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.

Introduction to Agile Instructional Development

Introduction

Following several years in the US Army, I entered the instructional development/design business. I've accumulated 20+ years developing instructional products ranging from lesson plans to self-study texts, to computer-based training. One of the most interesting things about developing training products is the diversity of content to which I'm exposed. I've developed training on military radio systems, environmental compliance, prevention of shop lifting, aviation maintenance, lawn irrigation systems, emergency medical dispatch, homeland security, immigration enforcement, and religious education.

For the last several years, I have managed the enrollment and retention efforts of two US Government online training efforts, building up an online student body of over 200,000 students over the last five years (averaging over 100 new enrollments per day). This entails managing the necessary customer service operations, product management functions, quality assurance operations, and the software engineering efforts. That's another great thing about this field--working with great people.

Agile Methodologies and Instructional Design

My current research interests are focused on the application of Agile methods (e.g., XP and Scrum) to the processes of instructional development and classroom management. My software engineering team introduced me to eXtreme Programming (XP) and I'm a Certified ScrumMaster.

What's the Difference Between Instructional Design and Instructional Development?

I wish to use this space to address Instructional Development not Instructional Design. Charles Reigeluth describes Instructional Development as follows:

Instructional development is concerned with understanding, improving, and applying methods of creating instruction...The result of instructional development as a professional activity is ready-to-use instructional resources, lecture notes, and/or lesson plans ... (Reigeluth, 1983, p. 8)

On the other hand, Reigeluth describes Instructional Design as:

... concerned with understanding, improving, and applying methods of instruction ... it is the process of deciding what methods of instruction are best for bringing about desired changes in student knowledge and skills for a specific course content and a specific student population. (Reigeluth, 1983, p. 7)

Reigeluth's distinctions are quite useful from an Agile perspective. Instructional Design is the application of Instructional Theory, whereas Instructional Development refers to producing instructional materials and actually getting the work done.

Consider the analogy of a software engineering team. The team will choose to develop solutions in different architectures or frameworks, based upon the customer, the delivery environment, and the tool sets available. They will apply their skills to coding practices and patterns to ensure that the final product meets the customer's requirements. Just as in Instructional settings, the distinctions between Design and Development are often quite subtle.

For example, when a software engineer develops unit tests, does this constitute Design or Development? On one hand, the unit tests certainly constitute working code; however, the unit tests represent decisions that will guide the development of coded products. Similarly, when a training developer produces instructional objectives or test item specifications, is he designing or developing? What do Agile methods lend to this distinction? This is one of the questions I hope to explore within this space.

One thing is certain, however; in both instances (whether developing software or training products) successful development teams must organize to accomplish their tasks, manage work flow, and get the job done with the resources at hand. This is, in my opinion, the first point to which Agile methods may be applied to Instructional Development.

Why Apply Agile Methods to Instructional Development?
The systematic design and development of instruction (i.e., ISD) is time consuming, expensive, and difficult. Make no mistake, ISD (in one form or another) is still the best solution to ensure that instructonal solutions are effective. But all too often, in my experience, by the time instructional solutions are ready for use they are no longer needed, out of date, or otherwise irrelevant. This has proven to be especially true when the solutions attempt to leverage more complex technologies (e.g., video, computer-based training, or even text-based materials).

Often, in attempting to shorten the delivery cycle, quality is often the first casualty. Unfortunately, by the time the customer comes to that realization, precious training budgets have been squandered. On the other hand, misplaced emphasis on "quality" often makes perfection the enemy of good enough. Attempting to find that middle ground where training development efforts provide maximum value to the customer, rapidly, reliably, and consistently is something else I wish to explore within this space.

Conclusion
Over the last few years, a good friend of mine has convinced me that when properly applied, Agile methods deliver working software much more responsively than alternative approaches. You can visit his blog at AgileJedi. His software engineering team employs eXtreme Programming (XP) quite effectively. I am certain the Agile methods can do the same for Instructional Development.



References
Reigeluth, C. (1983). Instructional Design: What Is It and Why Is It? In C. Reigeluth (Ed.), Instructional-Design Theories and Models: Vol. 1. An Overview of their Current Status (pp. 3-36). Hillsdale, NJ: Lawrence Earlbaum Associates.