Is Agile the way to develop elearning now? Is ADDIE something we even want to escape from?
I recently ran a workshop on Action Mapping for large elearning design and development company. They knew the method already and liked it but wanted to explore some of the practicalities and subtleties of using it on projects. One topic that generated a lot of discussion was the idea that, at the same time as generating creative ideas for practice activities, the designer should prototype these as far as possible – build working courses and scenarios instead of writing outlines, then storyboards then scripts.
While most of the people round the table saw the reasoning behind this they realised it would have major changes for how they worked. They’re not alone. The ADDIE model – Analyse, Design, Develop, Implement, Evaluate – still seems to be the standard model in larger companies, both larger elearning providers and larger corporate customers.
I’ve spent most of my time at the client end of this process, receiving outlines that had to be signed off before scripts could be written, then scripts that had to be signed off before any development could be done. The problem is that a script gives a subject expert (SME) very little taste of what a finished piece of elearning will feel like. The SME has their own job to do, and when a 30-50 page elearning script lands in their inbox, for comment by Friday, it’s not always easy to give it much time. Many SMEs I spoke to in those days printed off a bulk of paper and read it on the way home or at home. Inevitably they would be very tired by the halfway point and lose interest and acuity. Where the learning was scenario-based it was even harder as they had to work out what the learner would see if they chose this or if they chose that. No wonder Powerpoint plus a quiz was preferred as a simpler model to review. At least they could envisage what that would look like. How many times, however, did we hear ‘You signed that off at script stage’ ‘Yes but I didn’t realise it would end up working like this. I couldn’t see that from a Word doc.’
The developers stuck to this method as a protection against ‘scope creep’ and as a formal method of change management. Once the client had signed off a stage, any change to that stage had to go through various logs and hoops and could potentially incur new charges. Since the people who wrote the script would not be the people who would do the development, my clients on the workshop debated how they would involve developers at an early stage to create prototypes and how they would protect themselves from change requests running out of control. It seemed to come down to a balance between speed and simplicity on one hand, and cost control and the overstretching of resources on the other.
The most refreshing experience for me since leaving the corporate world and working with very small organisations has been the ability to work in a much less formal way, and always working from prototypes. Signoff stages haven’t come into it. SMEs have been more able to give me time and commitment than they would in larger organisations. But how do larger organisations move toward a method closer to that of Agile software development?
Here are a couple of articles giving cautious indicators.
Colin Welch of Brightwave describes a project where they began with a prototype and completed most of the work in a 2-day event ‘no phones, no email’. While he describes the process as resounding success, he states some important preconditions which are not always present.
‘ I was asked recently if we could work in this way again and the answer is that with the right team, the right client and the right pre-conditions, I would never work in any other way.’
Anand Timothy gives an overview of the contrast between the different models and the factors that might allow a different approach to succeed – with certain projects.
These approaches seem to be the exception still. Anyone else managing to successfully overcome the inherent difficulties of the ‘signoff stages’ ADDIE method? Please share your experience or articles you’ve read and post links below.