Your Source for Learning
Technology, Strategy, and News
ARTICLES       RSS feed RSS feed

Reconciling ADDIE and Agile

by Megan Torrance

July 28, 2014

Feature

by Megan Torrance

July 28, 2014

“Instructional designers familiar with ADDIE don’t need to abandon their project-planning strategies or the vital stages of the ADDIE approach in order to adopt an agile approach. You can complete the various steps more quickly and cycle through them several times, with the goal to build usable (though not necessarily beautiful and perfect) iterations that can generate useful feedback from project stakeholders, and a superior final product that you complete on time and on budget.”

An agile project-management style, such as LLAMA (lot like agile method approach), offers instructional designers some significant benefits. In particular, such an approach means that you’re able to incorporate changes to your project without upsetting your budget or schedule. The LLAMA approach contrasts in this way with a more linear approach, such as ADDIE (analyze, design, develop, implement, evaluate), with which many instructional designers are familiar.

While it may seem that ADDIE and LLAMA would work against one another, in this article I will show how ADDIE is actually embedded within an agile process like LLAMA.

Is it one or the other?

ADDIE and LLAMA are not an either/or choice. LLAMA takes advantage of ADDIE’s strengths and converts the linear approach to one that supports a creative process such as learning design. Those “a-ha” moments that elevate a product from pretty good to totally awesome rarely occur at predetermined moments along a prescribed schedule.

A linear approach leaves the instructional designer with two options: forgo the new idea because significantly altering the project is too difficult, or incorporating the new idea at the risk of jeopardizing the timeline, the budget, and morale as the team members contemplate many late nights at the office. LLAMA project management doesn’t put the instructional designer in the position of choosing between the planning and the project. Instead, it encourages designers to leverage change for a better product without sacrificing anything.

ADDIE and where it works

First, a quick reminder of the ADDIE process (Figure 1) and the situations in which it works well.

Figure 1: The ADDIE process

The ADDIE process comprises five sequential steps.

  1. The process begins with an analysis of the need for training. This assumes that the designer has collected all information about the potential learners at this point and that the organization’s needs and expectations of the training will not evolve after completion of this step.
  2. Next is the design of a course or series of courses that address the needs. The instructional designer includes all necessary content, creates spot-on interactions, and designs a course that matches the client’s expectations for aesthetics and usability.
  3. Following design, the next step is course development: building the course according to the design specifications. At this stage the project is nearing completion so it is too late to include substantive revisions.
  4. After this comes course implementation, or “release.” This is likely the first point in the process where an actual learner sees the course. Learners begin taking the course and applying what they learned to their daily work.
  5. Finally, there is evaluation of the training. Perhaps learners provide feedback about the course and the process begins again as the client considers other areas for improvement, which then undergo analysis for potential training topics.  

The ADDIE process works effectively in situations where everyone involved knows exactly what the finished product should be like, where it is certain that the content will remain static, and where no one will have any mid-development brainstorms that might require reworking the project. These situations are a bit like the El Dorado of the learning-design world—highly sought after but rarely (if ever?) encountered.

How do agile and LLAMA relate to ADDIE?

In an agile process (including LLAMA), the ADDIE steps outlined above are completed with an important twist. Literally—a twist. While ADDIE looks a bit like an arrow, the agile process takes the same five ADDIE steps but it looks more like a corkscrew. (Figure 2)

Figure 2: The agile process is ADDIE with a twist

Agile doesn’t wait until the very end to get feedback from the client and from potential learners. The goal of an agile team is to produce several iterations of the training, each of which is a usable version, meaning the course is substantive enough for the client to understand where the project is headed. The client and other stakeholders can offer feedback early, before the course is fully or almost fully built, so that changes can be made.

Building a bus: the ADDIE way vs. the agile way

You have to build a bus. With an ADDIE approach, you analyze the needs for a bus and decide the engine must be absolutely perfect. You start by building the engine, then optimizing it like crazy. Two weeks later, the project sponsor arrives in your shop.

“Can we take it for a test drive?”

You start listing the engine’s technical specifications. You describe your victory in finding just the right components. You show off the chrome fashion styling and the embossed logo.

“That’s nice. Can we take it for a drive?”

No, but we have these really nice little pink rhinestones over here. Aren’t they great?

A linear approach doesn’t lend itself to test drives two weeks into the project. Instead, you build the learning experience one component at a time and the test drive is frequently the drive off the lot and into traffic.

On the other hand, an agile approach might go like this:

You have to build a bus. You start by building a rough skeleton of the bus, with a basic frame, a basic engine, a steering wheel, and something to sit on. Two weeks later, the project sponsor arrives in your shop.

“Can we take it for a test drive?”

Sure! Let’s go.

“This is nice. But I forgot to tell you that we are going to be driving this bus in Ireland so the steering wheel needs to be on the other side.”

Sure thing!

You’re only two weeks into the project and you’ve still got time to accommodate changes to the requirements. You’ve only got the basics of the bus built, so it’s easy to switch the steering wheel.

Agile gives you the flexibility to handle changes, even after the project starts. Even better, agile encourages change. It helps you leverage those brainstorms and big ideas to create the best possible product.

The agile experience, iteration two

Consider this bus scenario:

You have to build a bus. You start by building a rough skeleton of the bus, with a basic frame, a basic engine, a steering wheel, and something to sit on. Two weeks later, the project sponsor arrives in your shop.

“Can we take it for a test drive?”

Sure! Let’s go.

“This is nice. But you know what would be really cool? What if we could make it amphibious, too?!?! Can you do that?”

Sure thing!

You’re only two weeks into the project and your project planning has positioned you to accept radical changes to the original concept. You and the client are both happy!

