Agile Instructional Development Project Management

I've gotten the opportunity to do a commercial level project with two really fine interns. This is my first attempt at an Agile-managed project. First, for Agile experts out there; I am not one of you. However, I want to gain knowledge in this area. I think it has a great deal of potential for solving a problem that one Army School's Chief Knowledge Officer told me about. He said that too many e-learning products are fielded on time but contain information that is out of date. There are other reasons....but I digress.
The purpose of this post is to share how I have begun organizing an instructional development project. We are only two weeks in and working only part time. To set up, the interns and I listed the tasks we needed to do on a chart. We used the card lay-down technique to determine the effort for each task, set a priority for them and established 2 weeks as our interval for a burn-down chart. Here are pictures:

Nice but nowhere near the level of detail of a software project. However, as the team discussed the way forward in out "stand-up" meeting, it occurred to me that we should list those items of content that we now believe must be covered. Then, we can prioritize those pieces of content very much like a software team prioritizes program features. We may find gaps there, or we may find content that we can save for a revised version.

I'm still thinking about this, but it seems worth trying for the first time.

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.

Taking Ideas from Programmers--Agile Instructional Development

My good friend, Dr. Rob Miller introduced me to some of the ideas behind Agile programming as well as some of the practices. The whole idea behind Agile programming, it seems to me, is to embrace change and to focus development on important requirements. Nice to have things are put on a back burner.

There are significant differences between the requirements of programming and the requirements of instructional development. However, there appears to be commonality in what is driving me to look at Agile as a better way to do an instructional development.

When we discuss Agile ISD, we have to include the works of Vischer-Voerman, Gustafson and Plomp (1999). They advocate the inclusion of three additonal paradigms to the ADDIE process. These include a "communicative" (Customer Collaboration) paradigm which emphasizes consensus and communication among all stakeholders throughout the life-cycle of a project, and a "pragmatic" paradigm (Working Software?) that envisions repeated tryout and and making revisions based on stakeholder recommendations. They also support inclusion of an "artistic" paradigm that (I believe) gives developers more license to use their own and customer subjective criteria in creating the final project. The artistic paradigm meshes with the idea of Working Software and and Customer Collaboration portions of the Agile Manifesto.