My last post was about Agile Learning Design, an iterative model of instructional design that focuses on collaboration and rapid prototyping. And it has become quite a hot topic this past year. It’s the new alternative to the old—and some have argued outdated—ADDIE model. The most welcome change is the fact that an Agile model has you sharing your mockups, prototypes, and early suggestions with the client—right off the bat! This way you can adjust on the fly. No more building a course only to realize the client hates the design of a button in every single section.
How we talk about Agile versus ADDIE
This difference (of early sharing and collaborating) is such a breath of fresh air that some people have even recommended leaving ADDIE in favor of a new, more agile system.
I can see where they are coming from because newer and more efficient processes have since been developed. Agile takes into account new technologies and more rapidly evolving ideas. But I’m not sure if “leaving” is the language we should be using. The concept behind the ADDIE model has worked for instructional designers for years. There is something about the simplicity of it—it grounds the team in stages so you know you’re not designing before you’ve defined the problem, or developing before you’ve laid out your design, etc.
“To me it’s not really versus”
So I would say that Agile isn’t a complete replacement for the ADDIE model. We’re not urging you to pull an “out with the old and in with the new” approach. In fact, you can make the case that in an Agile model you still do all the steps of ADDIE. Why does it have to be a fight between the two?
That’s precisely the point Jennifer Bertram made during my interview with her. She’s the resident ‘Agile expert’ here at Bottom-Line Performance, and here are some snippets of what she had to say:
So in Agile versus ADDIE, which one wins?
“To me it’s not really versus. I don’t think they’re incompatible or that the science of ADDIE is wrong at all. I just think working with other people requires you to communicate more frequently—and so you need an Agile process. Our clients really love being part of the team in the design meeting, in deciding what the interactions are and so on. We’re getting to solutions our clients are comfortable with earlier because they were there helping create them. That’s how Agile expands on ADDIE.”
At BLP we primarily use the ADDIE process, but integrate it with Agile. Can you explain when each process makes the most sense?
“If all you want is the traditional words on a screen with a next button, then Agile doesn’t make sense. That’s because there’s nothing really to iterate—there’s nothing to prototype, there’s nothing to test. You would still use ADDIE there. The Agile process is about different functionalities and what task we’re having those learners practice.”
We’ve used the Agile process when building Knowledge Guru games, is Agile a good system for developing learning games?
“Agile is really helpful for learning games because there is a lot of functionality to test—there are a lot of moving parts. So you think about when we develop learning games you have the learning goal, the specific challenges you want those learners to complete in the game, how do they win and what’s that system look like—there’s a lot of things that could benefit from the Agile process, the collaboration and iteration.”
ADDIE wasn’t supposed to be so rigidly applied
A lot of the bum rap that ADDIE has gotten recently, the reason that so many are hailing it as “outdated,” comes from that fact that people picture the ADDIE model in a few different ways. Yes, the original version of ADDIE—the one developed in the 1970’s by Florida State University—is rigid, linear, and completely impractical for us. However, even those who thought it up knew that.
Shortly after its development, the model started being revised and adapted for more practical use. The diagram below shows two different diagrams of the “same” ADDIE model. On the left is the very first diagram from Florida State University (1975) and on the right is a version of the model that started becoming popular later on.
You can see how the diagram on the right starts to become a lot more like Agile. The evaluation is more constant and the structure is much less rigid. It is still lacking a system of iterations and rapid prototyping, and it still doesn’t bring the client into the early phases, but it’s much better. It’s so easy to hold the diagram on the left up as a straw man argument for ADDIE.
Semantics aside, we still need to embrace Agile
Regardless, the future of instructional design is still Agile. Rapid prototyping, consulting with the client early on, and constant collaboration leads to faster, more innovative solutions. Not to mention it saves you time and frustration. No more developing a pretty, polished game only to realize the client wants changes or had a budget cut. All in all, I think we should avoid talking about ditching ADDIE completely, but we need to start moving on to Agile learning design.
Interested in learning more about agile learning design? Watch our webinar: Agile Learning Design: A Practical Perspective.
Related Posts
You Can Follow ADDIE... and Be Agile
Borrow the best from agile to produce quality eLearning fast.
Using Agile Methodologies for Organizational Change Management
Practical advice that will make you rethink how you do change management.
Building an Agile Toolkit for eLearning Development
Does your team need to develop high-volume, high-quality digital learning assets? Then you need an agile toolkit.
Yes, the original model was very rigid, especially if they were no review/sign-off at each phase, before moving on to the next. Your more flexible model is more… flexible, but all in all, it depends on budget: your yellow arrows going backwards are indeed very interesting from a design perspective, but not budget-wise… which leads me back to my question in your previous post:
How do you budget/sell this to the client? Some (probably a lot) would argue that there is too much uncertainty, not knowing how much in the end a project will cost…
David, someone else may have a better answer, but since 5 months have gone by I will give this a shot.
1. Realistically, this will not be an infinitely iterative process. For budgeting, you could anticipate 2-3 iterations in a phase, each being lighter than the one before (expect more if in the midst of organizational change). Therefore, an instructional designer or project manager (especially an experienced one) should be able to budget the project cost. Also, without an agile approach a project still has uncertainties.
2. The cost of early adjustments is much less than later ones. By making changes/improvements in the Analysis or Design phase, you save the expense of “going back to the drawing board” after implementation… which can be very costly. In this sense, the organization/client can see a cost-savings by implementing agile processes. Most organizations are using similar Continuous Improvement philosophies in other areas of their business and may appreciate this approach with designing learning.
That’s my 2¢ (1¢ per point, I suppose).
The Agile should not be the last refuge of the unprepared.
say what?
Having worked with Agile and Waterfall a lot, I can say I believe in Agile a lot more than in traditional design strategies. The end costs are not higher than traditional design, and the assurance that the training will be useful and appropriate is worth a lot.
My question to you is : what did you change in Agile to make it viable for training purposes? What did you have to cut, what did you have to add and what did you have to change?
I really enjoyed your post. In my process I tend to follow a mix of processes and agree that they aren’t competing. A blending of the two methods is great and even looking at ADDIE in a much less rigid light helps the process itself be closer to Agile.
I’m currently reading “Leaving ADDIE for SAM” and it seems you mention (or at least I think) this thought. So far I’m thinking it’s not a requirement to leave it but rather use it in combination with more modern approaches that also have their weak points.
Thanks, Nick.
The key point we try to make is that it’s not about “leaving” ADDIE… but about knowing when it makes sense to be more Agile and when the ADDIE approach still makes sense. There is plenty of grey, and plenty of chances to blend all these tools and methods we have.
My sentiments exactly. I work with a combination of all these methods, I can’t speak completely for “leaving” ADDIE but on the surface it sounds a bit one-sided. I agree with your post and your statement that there is plenty of grey and plenty of changes to blend methods.
Your key point is a great one, and one that I think everybody should recognize and be willing to work with.
I use ADDIE as a flexible model and believe most organizations have entered the development cycle, and not returned to design unless it is needed from analysis data. Misinterpretation of the model has led practitioners’ astray. Agile is more focused on the seasoned development professional to move quickly while listening to the market we are developing for and don’t duplicate costly work, use advanced tools, keep distance learners engaged.
I certainly agree that these two are not competing. It is sensible that the use of either should be fluid and not so rigid. The truth is that the designer needs the ability to change the order of what comes next depending on the circumstance. I believe that either may be used as long as all steps get accomplished.