The Tension between Documentation and Product

My beginning Instructional Design students are writing a script and storyboard. I have them do a modest analysis, develop learning objectives and test items, write a prerequisite skills outline and, finally a content outline before they attempt the storyboard. Sounds like a waterfall process, doesn't it? Yes, I have to admit that it is. However, as Rob Miller keeps telling me, they have to walk before they can run. In their second year, after lots of storyboard experiences, I take them into Agile.

This year, one of my students asked me the following question:

"I am doing the Script and Storyboard. I changed the presentation from what I stated in my Content Outline. Should I go back and change my content outline."

As I wrote the answer, I realized how much I have been influenced by Agile philosophy. My answer, as you see, is "NO" but the insight has changed to a product orientation. Here was my answer:

"EXCELLENT QUESTION!!! The answer is no, you should NOT go back and correct the outline. otherwise, the outline becomes the product. Let me explain. The ADDIE process is a system. A change in one phase affects the others. However, we want that system to be progressive instead of recessive. We don't want to go back. Sometimes clients with huge bureaucracies demand the documentation. However, that is a dumb thing for them to do because it slows down production of useful material.

Our goal is a product that the client (in this case ACME Driving School) can use. If we go back and do the outline, we have a very nice bit of documentation but who does it serve? The purpose of the

outline was to provide a guideline to get us started. We in the industry realize that things happen in scripting that may not have been anticipated in the Content outline. You may have gotten better

information from an SME, another professional may have introduced you to a better way of presenting content, you may have had a revelation about the content or the way it is presented. All those are great. WE DO NOT WANT TO BE SLAVES TO DOCUMENTATION. It helps us get started but it should not hold us back."

Rethinking Where Agile Instructional Design Reaches

A Draft (or drafty) Agile Model for Development

I'm now trying to apply agile concepts into a Multimedia Design class, MM 2123, Corporate Multimedia Production II. I had been struggling with how to teach Agile concepts and my good friend Dr. Rob Miller came through for me. A few days ago Dr. Rob took Ken Schwaber's Agile software development model (Schwaber, K. (2003) Agile project Management with Scrum. Microsoft Press: Redmond, WA) and attempted to apply it to instructional development as a way of explaining to me how to conduct a Scrum. Knowing Rob, it probably took him only 5 minutes to do this so it is not a finished product. However, it will help me describe what I'm thinking. Here it is: Simple_Agile_Development_Process

Agile and Rapid Prototyping (RP)

Over the past several months, I've been thinking about the differences between Rapid Prototyping and Agile methodologies. Among my readings was an article in a book edited by Reiser and Dempsey (2007), Trends and Issues in Instructional design and Technology, Prentice Hall:Saddle River, NJ. In an article in the Reisher book, Richey, Morrison, and Foxon (Instructional Design in Business and Industry) describe rapid prototyping as the "development of an instructional product that is used early in a project to assist in the analysis, design, development and evaluation of an instructional innovation."

However, among the critiques of RP is that it was used as an excuse to shortcut the analysis and design process and often resulted in products that suffered from not having been analyzed or designed properly. I used to say that the main difference between RP and Agile was that RP was not informed by good analysis and design whereas Agile had to start with a good analysis and design. I've changed my mind. The differences are much more stark than that and my thinking was too limited to the development phase of the ADDIE process.

As I looked at Rob's take-off on Schwaber's model, and after a short chat session with Rob this morning there are even more substantial differences between RP and Agile. I also decided that Agile was useful in more than just the second "D" of the ADDIE process. Before I go further, review Rob's slies and then concentrate on slides 5, through 9. After I looked at those, and after sleeping on it, I realized that, unlike RP:

1. We let the customer (versus the team) decide what is important. That doesn't mean we roll over. It is our duty to inform him/her of best practices and useful research. However, ultimately, the customer is always right.
   
2. We focus on delivering Value first. Customers don't care for analysis but a lack of even a back of the envelop analysis is a recepie for disaster.
   
3. We can create tasks for the ISD team that include Analysis and Design. We have to ask ourselves, "what do we need to know or have before going into development." As Rob shows, we need that Test Item Spec. What do we have to do to get that?
   
4. We focus on having a finished product not a prototype at the end of a given period or "sprint."
   
5. We can formally focus on getting the tasks done by use of Scrum and burn down sheets. Rapid prototyping did not have that kind of dicipline or focus.
   

I really need to review how Tessmer and Wedman's Layer's of Necessity Model since it led me away from a waterfall view of instructional design and opened my mind to the possibilites of Agile.