Earlier this year, I worked with a teammate to do a presentation on agile for instructional designers. It was a fun presentation to prepare for and also learn some things along the way. We used the book Agile L&D by Nadal Dank to read up on the topics and, of course, use our own experiences.
One of the things I thought would be fun for the presentation is to provide as supplemental material a translation of the Agile Manifesto for instructional designers. I think it’s a good way to put the goal of agile into context, making it more relevant to instructional designers.
Creating training and helping adults learn isn’t the same as developing software, and the goals are not the same. I approached it from the lens of the goal for each. Software developers serve the business by creating something they believe is valuable, and the customer’s satisfaction typically measures their success. That’s why the NPS score is so popular and widely used for software.
However, instructional design isn’t about making people happy (though it could, of course); it’s about helping them learn something or perform their job more effectively. That’s why I felt it necessary to translate some of the items of the Agile Manifesto. Some of them worked perfectly fine out of the box. Others required some adaptation to make them suitable for instructional design and training purposes.
Learning and development shouldn’t use the NPS score, as it tells us nothing about the success of training. OK, people like it, what does that mean? Nothing.
So, here’s what I came up with for the translations, and I’ll notate where no change was needed.
| Agile Manifesto for Instructional Designers | Original Agile Manifesto |
|---|---|
| Our highest priority is to help teammate learn the technology they need to do their job through continuous delivery of effective training. | Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. |
| The most efficient and effective method of conveying information to and within a development team is meeting in real time. | Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage |
| Deliver effective training frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale. | Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. |
| Project owners and developers must work together daily throughout the project. | Businesspeople and developers must work together daily throughout the project. |
| Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. | |
| Effective training that prepares teammates to do their work more efficiently is the primary measure of progress. | The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. |
| Effective training that prepares teammates to do their wperformk more efficiently is the primary measure of progress. | Working software is the primary measure of progress. |
| Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. | |
| Continuous attention to teammate excellence and learning design enhances agility. | Continuous attention to technical excellence and good design enhances agility. |
| Simplicity–the art of maximizing the amount of work not done–is essential. | |
| The best architectures, requirements, and designs emerge from self-organizing teams. | |
| At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. |
That’s it! You can see most of the items on the manifesto are fine the way they are. Even those that needed changing, often the change was a minor tweak. If you want to learn more about the Agile Manifesto, there’s a whole website with a lot more information.
The Unnecessary Need for More Agile Models
Part of the presentation also covered unnecessary models that everyone has come up with that are agile ways of working for instructional designers. The thing is, we have a perfectly good model that is agile at its core. I think others want to create models to bring people over to their business and promote themselves.
They’re all unnecessary, though. Yes, that means SAM, LLAMA, et cetera et cetera ad nauseam. People in learning and development seem to like creating unnecessary things. Have you noticed that?
However, ADDIE is a perfectly fine and agile model if used correctly. It was never meant to be a waterfall approach, and it works just fine. I modified the traditional ADDIE flow to be agile by starting with Analysis, then cycling through Design, Development, Implementation, and Evaluation.
It’s as easy as that. Sometimes Analysis can even be part of the cycle, too, if you need to re-analyze something. The original way ADDIE was presented was as an actual cyclical model. It was intended to progress through all the stages, circle back, start over, and take any necessary steps to achieve a successful end product.