Agile Learning Design

ADDIE is dead. Long live agile!

There’s nothing particularly new or insightful about describing ADDIE as slow, rigid, and dated.

ADDIE emerged as the dominant process for getting training done after being developed by the US Army in the 1950s. Judging by the job descriptions, most training departments still consider it a requirement. 

Most times, people talk about agile as a preferred approach. More on that in a sec.

ADDIE is a waterfall process

Using ADDIE, folks frequently waste an enormous amount of time and money building something that doesn’t end up meeting the users needs. ADDIE is a waterfall process, named for each phase flowing into the next. What that’s meant in practice is that a training deliverable would be completed and delivered before the team might find out it was ineffective. Oops.

Instead of tailoring an entire suit from measurements taken the day it was ordered, using an agile approach they’d sew the suit by making one part at a time, so the jacket sleeves would be completed and checked long before the work began on the waistband of the pants. In the old way of ADDIE, sometimes the desired lapel width and cuff style might change while the tailoring team was working on the suit. Oh, and for you Gen Zs and other Silicon Valley denizens, a suit is formal business attire generally worn with a shirt and tie.

People want fast.

People want effective.

The web holds seemingly endless info on the difference between waterfall and agile processes, but you might start here or here.

What we talk about when we talk about Agile

If ADDIE is dead, or in hospice, Agile is certainly not. Agile has become a buzzword used so frequently as to make it difficult to figure out what it means.

Agile is the good process.

Agile is now.

Agile is what everyone wants.

Google’s dictionary says agile is, “is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

Maybe. Except that when we talk about agile, we’re usually talking about getting things done fast by skipping milestones and throwing content over the fence. That agile is a process derived from software development gets lost in the shuffle.

In practical use, when stakeholders and leadership talk about agile, they mean fast.

They mean letting go of the substantial lead times associated with ADDIE.

And getting rid of long lead times is a very good thing.. 

Quick is good

One of the considerations to keep in mind is the difference between how we learn at work and how we learn at home. At home, if I need to learn something, I’ll go right to what I can find in a search or so. In YouTube, I’ll generally pick the short video first, and only try the long one if the first try doesn’t give me the results I want. 

Maybe you have more patience. Maybe not.

At work, I might do multiple searches, and make a quick consultation call, only to discover that I need to wait for a class that’s being delivered next month.

For most of us, work is substantially faster-paced, dynamic, and ambiguous than it used to be. 

Training used to be something you’d get before your role began, and you’d need to remember what you learned to use it effectively.  Back then, of course, flip phones were the latest and greatest in cellular products. Things changed. Now we learn just a bit before we start, and need to keep learning as we go.

Which is great. Because we have infinite information in our pockets, wherever we are.

If we want our teams to be able to use our learning experiences, they have to fit into today’s world.

Quick is good.

Agile can be quick

If I can cut the amount of time it takes to deploy a solution to the field by 75%, it makes the difference between a useful tool and something that’s too little, too late.

And cutting lead time by 75% is a reasonable goal.

Many, perhaps even most, training requests can have an interim solution in two weeks.

That means a solution can reach the people who need it when they need it, if we approach the situation with the right perspective. It may not be pretty. It may need improvement. But the fast solution can be a game changer.

Breaking out of the late cycle

Old school training frequently arrived long after the time of need for the learner. The situation in the field changes, and word gets passed along to the learning team, but by the time the deliverable reaches the people who need it they’ve adapted in some way and are no longer wanting help. Or they’ve made decisions that now have to be undone. Or they created their own learning materials.

If we take too long, not only do we fail to meet the learning need when it’s most acute, we also end up behind the next emerging need. When I taught school, the students who were working on yesterday’s homework couldn’t find time to do today’s assignment and digging themselves out was painful.

Agile leads to MVPs

Where I worked last, we talked about MVPs all the time. At first I was confused because my brain automatically translated MVP into most valuable player. Not what they meant. They meant minimum viable product. Or they thought they did.

This took me a while to understand. By MVP, they meant a deliverable created in a hurry, without the perfectionism and approval chain that characterized their earlier system. They’d use an agile (read “fast”) process to create an MVP (read “first draft deliverable”).

All well and good. Except for one thing. If you use an agile process to create an MVP, what’s in the learner’s hands may not be as good as it should be. If we’ve paid attention, the product should be better than nothing, but the MVP now has the same disadvantage as something created through the ADDIE waterfall.

The minimum deliverable shouldn’t be the final deliverable. The MVP needs improvement. 

Only through speedy learner feedback can the MVP lead to a final deliverable that meets the need.

The dirty little secret

Here’s the dirty little secret: you have to revise and improve the MVP you created using Agile if you want to improve its learning effectiveness.

Otherwise, you’ve just created something like you would have with ADDIE, just sloppier.

Quality matters, and feedback drives quality.

After the learning deliverable is active, teams need to gather suggestions from the audience to make it something really solid.

An old adage from twelve step programs applies: half measures availed us nothing.

This is an admittedly disturbing idea. I truly want to believe that half measures will get me half. But with learning products, that usually isn’t the case. 

Half-baked training doesn’t change behavior. 

The agile process is a great way to produce effective learning deliverables. But only if we don’t walk away after delivering the first version. We need to iterate on the content if we want it to deeply resonate with our learners.