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


email print

What Does It Mean to Be Agile?

by Megan Torrance

April 21, 2014


by Megan Torrance

April 21, 2014

“Using an agile project-management approach, a team builds their deliverables in small increments, releases usable training frequently, and uses those releases to collect feedback early and often. Successive approximation, aka iterative development, is central to agile methodology. It’s how you proactively gather feedback and, yes, changes, so you can further improve your product.”

 “Agile” is almost as hot these days as “mobile” and “gamification” when it comes to training industry buzz words. Sure, agility sounds like it could be a cornerstone of your workplace wellness program, but in fact it has a lot more to do with the overall health of your projects.

What is agile project management?

Agile project management is an approach for managing a creative project process, where team members both accept and expect change along the way. The team develops successive iterations of a product and uses their resulting observations to further improve the result. By comparison, a strict interpretation of the ADDIE model (analyze, design, develop, implement, evaluate) and other linear approaches works well in situations where all the inputs and outputs are known in advance. In a strictly linear model, change is often resisted as it throws project schedules and deliverables out of whack.

How agile works for eLearning development

Agile project management, originally conceived by the software industry, lends itself well to eLearning design and development projects where, if we’re lucky, we’re making creative and complex decisions along the way. How often do your customers (internal or external) know exactly what they want before the project starts? How often does that change once they see what you’ve built? How often does the underlying subject change in middle of the development project? We don’t live in a world that stands still while we build the CBT for it. And, I dare say, every once in a while we get a great idea that changes everything right in the middle of ADDIE’s development “D.” What to do? Get agile.

There’s a lot to it. For now, let’s start with what I call the “hallmarks of agile”—practices that agile teams adopt to manage their projects to bring them in at the right time, with the right budget, and with the right solution.

Define scope with user stories

An agile team sits down with stakeholders, learners, and subject-matter experts to define scope based on specific functions or actions they must accomplish. This business-performance-focused approach gets the project off to a solid start. Product-based projects (think performance support, LMS implementations, etc.) will tend to use a method based on creating “user stories” to define desired functionality. For instructional-design projects, use performance-based methods like Cathy Moore’s Action Mapping.

Break it down

When you break scope requirements and work tasks into small chunks, it’s easier to estimate your work and the project as a whole. Estimating is a whole other topic in and of itself, so for now we’ll focus on keeping things small. Complex tasks become simpler—and estimable—when you break them down into their component parts. And, as you’re working along, you’ll know when your estimates are off sooner if you work in small bursts. How small? Each team sets their own pace and has their own culture, but we’ve found that two- to four-hour tasks work well for many project teams. 

Produce frequent iterations to collect feedback

Using an agile project management approach, a team builds their deliverables in small increments, releases usable training frequently, and uses those releases to collect feedback early and often. Sound like the successive approximation model (SAM)? Successive approximation, aka iterative development, is central to agile methodology. It’s how you proactively gather feedback and, yes, changes, so you can further improve your product.

Accept and expect changes in requirements

Many of us are in the business of building training to give our learners and their organizations a strategic competitive advantage. It’s important to get it right. Some in our industry bristle at the thought of “eleventh-hour changes” to our projects. In expecting these changes to come, and accepting them willingly, we ensure that the training we deliver is up-to-the-minute. Now I’m not saying this is easy—however, it is essential. It’s what being agile is all about. When you produce an iteration, each release is an opportunity to gather feedback that influences future iterations. It’s ADDIE’s evaluation “E.”

Communication, communication

Agile is a full-contact sport. Frequent communications with business sponsors, with subject-matter experts, with learners, and within the team are essential. Not only does this help you manage the day-to-day workflow, but it is also a key method for gathering changes and ensuring that you’ve got the message right. Agile teams connect daily to coordinate their efforts in what’s called a daily scrum, or a synch-up, or a huddle, to name a few commonly used terms. In these meetings, team members share what they accomplished in the previous day, what’s planned for the day ahead, and what they’re stuck on and need help for. Customers and SMEs are involved in daily or weekly meetings, depending on the pace of the project. Learners are involved at each iteration in the feedback-gathering process.

Live in a visual world

One of the keys to managing small tasks and responding to change is a visual, vibrant, accessible, and living project plan. Whether it’s index cards and thumbtacks or a cloud-based tool, everyone has access to the plan, updates their own task completions, and knows exactly where the project stands at a glance. This is not a neat Gantt chart that’s made once and then shelved, or, at best, updated only on status-reporting days. An agile project plan is a living creature that shifts and adjusts as the work is completed each day.

What comes next?

In the months ahead, I will be addressing the key steps outlined above in tips that will appear in Learning Solutions Magazine, and in a Guild Academy course that will provide depth and practice. In the meantime, please post your questions in the Comments on this article!

Want more?

