Iterations in Agile Learning Design

In traditional waterfall-type projects, learning platforms are developed in lengthy sequential phases. Learning methods and delivery flaws are normally only discovered during the delivery or evaluation phases. Fixing these defects can waste resources and cause delays to the learning platform or process due to the rework required. This is often referred to as the 1-100-1,000 rule — if it cost one to fix it in the initial stages of the project, it will cost 100 times more to fix it at the end of the project, and up to 1,000 times more to fix it once it is delivered.

Note: ADDIE or ISD is NOT a waterfall method, unless the users decide to use the tool in this manner.

Using agile methodologies or concepts allow the designers to test the learning platform up-front in order to ensure it is built upon a sound architecture by discovering the risks and alternatives involved during the planning stage, selecting valid learning objects, and then iterating them in a logical fashion.

Iterations are normally performed using two methods:

A Design Iteration is a micro-technique in that it uses a small set of learners to test part of the learning platform so that you make an interpretation of its effectiveness. This method is normally used for innovative design. A Design Iteration will generally use two types of prototypes:

A Release Iteration is a macro-technique in that it uses a large set of learners in order to satisfy two requirements: 1) it gets the learning platform out as fast as possible, even though it may not be fully ready; and 2) it allows large scale testing of the platform before it is polished.

A large and difficult or innovative project might use several Design Iterations and then make a Release Iteration. In turn, this process is repeated until the learning platform is completed.

After Action Review (AAR)

After running the iterations, use After Action Reviews, especially after you perform a Release Iteration, in order to transform deficiencies into actionable items. In addition, ensure you include the learners and their manager(s) in the AAR to ensure everyone is on the same track:

Many years ago I was asked by a business unit leader to design a project management class with a significant emphasis on budgeting and forecasting. I complied with his request and designed several exercises intended to address this stated need. When the class ran, participants convinced the instructor that because they didn't have to do budgeting and forecasting, there was no need to spend much time on those subjects. Therefore the instructor skipped them. Participants (learners) were happy because they didn't have to learn content they didn't want to learn, and the instructor was happy because his end-of-class evaluations were extremely high. Unfortunately, my client was angry. As he explained to me after the class ran, his employees were correct in saying that they didn't do budgeting and forecasting, which is why most of their projects were over budget and delivered late.” — Larry Israelite in Lies About Learning.

AARs not only help you get to the root of problems by having the participants discuss the project in a non-threatening environment, but is also designed to help keep the learners, managers, and you on track so that everyone is striving for the same vision.

Iterations and After Action Reviews are performed until your team and clients are satisfied with the learning platform.

Thoughts?

This article was first posted on my blog, Iterations in Agile Learning Design, but since blogs tend to push posts to the bottom as new posts are created, I thought I would post the series on my web site where they would stay more exposed and could be updated when needed. If you have any comments on this article please feel free to comment on the blog post.

Next Steps