Building the Agile Case: How to Better Manage L&D Projects

Speaker: Megan Torrance, CEO and Founder of TorranceLearning

The Agile Case for L&D

Let's talk about how you would build a case for using Agile and doing something different. I often ask people to think about the best project they've ever been on, even if that's not the current project they're on or with their current boss or their current placement.

But if you think about the best project you've ever been on, here's what people come up with. They come up with things like there was shared alignment on what our goals were.

There was a commitment to solving the problem as a result of those shared goals. And that commitment was shared by the sponsor, the subject matter experts, the team, and the relevant stakeholders.

They had the right information and, the right resources, and the right timeline in order to deliver; they got input along the way from learners.

They themselves learned about their craft as well as the topic. And they enjoyed working because people were committed and had great communication with each other.

Those are the kinds of things that people tell me about when I ask them to think about their best project ever. And you might think about those as well.

What is the best project ever? So then, this quote just really struck me at my core. When I started learning about Agile methods, because I also was having freakouts, working really, really late hours, struggling to deal with change and incomplete information and all.

The Agile Way

I stumbled upon Agile methods, and I thought, "Oh, this is incredible." And Kent Beck, who's one of the founders of the Agile movement, describes it this way, "Do more of what works and less of what doesn't."

So all those things that we think about when we think about the best project ever, instead of them being accidental, we actually have specific techniques to bake those things into how we run our projects so that every project might be the next best project ever, which seems shockingly, both brilliant and elemental at the same time.

Understanding ADDIE

Yet, here we have this ADDIE model that makes some of these smart things difficult. In the ADDIE model, I'm not evaluating to know if it was any good until the end.

This is designed in a world in which I'm doing all of my thinking up front, in that analysis and design phase. The thinking being that if I've thought everything through, I mitigate the risk of change.

Except we all know that change happens all the time, even midway through development or even midway through the implementation.

What's more, often, in a model shape like this, I am implementing something I have not yet tested to see if it will work. That is a little bit scary.

So you can never think everything through. There's always something. And yet we tend to go about the world or people, humans, tend to go about the world thinking that we can think of everything.

Here's the thing, the first day of your project is the worst day to plan what it's going to look like. And that's very difficult. And yet we need to, and planning is important.

Planning is more important than the plan itself. And yet we know change is going to happen. And yet we want to make sure that we are not simply accepting every single squirrel that runs across our path into our project because that's highly disruptive.

Oh, by the way, what we didn't mention when we were talking about what makes delivering our projects on time, on budget, and meeting the needs so difficult? Sometimes it's us.

Sometimes we're coming up with brilliant ideas that might risk taking us way off track, but they're brilliant ideas. We need ways in which we can evaluate, as a team, with our business sponsors, whether a particular change is in alignment with our goals and our learners.

What we're trying to accomplish is just really cool or additional or excessive and how we would manage that as we go.

Redrawing the ADDIE Model

Here's how I draw the ADDIE model. I believe in a little bit of analysis design and development, but I'm very quickly going to get out an implementation and an evaluation very early in my timeline.

We rarely have enough time to analyze, but guess what? This implementation and evaluation is at the same position as the analysis. That's another opportunity for analysis.

But when we put out our early iterations of a project...your subject matter experts are excellent for telling you, "Are you accurate? Have you included it all?"

Your sponsors and stakeholders are going to make sure that it's directionally sound. Your fellow instructional designers and the randos are going to help you catch what you missed and make sure you've got it right.

Except, not a single one of those people is on the hook for using what you just created to do their jobs better. That's why I'm a huge proponent of having those actual learners as part of your early iteration reviews.

If absolutely the ADDIE process did happen multiple times along the way, it might look something like this, where I continue iterating until I run out of time or budget or things worth fixing.