Why Agile?

In practical terms, Instructional Systems Development is broken. Broken, not because it cannot work--broken because it is applied in ways that cannot adapt to changes in the situation. What follows is based purely on my experience, and that of several of my peers. However, I believe that it will be instructive and provide a basis for why an agile approach to instructional development might be worth considering.

This Thing We Call "ADDIE"

Instructional Design 101. When developed in a systematic, logical manner, instruction can be highly effective--demonstrably so. The five-step model, premised on a typical systems life cycle approach, depicts how the components of Analysis, Design, Development, Implementation, and Evaluation work in harmony. This model is not unique to ISD, it is used in several fields. Further, not all ISD theorists adhere to this specific model, however, its use serves a point. The ADDIE model depicts a systematic relationship of development activities:

• A-Use of empirical information to guide development activities.
• D-Design to meet the results of the analysis.
• D-Develop in accordance with design.
• I-Implement
• E-Continual evaluation and revision (both formative and summative)

Indeed, in my experience I have found that a little bit of systematic development, even poorly applied, can significantly improve instruction. For example, the idea that instruction ought to be planned in advance, be relevant to some "need", and ought to produce some measurable outcome is often quite foreign to instructors in many settings.

ADDIE as a Waterfall

However, at some point in the process somebody attempts to apply this model to an actual production effort (see graphic below).



This graphic depicts the typical attempt to use a waterfall approach to develop a training product. In my experience this is quite common. Admittedly, my experience is heavily tainted by working with the US Government (Department of Defense, primarily). The appeal of this approach is undeniable--a thorough analysis yielding a solid design which, in turn, allows someone to develop great instructional materials that are implemented, evaluated, and possibly revised through a follow on development cycle.

And let's not forget the formative evaluations along the way! Those wonderful opportunities to improve the end product and ensure that it is grounded in the "real" world. Personally, in over twenty years of training development I have seen more of these approaches than I care to remember. I have also seldom seen one that survived initial contact with the real world. Instead, this is what usually occurs (see following graphic).

ADDIE Meets Reality


Typically, the flow of events goes something like this:

• Analyze (submit documentation)
  
• Reanalyze when NEW source materials arrive (Seems that the customer forgot to provide everything called for in the contract; revise previous documentation and resubmit)
  
• Re-reanalyze after change of Contracting Officer's Representative (Attempt to RE-revise).
  
• Design (Analysis documentation still under revision - screw it, go with what's ready now and hope that the rest will be ready when you need it).
  
• Re-design after change of Customer's Project Manager (promise that the analysis will be brought up-to-date and post your resume to Monster.com)
  
• Re-re-design after storyboard review by customer's “Instructional Specialist” (skip the analysis, now we focus on design documentation that conforms to the way the IS's did things in the last company he or she worked for).
  
• Re-analyze/design after change in policy, doctrine, or new “learning theory” (customer's IS returned from the latest conference where Dr. Jazn-Fritz hocked his new book on Mentored Instructional Anthropomorphism Theory and wants to see an entirely new approach to health and safety training).
  
• Develop/Implement/Psuedoevaluate (Go back to Square-One, do not pass Go, do not develop training products .... see if the IS's old job is posted to Monster.com)
  
• Out of time-Over budget- WAY over documented - just get it done!!

The Horizon of Predictability

Cartoonist Walt Kelly's character Pogo once noted, "I have seen the enemy and he is us!". In this case, too many well-meaning training project managers fail to realize that they are attempting to plan well beyond their horizon of predictability.



In a water fall approach, the notion that all is known at the beginning of the project if a false assumption--especially in large projects that span several months or years. Change will happen, no matter how much effort is expended at the front of the project. Change can be mitigated through strict adherence to contracts, however, you can rest assured that the customer will not return.

Furthermore, who is to say that change isn't necessary? Instruction should be relevant to current contexts and situations. If it is not, then it probably has no value to the customer. Wouldn't it be great to be able to provide up-to-date, relevant instruction when the customer's requirements change? That is why agile instructional development is necessary.