Synchronizing Scrum and Waterfall

Many organizations manage large projects using the Waterfall life cycle (See Figure 1). The life cycle (when used correctly) helps manage scope, time, cost and risk. It also provides visible milestones to coordinate team members and managers involved in the project. Like all life cycles, Waterfall has potential downsides, such as finding technical challenges late in the project and getting end-user feedback after many decisions have already been made. All of these risks can be managed by early prototyping, which is common in process-mature organizations.

Figure 1 – Waterfall and Scrum, and an Example Coordination

Over the past 10-15 years, Scrum* has become a popular approach to develop software, and by nature does not have phases. This means that if a software development team wants to use Scrum, while another group or company wants to use Waterfall, coordination is needed.

In Figure 1, Scrum breaks down all work into Sprints (typically 2- to 4-week increments). The intent is that code is developed and demonstrated during each sprint to seek early feedback. This feedback helps identify and resolve technical challenges and obtains user clarifications early in the project.

Incorporating Analysis Activities into Each Sprint
If a team wants to use Scrum but not lose the analysis activities of Waterfall, it can incorporate those practices into each sprint. The intent of Scrum is to deliver working code at the end of every sprint. This benefit can be maintained by changing the percentage of coding and non-coding activities for each sprint. For example, each sprint could be composed of:

• 70% Requirements
• 30% Other (design, code, test)

or

• 70% Design (for the components the team has requirements for)
• 30% Other (process new requirements, code, test)

or

• 70% Code (for the pieces the team has design for)
• 30% Other (process new requirements, code, design, test)

Synchronizing Waterfall and Scrum Teams
Let us suppose that a large project (using Waterfall) has a software component and the software team wants to use Scrum. The large project expects there to be a software requirements document at the end of the requirements phase after 8 weeks, (see Figure 1).

The Scrum team:

• Negotiates that draft one of the requirements document will be available for review by week 4 (end of sprint 1).
• Plans to develop draft 2 of the requirements by week 6 based on feedback and investigation (mid sprint 2).
• Plans to develop draft 3 by week 8 based on feedback and investigation (end of sprint 2).

Draft 3 is baselined as the “requirements document” until further changes are needed. Changes are then looked at every 2 weeks at the beginning of each sprint.

The team uses 4-week sprints as follows:

• Sprint 1: 70% requirements elicitation and analysis, 30% other activities (design, code, test of high-risk or core components). Deliver requirements draft 1 after sprint 1.
• Sprint 2: 70% requirements elicitation and analysis, 30% other activities (design, code, test of high-risk or core components). Deliver requirements draft 2 at week 6. Deliver baselined requirements after week 8 (end of sprint 2).
• Sprint 3: 70% Design, 30% other activities (requirements, code, test of high-risk or core components).
• Sprint 4: 70% Design, 30% other activities (requirements, code, test of high-risk or core components).

The 30% allocation of each sprint is to develop code that is known to be needed or to investigate risky areas early. The component is demonstrated at the end of each sprint to obtain feedback. Depending on the item built, this could be feedback from the development team, product owner, end user, systems engineer or test engineer.

The other phases and analysis expectations of Waterfall can be met and synchronized in a similar way. The remaining sprints will have a time allocation of X% analysis activity, 100-X% build real code and get feedback, where X could be 80, 60, 40, 20, 0, and will change over the course of the project.

The approach of incrementally performing the analysis and developing the documents expected by Waterfall is made easier by breaking each document into early drafts, such as:

• XX document draft 1
• XX document draft 2
• XX document draft N
• XX document baseline

The benefit to the Scrum team is that they might have a lot more working code completed than typical before the Waterfall coding phase starts. Assuming the team has the discipline to develop components for which there are already requirements and test cases defined, then code will not be wasted. If the team is using all of their 30% coding time allocation to guess and develop speculative features, then all bets are off.

* See processgroup.com/pgpostoct2012.pdf (page 2) for summary of Scrum.

Questions, comments? Contact us.