1.1.4 Waterfall and Agile

There is a spectrum of project management and system development approaches available for projects to choose from, anchored on either ends by the predictive waterfall approach and the adaptive agile approach. To better describe the ends of this spectrum, the following sections will compare and contrast key characteristics of agile with the more familiar aspects of waterfall. The table below identifies the characteristics that will be explored and summarizes the difference between waterfall and agile approaches.

Scope and Resource Management

With waterfall projects, requirements are developed and thoroughly documented in project planning in order to come up with a fixed scope. Resource and time estimates are generated based on the fixed scope and are tracked and managed throughout the project. As the project goes through the development phases and new information identified necessitates a change to the scope, the project goes through a structured change control process and resources and time are adjusted accordingly.

As shown in Figure 1-1, agile places emphasis on resources and time over scope. Agile projects commit to delivering project outcomes within a fixed time frame with fixed resources. With time and resources being constant, scope that is not core or critical to achieving the project outcomes become the constraint that is most negotiable. Design features or functional elements that are not deemed core or critical to the project are flexible and are dependent upon the amount of time and resources available for the project. Another aspect of scope flexibility allows the project team to make the decision to shift delivery of functionality from iteration to iteration, as long as core or critical functionality is delivered before the project ends.

Figure 1-1 compares how scope, resources and time are perceived in traditional waterfall versus agile.

Agile contends that non-essential functionality within scope can and should be sacrificed in order to deliver higher priority items. This requires the prioritization of scope in a continuous, iterative, and collaborative process. It allows new information discovered through ongoing collaboration between the team and users to result in an adjustment in the priorities. In this way, functionality with the highest business value is prioritized for delivery first and elements that are outside of the core functionality are prioritized last.

Product Development Cycle

The development lifecycle for traditional waterfall follows a linear approach where each phase is completed in sequence, culminating in the delivery of a product or service at the end of the project. Although titles may vary among organizations and projects, the series of phases often follow the pattern of plan, analyze, design, build, test and implement. The deployment of all functionality is delivered once at the end.

By contrast, agile includes iterative development cycles that focus on building functional product increments of the overall solution, repeated over the course of the project. Figure 1-2 shows how functioning product is developed incrementally with several product releases over the life of the project, in contrast to traditional waterfall. Through continuous integration, product increments are frequently released to users to provide business value up-front and on an ongoing basis.

Figure 1-2 contrasts the output of product development in traditional waterfall versus agile.

Project Management Planning

Project management planning practices also vary between waterfall and agile, with the biggest difference being the depth and timing of project management activities. Project management for waterfall requires detailed planning that begins after project initiation with the development of the Project Charter. For a period of time, prior to any system development activities, the project team documents the processes, procedures, and controls that will be carried out during the project that are intended to ensure that the entire project scope is delivered on time and within budget. Over the course of project execution, project variances identified must go through governance channels for analysis and approval prior to implementation; significant changes may require project re-planning efforts.

Agile places more emphasis on the ability of the project team to react to change. Planning occurs continuously, though at a high level in the beginning of the project, to form a prioritized framework for what the project team sets out to achieve. Like waterfall, this includes developing repeatable processes for disciplines such as communications, governance, change control, risk and issue management, etc. However, with agile, the project team has the flexibility to manage work as necessary, with the focus on incrementally delivering system functionality. The decomposition of these priorities into specific activities occurs continuously throughout the development cycle as more information is learned with each iteration. Typically bound by the fixed constraints of time and number of resources, project teams have the liberty to actively manage scope. The team makes decisions based on the goal of delivering functionality that presents the highest business value to the users first. However, in the context of government, scope can only be managed to the extent that all core functionality (e.g., legislatively mandated functionality) is delivered by the end of the project.

Figure 1-3 depicts the continuous elaboration and re-prioritization of system functionality. Scope items are initially ordered from high to low priority. Starting with the highest priority, the project team decomposes the scope item into smaller work efforts that can be completed within an iteration (A). With the business owner providing direction, the decomposed items are considered individually and all scope items are re-prioritized. This may result in placing components of scope at a lower priority than it was previously based on the business value offered. During the iteration, the highest priority scope items are developed into a functioning product increment. To plan for the next iteration, the project team will repeat the process of taking the highest priority scope items and decomposing the work, if necessary (B). Individual scope items are re-prioritized, the highest priority items are developed into a working product increment, and the process repeats until all scope items are developed. This example describes the type of planning that can occur at the iteration level, but, as depicted in Figure 1-3, similar planning activities may occur at all levels of the project and organization.

Figure 1-3 illustrates how continuous elaboration occurs through iterations.

Wherever the project team ends up on the project management spectrum between agile and waterfall, users will benefit most when project teams prioritize their needs when making decisions. User-centered approaches to project management and system development lead to meeting users’ most important needs earlier and with greater consistency across an organization’s project portfolio.

Team Composition

Many waterfall project teams consist of separate roles specializing in specific skills or expertise. For example, an analyst typically hands off requirements to a developer, and then a developer hands off the product to testers, and so on. Conversely, agile teams are cross-functional; each member of an agile team can perform one or more of the skills required to take a requirement through all phases within an iteration. Agile teams typically consist of at least three people to ensure there are enough skills, but no more than nine to minimize complexity of communication and collaboration.

Figure 1-4 illustrates the contrast between teams with undefined roles and defined roles. Each letter represents a different team member and each color represents a different skill. With more adaptive cross-functional teams, each team member has one or more skill, broken down by the differing sizes and colors. Collectively, the team has more than adequate depth in all the skills that are needed. With more traditional specialist teams, each team member has a specialty skill and serves in a defined role. While cross-functional roles are more prevalent in the private sector, it is desirable for public sector organizations to develop cross-functional teams, as well. In doing this, the organization lends itself to supporting adaptive methodologies.

Figure 1-4 illustrates what team composition looks like in an environment with cross-functional teams in undefined roles versus specialist teams in defined roles. Each letter represents a team member and each color represents a different skill.

Stakeholder Involvement

During project planning, there is similar Stakeholder involvement for both waterfall and agile. Stakeholder involvement differs in the development lifecycle. On waterfall projects, there are two pivotal moments in the development lifecycle where Stakeholder involvement is critical to ensure the delivered solution meets the users’ needs– during requirements development and acceptance testing. During design and build, the project team will work to achieve the defined requirements with minimal engagement of the Stakeholders until they have the opportunity to validate the requirements by using the finished product during testing. Traditionally, Stakeholders receive project communications, but are not necessarily actively engaged in two-way exchanges.

With the incorporation of iterative development cycles, agile teams are able to solicit Stakeholder feedback on a continuous basis. Stakeholders are engaged before and during each iteration to provide input into the functional priorities. At the end of each iteration, Stakeholders are provided the opportunity to see working components of the product that they can react to and provide feedback.