Many organizations start implementing agile on a small scale, with one team or department, and expand from there. When organizations starting agile have traditionally used traditional or waterfall approaches before, they face the challenge of integrating agile and waterfall and determining what projects work best for each approach. In this post, we will talk about the challenges of integrating agile and waterfall and explain a model for how the two can integrate, even on large and complex projects.

The Challenge of Integration

Organizations using a mixed approach of agile and waterfall run into several challenges:

1. Agile adoption does not happen overnight. Especially in large organizations that have started out 100 percent waterfall, the transition takes a long time. For example, an organization may shift to 90 percent waterfall and 10 percent agile, then 80 percent and 20 percent, and so on.
2. Early adopters need time to become fully effective. We often see new agile teams struggle to internalize agile principles and mindset, become self-managing, and produce value early on. If more than three months pass without the team delivering value, then there may be process concerns to address. (For more on other warning signs of agile adoption, take a look at our most recent ebook, Top 5 Warning Signs Agile is Not Working for You.)
3. Agile is not ideal for every project. There are some projects for which agile is not a good fit. As a result, organizations are not expected to transition to 100 percent agile, meaning that some projects will still be executed using waterfall. (For more on where agile is a good fit, read our blog post, Is Agile a Silver Bullet?)
4. Resources are likely to overlap between agile and waterfall. Keeping exclusive resources for agile teams and waterfall teams is difficult and costly, so agile team members may also work on waterfall projects. Agile teams may also work with waterfall teams on the same project. For example, waterfall teams may design, develop, and release code while an agile team works through a backlog of bugs.

The Model

Figure 1 shows a model for integrating five teams, three waterfall and two agile, on a software project. Whenever one team releases code, as indicated by a black dashed line for the waterfall teams and a red dashed line for the agile teams, all other teams synchronize their code. Some integrations overlap between agile and waterfall teams. In this project, which spans six months, there are fifteen total integrations.

Figure 1. Model for Integrating Agile and Waterfall Teams on a project.

Using this model, some teams can work in waterfall fashion while other teams work using the agile approach. Code updates drive the synchronization between teams. Whenever teams deliver updates, all other teams integrate that code. By synchronizing code, teams stay current and avoid the problem of deprecated code disrupting the overall project. This model is shown with five teams, but can be used with even more teams.

Challenges with the Model

Teams using this kind of integration model commonly struggle with too many integration points. If teams need to integrate their code more than ten times a month due to deliveries, then resources will be stretched and time and cost will be added to the project. In Figure 1, which shows a six-month project, there are fifteen total integration points, which is more sustainable across all the teams.

Teams not using some kind of automated branch-and-merge system for updating code, such as the system included in TFS, will especially struggle with excessive code sync. Another challenge with code integrations is possible disruptions to testing. If a waterfall team needs to update code in the middle of testing, the team will likely need to add regression testing of the new code. This extra testing will add time and cost and may cause a team to miss a deadline.

To overcome these challenges, teams should time releases to a common cadence. For example, waterfall teams can halt their deliveries until agile teams have finished their releases, or vice versa. By adopting a common delivery cadence, teams minimize the number of code syncs, avoiding problems such as disruption of testing, added time and cost, and resource stretching. In Figure 1, we see that the first delivery points for waterfall teams 1 and 2 match up with the agile team’s sprints as indicated by the black and red lines merging.

Waterfall teams, which usually operate on hard deadlines, may especially struggle to time their delivery to agile team releases. Since waterfall teams are more likely to have defined testing periods, it is important to time releases so that the waterfall teams can synchronize code when they’re ready to perform regression testing. If both agile and waterfall teams have flexibility, we recommend that agile teams time their releases to waterfall team milestones.

Another common challenge is that agile and waterfall teams likely track their work in different ways. With the different approaches, how can project status be accurately assessed at any given time? Two approaches may be taken, either separately or together, to overcome this challenge. The first approach is that one program manager oversees work for all teams on the project. The program manager tracks work for all teams, whether they use agile or waterfall, and issues a report covering the progress of all teams.

The second approach is that project managers oversee waterfall teams’ work while product owners and ScrumMasters oversee agile teams’ work. Based on the size and number of agile teams, one ScrumMaster may facilitate work for all teams or each team may have one ScrumMaster. Even though agile teams are self-managing, the presence of product owners and ScrumMasters will introduce the necessary accountability for tracking the work overall. By taking these two approaches, work can be tracked in a common way for effective monitoring and controlling.

Conclusion

The model presented in this post is geared toward software projects but can be applied to a variety of projects. Any point where value is delivered to the customer is an opportunity for agile and waterfall teams to get on the same page. Integrating agile and waterfall in an organization requires overcoming several challenges, especially for large or complex projects. Overcoming these challenges to achieve a balance of agile and waterfall approaches is necessary to the overall success of projects. By overcoming these challenges, organizations achieve the ability to handle a wide range of projects with the appropriate approach, strengthening their strategic position.

Are you struggling to integrate agile and waterfall in your company? RefineM has project management consulting as well as agile transformation to help a variety of teams deliver their projects.

What are your experiences with integrating agile and waterfall? Please let us know in the comments.