Agile Learning Development in L&D

Agile, iterative, successive approximation... There are many terms to define it, but let me call it agile L&D development: delivering small incremental value by using an iterative approach to the design of learning solutions. Here is why you should consider agile too.

Life is Agile

A project did not go according to plan, and someone complains about a "moving target". Sounds familiar? But almost everything today is a moving target. In fact, the targets that are not moving are most likely the targets not worth pursuing. In an organization that strives for continuous improvement, everything, including learning, is a moving target.

And with that comes the realization that your learning design will never be "finished", that you may have to work towards the goal in small but usable increments. Learning solutions that are built gradually and launched frequently, incorporating additions and changes as you learn from the results. Welcome to agile L&D development.

Agile, in Short

A very discouraging aspect of agile literature (at least for us in L&D) is that it comes from and typically focuses on software design.

So if you are not inclined to read any of the resources available on agile, here is a summary as it relates to learning design:

• Work with your team and your learners more than with documentation and processes
• Aim to design and create the simplest learning solution that solves the problem
• Test it or launch it and ruthlessly collect and analyze data
• Refine the solution, informed by that analysis
• Launch revised solutions as soon as you feel they add new or better value
• Constantly seek ways to remove non-value steps as you repeat the above

In Practice

How this looks in practice depends on a few factors. For example, classroom and webinar sessions are easy to test in small chunks and allow quite frequent iteration. In fact, you could revise the material and delivery after reading the survey from each class. When more than one person delivers the same session, common storage, versioning and regular meetings allow a similar pace of iteration.

For video and elearning, finding new ways of prototyping and testing solutions will avoid the overhead and expense typically associated with the production of "finished" solutions. Eventually, an iterative approach to prototyping and testing will let you to find the right investment level, based on the data collected along the way. Iterating will most likely redefine what "finished" means in your context.

Is every learning solution an ideal candidate for agile? Probably not. Solutions with short shelf life, and those where external certification or other dependencies require consistency across groups, industries or countries are probably out.

But I have practiced agile learning development in other areas, including:

• Employee onboarding. A perfect scenario where the stream of data is constant and the needs of new employees easily fall within the "moving target" category
• Role-specific training. As talent, technologies and best practices evolve, so does role-specific training. Never static, never boring, role-specific training is usually a great candidate
• Compliance and other training that must be repeated over time and where there always seems to be some extra room for improvement

So... Time to Park ADDIE?

Adoption is not like a switch that only has "On" and "Off" positions. If you are with ADDIE today, consider the gradual, selective adoption of agile where it makes sense. I use "gradual" and "selective" in a broad sense, where you could, for example, pick only parts of a learning solution, and only a small number of individuals of the L&D team to try agile development. This approach will let you find -incrementally, and with data to back it up- what works best in your context and for the needs of your organization. There is no fixed way of applying agile. In fact, there may be as many flavors of agile as teams practicing it. The trick is that rather than sticking to a set of processes, they stick to a set of principles.