Instructional Design Needs More Agility

A few years back, while working on the Pan-Canadian Online Learning Portal definition project, my colleague Grigori Melnik introduced me to Agile Programming. The Future of Software Development discusses some of the major differences between agile programming and the earlier, less flexible Waterfall Model. You see, at one time, software engineers assumed that they could design a program and then build it based on those specifications. However, the world changes and we never really have a clear picture of all the necessary factors at any given time. My read of the article had me asking if instructional design [or ISD or ADDIE] is also arrogant:

“The problem was that the Waterfall Model was arrogant. The arrogance came from the fact that we believed that we could always engineer the perfect system on the first try. The second problem with it was that in nature, dynamic systems are not engineered, they evolve. It is the evolutionary idea that led to the development of agile methods.”

Instead of factory-style production teams, agile programming uses far fewer, but better, programmers. The principles of communicating, focusing on simplicity, releasing often and testing often are all applicable to developing good instructional programs.



Software development has embraced the iterative and flexible Agile model, but not without a major re-education program. It is up to industry to educate customers so that requests for proposals don’t force vendors into using an older and outdated model. I still see educational and training RFP’s that leave little choice but a quick analysis (if any), little design time (and only at the front end) and then get into production based on a specification whose premises were never tested and cannot be questioned later.

It’s time that the training industry develop its own agile approach or risk becoming redundant.

15 Responses to “Instructional Design Needs More Agility”

  1. Jay Cross

    While I detest ADDIE, I understand why it made sense several decades back. Not only was there arrogance; the presumption was that things were very slow to change. When time stands still, the future mimics the past, so tradition carries a lot of impact

    Not only that, but our understanding of complexity rips all certainty from our lives.

  2. Mike Taylor

    I thing Jay makes a good point here. I know I never have time to carefully/slowly progress through the waterfall. Due to short, dynamic time constraints in conjunction with the complexity involved; the process is much more like a washing machine than a waterfall. (To borrow someone else’s analogy.)

  3. Mike Deutsch

    Great post, Harold. I’m a programmer, and my first job was building business learning simulations at a consulting company (SMG Inc, Philadelphia, now a subsidiary of ) which was completely Waterfall-oriented.

    Not only does Waterfall result in projects that are obsolete by the time they are done, it is a recipe for tension between the clients and the consultants. It all comes from the developers trying to lock down the specifications and make it as costly as possible to change anything. I’m looking into Agile project methods in my current job, and I can’t wait to try a new approach to that area.

    @ Gilbert, the function of Instructional Design doesn’t go away in Agile methods. It just becomes one role of the development team, and it contributes the ID perspective incrementally along the way instead of all up front.

  4. Gilbert

    In agile methods it is very possible that Instructional Design as most people understand it could, for all practical purposes, disappear.

    In many cases YAGNI (You Aint Gonna Need It) will apply. No instructional design … just evolution and adjustment.

    It takes a while to understand the Agile Paradigm.


  5. EJ

    Either method alone leaves a lot to be desired and in the wrong hands can lead to failure. Instructional design concepts are extremely valuable so why throw them away because someone doesn’t understand their value? Why not use them as a starting point with the understanding that evolution will need to occur to stay relevant? This will save more time than it requires. The evolutionary process for coding may work from the programmers perspective, but I have seen it produce un-usable products for education. Starting with basic instructional design concepts and then evolving is needed. Streamlining the design process and hiring more experienced designers is a better solution than doing without any design, but for some reason it is not common knowledge yet.

  6. Bala

    I agree to your viewpoint Harold. But IMO it is applicable for certain types of training – software, process, procedural, where the work product and instructions can be integrated. I tend to look it more like augmented reality than agile programming.
    However in other areas like soft skills, where we are trying to change behavior, this approach may not work well.

    • Harold Jarche

      Thanks for your comment, Bala. Changing behaviour, or addressing soft skills, is less of a training issue than a cultural one. In this case we need agile work environments, not agile ISD. Learning needs to be embedded in the work, “In order to develop the necessary emergent practices to deal with complexity you need to first cultivate diversity [autonomy of each learner] . You also need rich and deep connections, but these are not enough if you don’t also have meaningful conversations [social learning].”

  7. Nancy Munro

    I have long said that the ADDIE model is not the end all. We developed an alternative approach “IMPROV” model to take the approach of designing the training to pinpoint a tangible business impact and then design backwards. We also recommend that you engage the trainee in contributing to the content of the training vs. just repurposing existing content. I = impact, M = measurement, P = Real World Proof, R = Results, O = Ongoing — training will change as conditions to business change V= variety- allow trainees to select how they want to learn.


Leave a Reply

  • (will not be published)