Have you ever been part of an eLearning development project in which waterfall management (ADDIE) was the designated approach? This is not at all unusual, and neither are the difficulties you may have encountered in dealing with client- or management-imposed changes in objectives, scope, and content during the project. You may know that for the last 20 or so years, software and eLearning design and development professionals have advocated for a change to Agile methodology, and you may have learned from experience that making this change can be challenging. Why should this be, and is there a way to overcome objections from clients and from your own managers? This article will explore the reasons, an idea for handling the objections, and a path to success.

ADDIE and Agile: Risk mitigation

ADDIE is intended to achieve predictability and to minimize risk, as well as to standardize development. ADDIE began decades ago as an adaptation of engineering and accounting practice. Waterfall assumes that risks can be known and managed. This assumption is reflected in the methodology: a linear, structured approach to project management. ADDIE is made up of a series of steps to be completed in sequential order within the development. The first step consists of generating detailed upfront documentation between the development team and the client or end-user. During this phase, the product features within the project plan are documented in great detail, enabling the team to determine a clear cost and timeline. After both parties sign off on the requirements, there may be limited to no correspondence between the development team and client until the project is completed.

IT and software development professionals (including those of us in eLearning) are coming to a different view and a different approach that ideally will make better use of our expertise: Agile. Development experience has taught instructional design teams that customers (the clients and organizational managers) often do not know what they want in terms of a product.

Sometimes it becomes obvious that what clients want is a "pair of hands" to take the order and build the solution that management expects: for example, "We need a two-day course on communication skills", with no more detail or documentation than that. Glossing over the first step of the waterfall can be a sign that the process is not going to be a happy time for the instructional development team. When the instructional design team begins to ask questions about the details, they may be said by the stakeholders to be stuck in "the paralysis of analysis" and the client representatives may complain that they have no time for this. Or the client representatives may turn out to be uninvolved or uncommitted to definition of the outcome. In an article comparing waterfall and Agile, IBM program manager Eda Kavlakoglu identifies how these shortcomings affect the process and the outcome:

  • Clients can find it difficult to outline all of their requirements at the beginning of the project, leading to gaps in documentation.
  • Minimal customer collaboration during the development process can lead to costly changes if the product does not meet expectations.
  • Testers report issues and bugs later in the process, which could have informed an alternative program architecture.

Even in the best of situations, waterfall methodology can lead to these issues. This article is not a criticism of waterfall methodology, and in fact, successful projects and products have been developed with waterfall and with Agile methodologies. They have similarities. Each one has advantages, but the energy behind Agile methodology has been building for about the last two decades.

Agile was developed to take a different route to risk mitigation, defined by an iterative approach to project management. An Agile team begins by identifying specific product features, instead of drafting lengthy project requirements. The team addresses each one under a specific time constraint, known as a sprint.

Agile project management teams are cross-functional, self-organizing groups of five to nine members. In each sprint, the team develops a workable piece of the product, and combines it with other functional pieces from previous iterations. At the end of the sprint, the team demonstrates the result to stakeholders for feedback. This frequent feedback gives the team flexibility to adapt the product roadmap during development, ensuring that functionality meets user expectations.

There are a number of popular Agile frameworks, such as Scrum, Kanban, Feature Driven Development (FDD), and Extreme Programming. It is important to remember that "Agile" is not any of these frameworks, and that when applied to eLearning development, Agile will not resemble in detail the way that it is applied to software development. It is the application of Agile principles in the context of a supportive culture that makes the difference.

In either approach, you need a champion

As with any project management methodology, leadership is important. And as in many human activities, there are leadership roles that are named and defined: these are formal leadership. There are also informal leadership roles that are less structured. Depending on organizational size and culture, in eLearning development projects there may be both kinds of leaders.

One of the most important steps in organizing an eLearning development project is to include a designated product champion and to learn to use the power that person brings as facilitator and coach. This is often one of the informal leadership positions.

In nearly every eLearning project, the project champion role is critical to success. This may be a formal role or an informal role. The project champion may be someone on the project management team, or the project champion may be a senior manager who is not on the team but coaches team leadership, helps to obtain management support, and generally facilitates the team's work.

No matter how the roles are structured or which methodology (waterfall or Agile) the team is using, the presence of a project champion makes a huge difference to the outcome. The project champion is the one person who makes sure that everyone is on board with the project goal. At the same time, the project champion is not the ultimate decision-maker and may not even have much formal power in the larger organization. But project champions have four things that make them essential:

  • Credibility
  • Connections
  • Company intelligence
  • Motivation

The activities and outcomes for the project champion may include involvement in and communication of:

  • Identification or clarification of the project's strategic objectives
  • Translation of the project vision into requirements and solution design
  • Ensuring best practices
  • Identifying and eliminating obstacles
  • Prioritizing project phases based on value
  • Relaying timely updates
  • Ensuring successful completion and implementation of the project

There are some differences between definitions of the project champion role and responsibility under each methodology. It may be more usual in some organizations, depending on culture or size, for the champion to be a more senior manager or executive, even designated as the project owner. In other organizations, the champion may be designated by name, or not.

Especially in Agile teams in organizations that are small, project champions may not have obvious formal power, due to the cross-functional, self-organized nature of the teams. But they are no less essential.