Megan Torrance will teach a Guild Academy course, Agile Project Management for eLearning, starting May 13, 2014. Sign up for this course and learn how to apply agile project management techniques to scope out a project, estimate and plan the work, generate frequent iterations to gather more feedback, and welcome constant change into the development process. Find out how to select a first project to use agile, how to train your team, and how to get your internal and/or external clients on board. Since agile is just as much a state of mind as it is a project-management method, you’ll also explore daily practices for implementing agile in your workplace.

Sign up now before this one-of-a-kind class fills! See the course page for details. There is a substantial discount for Guild members!

Topics Covered

Appreciate this!

Login or subscribe to comment

I work as the loan ID for a very large IT Organization. All of their projects implement Agile methodology in some form or fashion. I have been trying to structure my learning projects the same way. I found the article very interesting, and have saved it off as one of my favs. Thanks!
Grr, can't edit my comment. Loan = Lone
Thank you so much for the reminder @Megan and @Etraugott. Agile is the only way to go to get the learners what they need. It is my only ID workflow.

I also teach the agile methodology to my into to Web Design students see,

Let's connect >
Etraugott and Dave, good to have fellow Agile fans! We've found we have to make a few tweaks to the traditional IT and Scrum approaches for elearning projects ... and then we're set.

(I also lead an eLearning Guild Academy course on Agile for Elearning.)
I'm glad you addressed the estimating part of Agile Project Management. From a vendor perspective, my concern with Agile is managing costs for the iterations. Our clients want a firm price up front which drives me to define a relatively firm scope. With Agile, it sounds like you assume that you can't firm up the scope until you are into the process and work through the iterations. If clients expect the scope to change, I agree that the process is valuable. I find that the ones who sign the purchase orders don't really get this concept and neither do the managers who hold and manage the training development budget. I can see that it would work well from an internal perspective, but not sure it will go over well with those who have manage the $$. (vendors and budget holders)
Etraugott, I'm in the same boat as you, but our group is very Agile. Instead of siloing my projects, I participate in the actual development projects as a member of the scrum team, even if it's off and on throughout the project. What I really appreciate is that Scrum and ID go hand in hand - Sprint 0 activities fulfill most of my needs analyses, the sprints allow for review and reprioritization, and it all works very well.

Devriesj - a cool thing about Agile is that budget is taken out of the equation. That is left on the business side - if they want the feature, they pay for it. It's hard for them to swallow at first, but after a few sprint reviews, I've seem the BOs come around full circle. :)
Agile is definitely the way to go when coding for today’s busy, changing world. I’d be keen to hear your experiences, though, Megan. Does everyone adapt easily to the scrum mentality and the more immediate deadlines? Or do some coders and designers wish they were still very much in the ADDIE world?
It seems to me that one source of trouble with managers (and I used to be one) is that they want to buy a box of training. In their mind, what they are buying is a finished product. Because of the way managers are compensated in most companies, this is how they manage risk. One course = one box = $x, and the $x is what they have in the budget. If they come in under or on budget, they get rewarded, or at least they don't get hurt. If they come in over budget, they have trouble. In actual fact, what the manager is buying is the entire production process and the finished deliverables. It's more like buying a custom-built house than buying a box of cereal. This is a conversation that needs to take place during the negotiation with the client, whether the developer team is in house or contractors. csowar is right, they don't like that very much, no more than a home buyer likes it when the master contractor says, yes, we can give you travertine floors instead of carpet, but it will add $25,000 to the cost of the house. It is totally necessary to have all of the people who can say "no" or make your life difficult in the conversations that determine scope, and have all of them sign off on the final agreement, including the understanding that scope changes after this mean changes in cost, and that is management's problem, not the development team. As csowar said, they want it, they pay for it. The development team's problem is delivering what they said they would deliver, when they said it would be done, and at the agreed cost or less.

And of course, simple as this is, it is never easy.
@devriesj, we have a number of clients with fixed budgets - government projects, grant-funded projects, etc. We will typically estimate and give a rough budget, then manage to it through each iteration. It's a slightly different mindset, but our fixed budget clients come to appreciate it. Oh, and they especially like the fact that if we come in under budget, we don't charge them for the hours not worked so they SAVE money, which they rarely get to do.
@Bill1, I love the home construction metaphor. And, you're right, this is all a constant communication thing. We call it "full contact project management."

Here, I'll share my home construction metaphor. (and it's a true story!) The client doesn't know what they want until they get close to it - and you do that with iterations. When I looked at our house plans in 2D design drawings and room layouts, I placed all sorts of kitchen cabinets in. Thank goodness the cabinet people wouldn't put our order in until we had the room framed and drywalled so they had exact measurements because there was a big beautiful oak beam right where I was about to put a double decker lazy suzan corner cabinet. Of course, I didn't even SEE the beam (which I had wanted) until we had the room framed in. I didn't realize I was asking for 2 conflicting features.
@devriesj, yes, purchasing people don't know what to do with this. It's tricky. We tend to write statements of work as vaguely as we can.
Related Articles