According to research by HP, agile has overtaken Waterfall as the prevailing software development methodology. What does this finding mean for the learning and development teams creating and delivering software training?
First, a Simplified Snapshot of Waterfall and Agile Development
Waterfall software development attempts to understand all or most of an effort up front, often including a charter and predefined scope, a complete or nearly complete list of business and technical requirements, an end-to-end project plan, structured phases with decision gates, and robust processes and tools. The team delivers the software product at the end of this process.
Agile approaches software development from a fundamentally different mindset, emphasizing “adaptive planning, iterative & evolutionary development, rapid and flexible response to change [and communication],” according to an article by researchers from the Guru Jambheshwar University of Science and Technology.
The hallmark of the agile approach is adaptability. A wide variety of approaches, routines, practices and behaviors have been developed and introduced under the agile umbrella. Depending on how a team implements the agile approach, it can deliver minimally viable software quickly and build it feature by feature from there, delivering the final software product bit by bit.
Here are a few lessons we’ve learned from our involvement in agile development projects.
There Isn’t One Flavor of Agile
When you’re supporting an agile development project, set aside some time with the project manager (or whoever knows the ins and outs of the situation) to learn about the approach, processes, roles and definitions he or she is using for the project (e.g., personas, user stories, ceremonies, sizing, prioritization, refinement, etc.). We’ve been part of internal corporate agile projects and have partnered with software development firms as they delivered agile projects. Each project — and each approach to agile development — has been a little different from the previous one.
Understand the Release Plan and Implications
In general, Waterfall delivers software at the end, while agile might deliver software sprint by sprint, in a group of features or at the end.
It’s important to pay attention to the release plan, because it indicates how often you will put fully functioning software features in front of the end users. Teams can organize release plans:
By sprint: releasing a feature approximately every sprint.By clusters of features: releasing a group of features together.By a complete product: releasing fully functioning software (In effect, this approach is a mash-up between agile as a development method and Waterfall as a release model.).
The release plan will affect L&D processes and decision-making. For example, a sprint-based release plan will limit the amount of time L&D has to design and build content — particularly for incumbent employees — which may eliminate modality options.
On the other end of the spectrum, releasing a complete product is akin to releasing under Waterfall, where the team delivers software at the end. In this case, L&D likely has time to develop training for features developed early in the sprint cycle and less time for features developed near the end.
Business Goals Aren’t Always Durable
In our experience, when the software team is using an agile model, it builds in frequent discussions of business goals. The planning horizon is comparatively short, often only a few sprints into the future (typically a sprint is two weeks). During each refinement cycle, the team prioritizes, sequences and sizes upcoming work. This process encourages the team to discuss business goals, take note of any shifts and, when necessary, make trade-offs, all of which ensures that prioritization is sensitive to business needs.
The fast-paced and evolutionary nature of agile decision-making can challenge L&D to stay tightly aligned with the business. Initial understanding of goals generally won’t stand the test of time or the pressures of ongoing agile processes. Successful training professionals find ways to stay engaged with the agile process to understand how the goals of each stakeholder play out during prioritization and sequence decision-making.
The Analysis Opportunity and Challenge
Under the agile approach, the software development team captures its understanding of the end user through personas, user stories and other mechanisms. An agile team’s analysis is generally sufficient to help it address technological needs, but its work is often insufficient for L&D to identify and understand gaps in performance, knowledge or skill requirements.
To ensure training targets the right skills, L&D can take advantage of available data and make minor adjustments to its analysis processes to leverage agile documentation, participate in the sprint ceremonies or join the team, and engage with subject matter experts (SMEs) differently.
Design Considerations
No matter the software development approach, L&D is on the hook to create effective and timely training. It is incumbent on training professionals to use research-based practices when designing, developing and evaluating instruction. Here are a few considerations:
1. Release Plan
Under a sprint-based release plan, there often isn’t enough time to develop training in modalities that require a long lead time. Keep it short, simple and effective.
2. Target Audience
It’s important to recognize the different needs of new hires and incumbent employees. In most scenarios, you need to introduce new employees to nearly everything. For example, they need to learn appropriate schemas, basic software functionality, and when and how to use it when completing work tasks. You can use more systemic, programmatic designs and more complex strategies, including blended learning, to great effect.
For incumbents, where the skills or knowledge gap may be small, you can leverage their existing knowledge and decide to use highly targeted content, packaging it in job aids, decision guides or “show me” videos (in short, content that they can access instead of needing to rely on remembering it).
3. Training May Not Be Necessary
In some cases, the feature the software development team is releasing is minor or occurs entirely in the “back office.” In these cases, training may not be required. Follow a repeatable decision-making process with the product owner and SMEs to determine whether users will need training.
4. Change Fatigue
Under the sprint release plan, the constant drip of new features and associated training can be exhausting. The agile team is in place to develop software; sometimes, the L&D professional is the one protecting the end user.
As the HP researchers wrote, “agile is the new normal” in software development. There isn’t one form of agile, so it can be challenging to adapt to its processes and velocity. As an L&D professional, you can start by learning how your organization is using agile development, figuring out where and how to unobtrusively plug into the process, decluttering and accelerating decision-making, and making small adjustments to your design and development processes.
