As we enter the New Year, I keep having the feeling that all the shiny, brand new objects in the learning world are just today’s reinterpretation of all the right stuff that we’ve been doing all along. A cynic would say that somebody else is getting all kinds of credit for inventing something that really isn’t new, but in the spirit of the New Year, I think I’ll choose to be excited that I can bring so much existing life experience to these “brand new” trends.
There’s been a lot of buzz lately about applying the principles of Agile software development to the creation of training. For those of us who are new to this, the Agile movement began some 15 years ago in the form of an Agile Manifesto based on four values:
- Customer collaboration over contract negotiation
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Responding to change over following a plan
The manifesto then went on to outline 12 principles for the creation of software that support these four values. Although these principles are focused on software development, they have a lot of relevance, and those of us who have worked with clients over the years will recognize many of these principles come out of good consulting practices:
…the highest priority is to satisfy the customer early with valuable deliverables…
business people and developers must work together…
build projects around motivated individuals…
continuous attention to technical excellence and good design enhances agility…
simplicity is essential…
If we are good at what we do as performance improvement and training professionals, these principles are built into our standard approach. We include analysis and design deliverables to provide the customer with an early vision of our proposed solutions. We get business input in solution design and approval to ensure we positively impact the business. We engage stakeholders and team members around a vision for success and motivate and equip them to effectively do their jobs. We use prototypes, documentation standards, and a QA process so content is technically accurate and well-designed from the onset. And most importantly, we identify outcomes of value for the business and then design our solutions to produce those outcomes in the simplest, most effective, and most cost-effective way possible.
But other Agile principles aren’t as evident in the training world. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Personally, I struggle the most with this one. How do you deliver a solution on time and on budget when welcoming changes late in development? I think the solution here is to align early and often and to plan development around possible changing requirements. For example, we often work with clients to develop training on new business processes and systems that are being implemented. In planning development of these solutions, we align early in the project on which elements are the most “baked” and which ones are still being figured out. Then we start development on the baked areas and save the unbaked ones for later. Equally important, we try to maintain flexibility when changing requirements come up, and by having a detailed development schedule and understanding our development metrics, we are almost always able to incorporate the changes without negatively impacting our budget and final delivery schedule. And of course, when in doubt, we always refer back to Agile value number one: customer collaboration over contract negotiation. Keep that in mind and everything has a way of working out.