Being Agile With A Lowercase 'A'
How should we approach the management of eLearning development? The traditional model for eLearning authoring is ADDIE: Analysis, Design, Development, Implementation, and Evaluation. This model has been in use for a good many years and works well for many purposes, but has the flaw that modern and trendy Agile methods try to avoid - it's all too easy to produce something huge (and hugely expensive) before any users have seen it at all.
Agile Concepts
That's why I've always preferred the Agile concepts; I love the story about how Boeing used it in aircraft development - see Agile at Boeing in 1990s – the 777 Program if you're not familiar with it. In short, the old method was that a plane would move through the production line whether or not that particular phase had been completed - and spent ages at the end of the line being finished off (sound familiar?). The agile way was to stop at each stage until it had been completed. This had an amazing impact - no one wanted to be responsible so everyone pulled together in a flexible (agile) way. The results were an amazing improvement in speed and efficiency.
Another great example is how to stuff envelopes - take a look at this video:
In short, make a whole thing (whatever that may be) first and see if/how it works before you make hundreds of them and finish making one before you start the next. That principle works if you're making planes and also if you're making eLearning courses. So, the question is: How do you put in into practice? The eLearning industry -like many others- loves its TLAs - three-letter acronyms. So, what often seems to happen is that many models are developed to fit in with the names to make a nice acronym.
Applying Agile
I certainly don't want to criticize these models - many are very good and serve as an excellent framework to apply Agile principles in day-to-day work. However, these acronyms do sometimes distract from understanding the core principles behind the concept - the Agile Manifesto.
Therefore, I suggest that as Instructional Designers and eLearning project managers, we take a step back from the TLAs and (re-)read the Agile Manifesto. And then think about how to apply the principles in our work to make it truly agile with a lowercase 'a'.
The Agile Manifesto was of course written specifically for the software industry - not identical to ours, but similar in many ways, so it has many takeaways for eLearning development.
Lots of the suggestions given in eLearning development models are around processes. Although the Manifesto says processes are valuable, it suggests that interactions -talking to people- are far more important. What does that mean then? In order to examine that, I'd like to look at a principle from Lean production. That's the 'build-measure-learn' feedback cycle whereby your goal in each production cycle is to produce a minimum viable product - MVP.
An MVP needs to be:
- Minimum - that is the smallest complete 'unit' that can be produced.
- Viable in that it needs to be able to function fully.
- Product - a complete product that you can take to market/your client for use with end users.
What is an MVP in the context of eLearning? It's not necessarily a short course or one module from a course - a real MVP is something designed so that you can learn as much as possible about what your client/end users really need. It could be a module or course, but it may also need to include the platform and other wraparound material, too. In many eLearning contexts, however, a module from a course is likely to be a realistic MVP.
So, you've built your MVP. The next step is 'measure' - that means putting your course in front of users and testing it. There are several key aspects here that are often overlooked - the point of an MVP is that you need to put it in front of users as soon as possible in order to get real 'actionable' feedback that you can then feed back into your next phase of development (learn) –thus asking the right questions– to gain 'actionable metrics' – actual figures that will help you with your development is vital (rather than ‘vanity metrics’ – numbers that sound good, but can’t be used to improve the product). Then of course, you need to repeat the cycle –'build, measure, learn, repeat'– incorporating the feedback into the initial product and then going on to develop the next phase of the product (the next course module, next course, etc) and testing again.
So, coming back to the human interactions – in order to test a product in front of real people, we need to talk to them. That might mean showing your early development course to a client sooner than you want to. It means asking the right questions and listening to their feedback –all issues around human interactions, which may mean that the carefully designed processes need to be modified– or even scrapped. It's far better to know that at the earliest stage possible, rather than at the end of a project.
How does Lean relate to Agile? I think of it as Lean –higher level– the framework in which processes are developed, and Agile –day-to-day work– using the systems and processes.
To my mind, it's getting the principles of Lean to feed into Agile that is the key to a truly agile approach through talking to people rather than focusing on processes. This then becomes truly agile with a lower case 'a' eLearning development.
So, what does the Agile Manifesto look like? Here it is in full:
Manifesto For Agile Software Development
We 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.