Is Agile Methodology Lipstick on the Training Pig?

Short answer: It could be!
Longer answer: It could be if the primary reason to pursue an agile methodology is to gain rapid development benefits as the primary outcome.

Having participated in several “Agile” breakout sessions at DevLearn and Learning 2013 late last year, it became clear to me that old training paradigms never really die; we seem to just dress them up with a couple coats of new jargon. It’s kind of like calling “training” by a different name…something like “learning” and yet we still grind out courses in virtual blends and deliver through massive venues expecting the results to be different. While we may derive some incremental improvement, how could results ever really be step-change different when we’re still focused on effectively transferring knowledge?

I know that may have sounded a bit harsh, but please understand that there is nothing wrong with transferring knowledge…if that’s all you want. We say we want to improve performance through training, but we do not use a design methodology that targets the business performance objective(s) serving as drivers behind the training/learning effort. One would hope that somewhere in the training request dialogue there were explicit performance outcomes discussed and identified that serve as evidence of business impact. If not, all we have left to shoot for are learning objectives, and meeting those requirements do little to sustain workforce capability. If you are not having these kinds of conversations with your stakeholders, step away from “agile” because all you’ll get out of the effort are the same training assets…a little faster. We must get beyond that paradigm.

Usually there are inferences to improved performance, but too many times we do not accomplish the diligence of discovery to acquire them. The concept of “performance” still defaults to the context of learning objective gates that confirm we successfully transferred the knowledge identified by a training needs assessment. Again, nothing wrong with that either, but that assumes training was the only solution. An agile methodology, when properly integrated, should confirm what mix of learning AND performer support assets are required in the solution. Our training paradigm was never designed to go there because discovery is narrowly focused upon knowledge…not capability at the point of work.

An agile methodology should evolve the context of discovery. So what does “discovery” have to do with an agile methodology?  Ummm…how about everything? Step away from the concept of discovery for a second and consider the context in which it is accomplished; and not just the context, but the scope of the context.

The scope should be expanded to cover the business’ Learning & Performance Ecosystem. Yup, jargon; but “ecosystem” is meaningful and relevant jargon because it points to a larger context that encompasses where our workforce LEARNS and WORKS…and where they work is where PERFORMANCE reigns supreme and tangible BUSINESS IMPACT is generated…or lost. This is the context…the expanded context… that becomes the target of our evolved discovery efforts.

By bringing performance expectations and business outcomes into the mix, we exceed the scope of the training paradigm and design and development of solutions fall short. We are faced with supporting Performers in the context of their work. Training was never intended to accomplish that kind of support. More specifically, we are in need of understanding what are the role-specific, task-centric actions a Performer is going to be expected to execute flawlessly to generate business value…and if they do it flawlessly, what’s it worth to the business? And if they screw it up, what does it cost the business? To me, answers to those questions point to an essential aspect of any “agile” methodology.

So…what do you want from an agile methodology? Here are several things I believe are going to be important to consider:

• Rapid development – but not just training assets – the solution may be Performer Support only
• Discovery includes the performance context and outcome expectations; not just what learning objectives should be
• Role-specific, task-centric workflows are identified and mapped
• Collaboration with client to confirm and prioritize performance gaps
• Learning & Performance road-mapping targets and prioritizes assets for development
• Incremental asset design & development with deployment via technology – iterate based on a feedback validation loop
  • Storyboards may not be required – why bother if a job aid or two will do?
  • Training may shrink; if required at all. Training may be “what’s left” after performance has been adequately addressed.
  • Training that DOES take place should re-use the same performance assets developed and deployed earlier
• Performance data identified in Discovery is extracted to serve as evidence of business impact evaluated at levels 3 & 4.
• Rise and repeat – replicate methods, align a robust content management capability to manage and maintain content assets through object re-use and re-deployment as business needs change.

These considerations listed above are high-level for a reason; mainly, there are more ways to skin this agile cat. If you come from a software development background, you know the “sprint & scrum” workflow well. For me, this breaks down when trying to pack traditional training development cycles into this regimen. If sprints are a week, or maybe two in length, we all know how much training we can pump out when we’re quoting 8-to-14 week development window for an hour of e-learning. Traditional instructional design was never intended to be “agile” enough to deliver much of anything in a shorter “sprint” window.

What DOES work using the software world example is Training partnering with the business stakeholder [IT in the software world] and working collaboratively in an iterative cycle of incremental deployment, review, and refinement. The key is… “What are the increments?”  Learning assets? Performer Support assets? Both?

The answer to that question ultimately defines what your “agile” methodology is intended to support. What I fear can happen in the rush to agile instructional design is the shiny object syndrome that promises a path to rapid training development. Certainly rapid development benefits have business advantages to reduced development time and overall costs; but what about the “performance context”?  What about the Performer Support assets [job aids, quick references, etc.] that may have been deployed ahead of the formal training content and positively impacted business results weeks ahead of the final training project completion? And still we have to ask, “Was training development ever necessary in the first place?” Okay, am headed down the rant path again…sorry…it happens.

My caution is to not let the move to “agile” only become a cosmetic enhancement to an outdated training paradigm. Yes, we need to be agile, but more importantly we need to be INTENTIONAL. Let the methodology BE agile, but define the methodology by being intentionally focused on the performance context – the point of work – first and foremost.

Being rapid and off the mark [or short of the mark] with a rapidly developed training solution is not a benefit. We are beyond training, and the needs of the business have outgrown what training can deliver. With “do more with less” being top-of-mind these days, it is easy to see “less” realized through savings of time and money. I think we’d be better served if we adopted an evolved Learning & Performance Paradigm that focused on the “do more” instead. To be more specific, our agile methodology should equip our workforce to “do more” and to do it flawlessly…and if we do “agile”…intentionally focused on the point of work… right the effort may actually be “less”.

Here’s an additional thought. “Agile” should not be limited to a description of our methodology; it should also describe the capability we build into our workforce. The performance assets we build should be agile enough to support workforce agility and resilience to change. Content should be agile enough for re-use and re-deployment with minimal effort. Content should be agile enough to serve multiple audiences. Truly, it should encompass a greater scope that just training asset design and development.

My advice is to peel back the layers on whatever agile methodology you consider and make sure that beneath the cosmetics it does more than “oink!”

Gary G. Wise
Workforce Performance Advocate, Coach, Speaker
gdogwise@gmail.com 
(317) 437-2555
Web: Living In Learning
LinkedIn