Well, who wouldn’t want to be? Agile, I mean. Given that there are so many antonyms of ‘agile’, including dull, ignorant, inactive, lazy, lethargic, lifeless, rigid, slow, and for good measure, probably sluggish too.
My background is in software development and traditional IT classroom training on topics including programming and project management. I gained twenty years’ experience as a software team leader and programmer before my involvement in instructional design at Saffron, which commenced about fifteen years ago.
The many vices of the software development sector include being prone to faddishness and a tendency to say ‘methodology’ when the word ‘method’ would do perfectly well. A current and prevalent software development fad goes by the name ‘Agile’ and it’s the applicability (or not) of an agile approach to an elearning development life-cycle that I consider in this post on the Spicy Learning Blog.
For more information on the Agile ‘movement’, may I refer you to the so-called Manifesto for Agile Software development, also known as the Agile Manifesto.
‘Agile’ approaches were introduced as a reaction to the problems created by the more traditional ‘waterfall’ approaches to software development. An equivalent waterfall-style approach that some people use in elearning development goes by the name ‘ADDIE’, where the E stands for Evaluation.
The waterfall approach left testing to the last stage of the life-cycle, by which time it was both very late and very costly to correct misunderstandings. Hence the Agile insistence on an iterative and incremental approach to development and delivery, allowing for mistakes to be identified earlier rather than later, to the benefit of all. Having once coined the expression ‘Better a little increment than a lot of excrement’, I remain an enthusiast for iterative software development.
To return to elearning development, let me quote from the manifesto and then consider the applicability of its principles to our industry.
“We (the manifesto’s authors write) are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more”.
Are you ready for the principles? Here they are:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
[We]Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Welcome a late change in requirements? Really? On a fixed-price contract? Or should we increase the price to account for the unforeseen rework to adapt to changing requirements?
My point here is not that it’s impossible to be agile in elearning development. On the contrary, Saffron introduced many of our practices to make our project development as agile as possible. But if you want to advocate strict adherence to those principles, you need to address the question of budgets and scope head on or else find a way to capture your customer or sponsor’s requirements so well as to minimise change requests (to content, if not appearance) later in the development life-cycle.
The question of being responsive to late changes but staying within budget is the not so agile elephant in the room for this method. I have my own preferred approach to taming it. If you want to know more, please get in touch with us. I look forward to hearing from you.
