Why you should be doing agile L&D development

Agile, iterative, successive approximation… There are many terms that broadly encapsulate the same concept: agile L&D development, or the delivery of small incremental value-add to your business through an iterative approach. Here’s why you should be agile too.

Life is agile

We have all heard someone complain about a specific goal being “a moving target”. Usually, this type of complain implies that it is not worth pursuing such goal. But the reality is that almost everything today is a moving target. In fact, the targets that are not moving are most likely the ones not worth pursuing. In an organization that strives for continuous improvement, everything, including learning, is a moving target.

And with that comes the realization (deep down you knew all along) that your learning design will never be “finished”, and that you may have to work towards the goal in small but usable increments. Courses, workshops, elearning, blended learning solutions that are launched frequently, incorporating minor additions and changes as you learn from them. Welcome to agile L&D development.

Once restricted to the realm of software development, agile has found supporters in many activities involving design. There are many good introductions to the concepts relating to agile development, such as Leandog’s discussion guide.

Agile, in short

But a frequent, usually off-putting feature of agile literature (at least for us in L&D) is the fact that it focuses on software design.

So if you are not inclined to read that 100+ page ebook, or a similar one, here’s the essence as it relates to learning:

• Work with your team and your learners, not with documentation and processes
• Aim to design and create the smallest learning solution that solves the problem
• Launch it and ruthlessly collect and analyze feedback
• Refine the solution, informed by the feedback you get
• Launch revised solutions as soon as you feel they address enough previous feedback to add new value
• Constantly seek ways to remove non-value steps so you can cycle through the above as fast as you can

In practice

How this looks in practice depends on many factors. For example, classroom solutions lean themselves to quite frequent iteration. In fact, you could revise the material and delivery script after reading the survey from each class. In teams, it gets only slightly slower. The way I have done rapid iteration of classroom solutions within a team involves:

• a common storage location in the cloud
• a standard way of documenting changes
• a regular video conference to coordinate changes

In practice, your personal delivery kit will be somewhat off sync from the central repository, since you need time to fully assimilate changes made by others before being able to incorporate them in your own sessions.

Blended and elearning solutions are somewhat less agile in that there is a production and deployment process involved that may cause too much overhead if done frequently. Still, adopting an agile methodology will help the L&D team be more nimble, launch solutions faster and keep them fresh and topical over time.

It’s easier than it looks

When thinking about implementing agile practices, the L&D field has some important advantages over the software field.

Perhaps the most important one is prototyping. It is generally much easier to prototype a learning solution than it is to prototype software. This applies both to classroom and elearning. There are many approaches and techniques to quickly create useful prototypes for the purpose of testing an idea, visualizing the solution or requesting feedback from customers (learners).

When it comes to elearning, we also enjoy the same benefits of the software world. Particularly, practices like A/B testing, where a small portion of the learners are shown a different version of the elearning so we can study their reactions and feedback. Many software companies are constantly in A/B testing mode.

There are also great low-tech approaches to gathering feedback and understanding the business, the learners and their needs, and quickly incorporating these insights into the agile development cycle.

It’s easier than it looks because the key, as in any agile practice, is not so much the technical ability or tools used by the L&D team, but their grasp of how agile can help in their specific environment and their ability to work together to deliver that promise. Actually, if you are leading an L&D team, a good conversation starter is reading the Manifesto for Agile Software Development but placing the word “Learning” whenever you see “Software”.

When to do agile

Of course not every learning solution is an ideal candidate for agile. For example, solutions with short shelf life or those where participants are getting externally certified and consistency across groups, industries and countries is expected.

But there are many other areas where I have seen or practiced agile development of some sort, including:

• Employee onboarding. I consider this the perfect scenario in large companies or those with high turnover. As this post suggests, it’s hard to get it right; iteration becomes your friend
• Role-specific training. This is a great example of a “moving target”, as the learning solutions must quickly adapt and support the company’s talent strategy
• Compliance and other courses that must be repeated over time and for every new hire

Time to park ADDIE?

Probably not. Although it’s time to look at ADDIE not as a flowchart or fixed set of rules, but as a set of principles. The principles that guide ADDIE are solid. But it is easy to be slowed down by the waterfall approach that is traditionally applied in ADDIE. If you’ve only worked on ADDIE models, experiencing agile L&D development will change the way you think about learning solution design.