You’ll go back into your shop, incorporate the changes, and produce a new iteration for the client. It still won’t be a complete bus, but it’s getting closer. The project sponsor can take another test drive to see how you’ve modified the project and can suggest additional changes if necessary. Depending on your timeline, budget, and relationship with the client, you may make a new iteration or you may feel that it’s time to create the final, perfect bus.

Orient the client, communicate, and iterate to win

In agile, the design and development stages occur initially as you plan and build the first approximation. The “test drives” serve as the implementation and evaluation stages. You have not fully implemented the project in the sense that it’s ready for release, but it is usable which means that stakeholders can evaluate it. As the client makes suggestions, you tinker with the design and develop a new iteration, which leads to another round of implementation and evaluation. 

As you can see, the agile method requires more communication than a linear approach. An agile approach will make the finished product much stronger, but it can also mean the project can slow down if you’re waiting for the client to provide feedback or approve tasks. Orienting a client to the agile approach might be an important step to consider during the project’s initial meetings.

Instructional designers familiar with ADDIE don’t need to abandon their project-planning strategies or the vital stages of the ADDIE approach in order to adopt an agile approach. Instead, consider how you can complete the various steps more quickly and cycle through them several times, with the goal to build usable (though not necessarily beautiful and perfect) iterations that can generate useful feedback from project stakeholders, thereby leading to a superior final product that you complete on time and on budget.

Understanding the sequence of agile is only one part of putting agile to work for you. I will provide additional articles on LLAMA project management that will explain the nitty-gritty of planning projects at the discrete task, weekly, and project levels.

Note from the Editor

Megan Torrance teaches Agile Project Management for eLearning, a course offered by The Guild Academy. The next offering begins September 16, 2014; details are online here, and the course is available for private training for your team.


Topics Covered

(69)
Appreciate this!
Google Plusone Twitter LinkedIn Pinterest Facebook Email Print
Comments

Login or subscribe to comment

I'm sorry but whoever gave you the information about ADDIE being linear is sorely misinformed. ADDIE was never conceived of as being a linear process. Besides if one truly understands instructional design, a formalized process of any kind is completely unnecessary.
The most adept uses of the ADDIE model are indeed not linear. What I find when I talk to many instructional designers is that it becomes linear due to the realities of time, space and budget that most organizations face. They have time to "get through" one ADDIE before they stop and move on to the next project. They make little adjustments and accept change along the way, but they are not cycling back in the way that they would want to.

An Agile approach would ideally incorporate several iterative releases within the same timeframe as a traditional project, offering more opportunities to collect feedback before the project sits and the instructional design team turns to its next effort.

In my own experience, a formalized process of project management is quite necessary. The organizations that fund projects appreciate a rigor around ensuring that they are completed within a reasonable timeframe, a reasonable budget and in such a fashion that they can be said to be effective solutions to the problem at hand.
Love the idea of getting something into the stakeholders hands early (the "test drive"). In a past life as a software developer, I often found that some requirements weren't known by the client until they saw a prototype. The sooner you could show them one, the sooner you could build something to meet the new requirements.
As an added bonus, in a pinch you could use one of those prototypes as a stop-gap training measure. I wrote a bit along those lines in a post of my own: http://www.simonblairtraining.com/2013/09/agile-learning-or-how-half-course-is-better-than-95-percent-of-one.html.
What I like about this article is it affirms the power of ADDIE in a typical work environment. That is, short deadlines and no funds for scope creep. So, to use the bus analogy, the project is already over in two weeks. What I see more frequently is that people forget the first step, that of Analysis. It's at that point you determine that your users are the Irish amphibians and build to suit. Input is essential along the way, with great ideas incorporated into the next training project. Too often we jump into development so that we can "test drive" with stakeholders what has been done. How about stakeholders show us what they do all day? :-) I do like Agile and building what is required by the stakeholder and what is agreed to. Spend more time on Analysis. Without it, your process and your result is "DIE."
Deeply appreciative for the approach taken in this article. A key and much-appreciated point made up front is that "ADDIE is actually embedded within an agile process," so we don't have to make this an either-or choice. The idea promoted by the title of the book "Leaving ADDIE for SAM," for example, misses the point that we don't have to abandon one model for another when we actually can benefit from knowledge and use of a variety of models to meet the needs of our learners and those whom they ultimately serve.
In software development, iterations define the cadence for the implementation of user stories, not releases. How many iterations are in a typical LLAMA release cycle?
@rminto, I'm not sure there's a "typical" number of cycles. Many instructional designers will relate to an "alpha, beta, gold" approach with 3 iterations.
Great article Megan! It is definitely not an either/or scenario. You made the points about iteration and collaboration with stakeholders earlier than later. I would only add that other ways to incorporate lean or agile principles in learning content development is to make work products smaller (which our learners are demanding anyway!), scrum - which is daily communications between developers to increase velocity/remove barriers, and write user stories that put requirements into the context of the audience. Learning content management becomes more critical once you break your work products down, and another way to be more agile is to develop your content so that it is separated from presentation so it can be applied more readily in other modalities or variants to address the same business need for other audiences. Look for tools to help. They are out there!
Great article. I've just wrapped up reading Jeff Sutherland's book The Art of Twice the Work in Half the Time and my immediate thoughts were of how to better integrate Agile with traditional ISD. This article describes the iterative approach which is a hallmark of Agile.

I would like to see how the author has integrated the daily standup meeting which focuses on identifying what has been accomplished and identifying obstacles. There are three reasons why I would think this is important. 1. A daily standup will demonstrate a progression of effort and accountability towards the next iteration and keep everything on track. 2. Discussing obstacles/issues can help facilitate creativity. 3. Creates the opportunity for obstacles to be removed.
Related Articles