[updated from the original publication on July 2, 2019]

According to research by HP, agile has overtaken Waterfall as the prevailing software development methodology. This shift is something we’ve experienced first-hand. Several clients have adopted or are in the process of adopting agile as a cultural model and way of doing business – elevating its place, shifting its meaning, and deepening its pervasiveness. 

What does this evolution mean for the learning and development teams creating and delivering training?

First, a Simplified Snapshot of Waterfall and Agile in the Context of Software Development

Waterfall software development attempts to understand all or most things early on and then make minor, incremental adjustments along the way. This approach often includes a robust charter (usually a large document in and of itself) with 

  • An attempt at a precise, predefined scope

  • A complete or nearly complete list of business and technical requirements (often heavily negotiated)

  • An end-to-end project plan with structured phases and robust decision gates

The waterfall development process is often linear, following the familiar phases of designing, developing, testing, then deploying software. At the end of the project, the team delivers a complete or nearly complete software package. 

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 methods, routines, practices, and behaviors live 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, deploying the final software product feature set by feature set. When done well, processes are robust, flexible, and fast. Documentation is thorough and provides a trail of evidence connecting personas, user stories, feature descriptions, feature backlog and priorities, sizing, and more.

Here are five things we’ve learned from our involvement in agile development projects.

1. Learn Your Organization’s Version of Agile 

We’ve been part of numerous corporate agile projects and have partnered with software development firms to deliver training solutions supporting their agile projects. Those experiences taught us that while the agile deployments we’ve seen adhere to the tenets of agile, each project is unique. 

Request time with the project manager (or whoever knows the ins and outs of the situation) to learn about the approach, processes, roles, and definitions used in the project (e.g., personas, user stories, ceremonies, sizing, prioritization, refinement, etc.). 

It isn’t necessary to become an expert in agile, but it is helpful to become conversant in the language, be aware of the processes and how they work, and know who fills essential roles. 

Additionally, talk with the project manager about documentation. We’ve seen the quality and completeness of backlog, user story, sizing, feature, and other documentation vary considerably. The variation shows up between projects in the same organization and from team to team in the same project. Additionally, as a team becomes more familiar with the project, the features, and the other team members, a shorthand often emerges; consequently, the quality and completeness of its documentation can drop. 

2. Get on Top of the Release Plan 

Generally speaking, Waterfall delivers software at the end, while agile might deliver software sprint by sprint, in increments, in a group of features, or at the end. In addition, agile teams will often organize release plans to serve business priorities (and feature complexity):

  • By sprint: releasing a feature approximately every sprint (about two weeks).

  • By clusters of features (sometimes called an increment): releasing a group of features together (often 8 – 12 weeks).

  • 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.).

L&D must know the release plan because it 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 restrict modality options, taking some off the table entirely. 

Parenthetically, the release plan appears to significantly impact incumbent employees, who will experience the changes roughly in the same cadence as the release plan. For new hires – or future new hires – a feature set, often defined by what is available at a particular point in time – becomes the foundation and focus of the training.

On the other end of the release 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 ample time to develop training for features created early in the sprint cycle and less time for features built near the end.

3. Agile is Adaptable, so 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. As a result, the planning horizon is comparatively short, often only a few sprints into the future (keep in mind, a sprint is typically two weeks). The team prioritizes, sequences, and sizes upcoming backlog items during each refinement cycle. This process encourages the team to discuss business goals (which can mean revisiting goals previously discussed, documented, and agreed), take note of any shifts, and, when necessary, make trade-offs, all of which ensure that prioritization is sensitive to business needs.

Agile decision-making’s fast-paced and evolutionary nature can challenge L&D to stay tightly aligned with the business. As a result, an initial understanding of goals generally won’t stand the test of time or the pressures of ongoing agile processes. Nevertheless, 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.

4. The Analysis Opportunity and Challenge

Under the agile approach, software development teams understand the requirements 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 – perhaps typically is a better descriptor – 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.

5. Design Considerations

No matter the software development approach, L&D is on the hook to create effective and timely training and support. It is incumbent on training professionals to use research-based practices when designing, developing, and evaluating instruction. In addition to the research, here are a few considerations related to an agile scenario:

1. Release Plan

Under a sprint-based release plan, there often isn’t enough time to develop training in modalities that require more lead time, such as eLearning. We’ve seen stakeholders – inside and outside the agile process – expect and request modalities that don’t fit the situation, need, or timeline. Educate, coach, and reinforce expectations with stakeholders. Help stakeholders understand how instructional design processes depend on agile process outputs and the release plan (and perhaps provide tools like a decision tree for transparency). Left unmanaged, the disconnect between stakeholder expectations and reality can cause project challenges. 

2. Target Audience

It’s essential to recognize the different needs of new hires and incumbent employees. In most scenarios, L&D needs to introduce new employees to nearly everything. For example, they need to learn appropriate and realistic scenarios, basic software functionality, and when and how to complete work tasks. You can use more systemic, programmatic designs and more complex strategies, including blended learning, to significant effect.

For incumbents, skill or knowledge gaps may be small. L&D can leverage existing knowledge and use highly targeted content, packaging it in job aids, decision guides, or “show me” videos (in short, providing resources that incumbents can access instead of needing to rely on memory).

3. Training May Not Be Necessary

In some cases, L&D may not need to pay attention to some releases. Training may not be required when the feature is minor or occurs entirely in the “back office.” Follow a repeatable decision-making process with the product owner and SMEs to determine whether users 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 protects the end-user.

5. Sunsetting Training

Good software design and deployment – where the software addresses realistic user stories and employee needs, has an intuitive flow of work, and where the UI/UX is easy to learn and follow – often replaces or eliminates work processes and tasks. The knock-on effect can be that training is no longer needed and should be removed from circulation. 

Like the decision tree mentioned above, developing and implementing a decision-making process can improve transparency regarding what to remove, when to remove it, and why, guide decisions about changing adjacent or neighboring modules, and ultimately reduce time wasted on unnecessary training. 

As the HP researchers wrote, “agile is the new normal” in software development – and we’ve seen instances where organizational leadership uses agile as a conceptual and operational framework. There isn’t one form of agile, so adapting to its processes and velocity can be challenging. 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 minor adjustments to your design and development processes.