L&D can deliver more by applying agile workflows

The seismic changes in the workplace brought on by the COVID-19 crisis have placed a responsibility for Learning & Development to step up and help leaders and workforces adapt. To do so, we need first to become more change-friendly ourselves.

ETU is in the privileged position of receiving input from learning professionals across many sectors and in all sizes of organizations -- and we often hear the same concerns repeated again and again. The change conversation is a ubiquitous one, but we also hear concerns about the efficacy of learning, the need for L&D to adapt more quickly to business needs, and the desire for a more flexible responsive learning service.

Better learning, more aligned to business goals, delivered faster. But how?

Is agile the answer?

To answer this, let’s take a look at the agile movement. The agile movement swept through software development in the nineties and noughties as a backlash to top down (waterfall) management and formalized project management. Agile came, it conquered, it even experienced its own backlash. Ultimately, it has matured into a useful way of delivering services that is also applicable outside of software development.

Agile’s roots go back many decades, but it was formally named at a meeting in 2001 in Snowbird, Utah, where seventeen senior IT professionals met to progress ideas on how to create better software faster. They were responding to widespread frustration over how long it took to deliver software. A common estimate at the time was that it took three years to get from a validated business need to a production-ready application. Something had to change. The output from that meeting, the Agile Manifesto, caught fire and became a movement.

That same frustration is evident today throughout the Learning and Development community. The increased sophistication and simplicity of design and development tools has significantly reduced development time. Evidence from the Association for Talent Development (ATD), drawn from a longitudinal study, shows that where ten years ago it took on average 525 person hours to create one hour of simulation-based learning, today it takes 142 (a 73% drop). To put it another way - one fifth of the time.

Learning delivery cycles remain stubbornly long

Despite reductions in the number of hours required to technically create a unit of online learning, the elapsed time from a business problem arising to having a learning solution in place has remained stubbornly high. Unfortunately, we’re seeing that it can still take a lot more than one fifth of the time to go from business need to finished product. That’s because the rate-limiting step is not the tools, nor skills. It is the inertia of internal processes and specifically poor alignment between line of business departments, and learning & development.

So is agile an answer? Paraphrased, the Agile Manifesto asserts:

• Make satisfying your customer your highest priority
• Welcome change requirements even late in the process
• Deliver working product frequently in short release cycles
• Work daily with the “line of business” people
• Build projects around motivated individuals and put your trust in them
• Prioritize face-to-face communication
• Make working product the primary measure of success
• Maintain a constant pace, and sustain it indefinitely
• Keep continuous attention on technical and design excellence
• Simple is better
• Promote self-organizing teams
• Learn to reflect on your effectiveness and feed the learning back

The Agile Manifesto is more ideology than method. Its principles are codified in methodologies such as Extreme Programming (XP), Adaptive Software Development, and perhaps the best known, Scrum. While these methodologies precede the publishing of the manifesto, each embodies the agile approach. Most development teams that claim to be ‘agile’ today use the vocabulary of Scrum: Sprints, Stand-ups, Stories, and Burn-down charts.

Software development methodologies don’t directly map to learning development; it’s better to focus on the inherent principles and adapt them. For instance, the underlying principles of Adaptive Software development - speculate, collaborate, and learn - continuous learning and adaptation through the content creation process, is made for L&D.

There is nothing in the Agile Manifesto that would be controversial to a learning professional. Most of us would recognize behaviors that we aspire to in our working lives. Translating aspirational abstract ideas into actions is the challenge. If you are new to agile, it can be difficult to know where to begin.

A good place to start

A good place to start is to know where you are at by calculating your baseline. How long does it take to evaluate a business need and decide to create learning to address it? How long does it take from the decision to create learning until it is business-ready? How responsive/aligned/relevant does the business perceive the learning team to be? Don’t beat yourself up with data: creating a simple, well-targeted set of data points is better than a deluge of data. Think car dashboard, not airplane instrument panel.

Baseline established, move to goal-setting: how much do you want to move your data points and by when? It’s also a good idea to step back and define why it’s time to go agile: “Better learning, more fit for purpose, delivered faster,” works for us, but feel free to create your own mission statement.

Armed with a mission statement, you then need to get your team and the business on board. Remember: agile methods are team-based and focused on serving the client or customer, so it’s important to get everyone on board from the start. In the spirit of team, a workshop is a better place to start than a declaration.

Team on board, create some rules to live by. Start fairly high level and you can deepen the new rule set with experience. For example:

• We collaborate with our end user through the entire project lifecycle
• We iterate our learning rather than documenting an end solution
• We create simple working versions of learning and iterate them with the end user
• We invite our customer to be on the team
• We prioritize individuals and interactions over processes
• We respond to change positively at any stage in the plan

Commit to all twelve agile principles from the Agile Manifesto and build out rules and behaviors around each. Halfway practitioners of agile adopt only the rules that suit them. Go all in.

Flexibility is key

Resist this trap by committing to flexibility; don’t become hard-wired to your new rules. Remember agile is about the ability to analyze, understand and adapt quickly, so don’t let your new framework become the new tyranny. If all you are doing is adding additional agile practices to the way you already do things, you risk driving your data points in the wrong direction and demoralizing everyone around you.

So now you are treating the business users as team members rather than arm’s length SME’s, you are trusting your team with goals and leaving them to work out how it gets done, you’ve replaced alpha and beta delivery with short iterative cycles, you’ve abandoned hard sign-offs in favor of living documents, and you have learning loops at every stage. Are you truly agile? Only if it’s working.

Remember that baseline. Go back and measure and survey again. Do you now have better learning, more aligned to business needs, delivered faster? It’s likely, but if not, don’t give up. If the business is open to continuous learning and adaptation, you must be too. ETU’s advice is ‘change just one thing, get it embedded and change just one more’. Become an agile team one step at a time.