Rapid Training Development the Agile Way

By Jay Lambert

If you've developed a learning program for software, at some point or another you've likely had to develop training before the software itself was even ready.

It was this very scenario that Teresa Teirney and her associates at Nationwide faced.

As with many (read most) technical training projects, Nationwide started developing training modules before any system content actually existed; but in a flash of inspiration, they decided to try using Agile development methodologies during the instructional design and development process. The goal was to minimize the amount of re-work typically associated with these projects.

Teirney spoke about the process they followed in her session 'Agile Instructional Design & Development' at the recent Lectora User Conference 2010.

As defined by Wikipedia, "Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams."

These requirements and solutions are typically tracked on a "story wall" that constantly changes as the project progresses. The story wall might be a literal wall of post it notes or might be virtual.

Decision making focuses on what is vital to keep the project moving. Studies show Agile reduces both development time and scope creep; clients on an Agile project typically accept what is necessary and ask for fewer extras.

Think about that - training only on what is necessary. We all should be big fans of that. (See an earlier post on this blog, Pointing to the Five Moments of Learning Need.)

One way this 'training only on what is necessary approach' is accomplished is by commitments being made at the last responsible moment; as the project progresses, this tactic reduces re-work in two ways. For one thing, the last responsible moment in a system training project should mean that the system being trained is final; you'll have fewer edits to an eLearning module developed for a stable software system than you will for one still in development itself. And then of course, the last responsible moment implies that limited time is available; limited time means no time to add the "nice to haves" into your training.

Following Agile means identifying and reacting to rapid change. How rapid depends, but Nationwide chose a 3-week iteration for their development cycle. As Teirney put it, "think 'what can I produce in 3 weeks that will be helpful?'"

At its essence, Agile is simple evolutionary design; get enough out to be useful, then come back and improve it. And sometimes you'll find that what you initially thought to be useful is all you really need.

Accordingly, you should start with the simplest thing first and build from there. So Nationwide started with job aid development. Over the course of the full project, they added podcasts, coaching cards, asynchronous eLearning modules, and classroom-style workshops led by subject matter experts (SMEs).

As a best practice, Teirney said that SMEs must understand and commit to involvement for the life of the project. (Really this applies not only to Agile, but also to any significant training project.) As situations come up, the SMEs must be actively engaged in order for the Agile collaborative decision-making process to work.

Interestingly, Nationwide didn't restructure their learning organization for the Agile test. But Teirney was quick to point out that, "there is an organization cultural change that comes along with it."

For starters, Agile development requires close working proximity; if yours is a virtual or geographically-scattered team, then you must still replicate the close proximity environment somehow. Agile requires teamwork and heavy communication and collaboration, not only amongst the development team, but also with the customer. Communication, Teirney stressed, is vital.

And because it involves change and iterative development, Agile requires significant attention. If you try its methods, you must stay on top of the current state of both the subject matter and the training you are developing for it.

As it turns out, we've been following many practices Teirney suggests for some time in our technical training projects. We've just never called them Agile.

How about you? How do you approach projects when the instructional design and development must be completed in conjunction with development of the training matter itself?