Tech tutorials How to Transition an Active Project From Waterfall to Agile Scrum

By Insight Editor / 26 Apr 2013 , Updated on 16 May 2019 / Topics: Agile

Agile Scrum has been around for a number of years now. The adoption of Scrum (or other Agile methodologies) continues to grow in popularity as the approach continues to gain acceptance. In many cases, companies that haven’t previously used an Agile approach will test the "new" methodology using a pilot project. If successful, the company will typically expand Agile to additional projects.

As companies expand their use of Agile (or Scrum for this article), there are typically active projects that may be transitioned from Waterfall to Scrum while “in flight.” This dynamic raises special considerations that are distinct from starting Scrum with a new project, although the same core Scrum principles still apply.

The purpose of this blog is to help Scrum Masters and others think about what they need to do to transition an active project from Waterfall to Scrum so that they can improve the likelihood of the project's success.

Here are a few key tips to keep in mind when transitioning an active project from Waterfall to Scrum:

Business commitment — you need a single business "product owner" who can make decisions for the team and is willing to commit anywhere from 10 to 20 hours per week (likely more).
IT commitment — you need a relatively small, dedicated core team of developers and a flexible Scrum Master (not a project manager) who’s well-versed in the Scrum methodology.
Training — you need to get each team member — including the product owner — trained in Scrum so that he or she understands the philosophy and why certain things are done in Scrum.
Preparation — you need to ensure proper planning and preparation have been done so the team is ready for and comfortable with the transition from Waterfall to Scrum.

Commitment

As with any endeavor, the commitment of the team and its sponsors is critical for a successful transition.

First, the project leadership (both business and IT) must be willing to support the team and provide the necessary resources for the project. This takes many forms, including but not limited to providing project personnel (e.g., more of the business's time), budget (e.g., training, tool) and flexibility (e.g., prioritization of work and timing of delivery).

Second, the business must be willing to provide a product owner who can make decisions for the delivery team and who can meet the time requirement inherent to Scrum. While business participation is always required, there’s a much greater time commitment in Scrum due to the active participation of the product owner in the various meetings (e.g., sprint planning, user story reviews, backlog prioritization, etc.).

Also, the product owner must be able to make decisions for the team. Otherwise, the team may lose momentum, and that will impact the commitment of the team as a whole.

Third, the IT team must be willing to commit to the different dynamics involved in delivering a Scrum-based project. In particular, the IT delivery team will have to learn how to be more flexible with scope and the introduction of new requirements.

Caveat: That does not mean the project should eliminate change control procedures, but Scrum philosophy does allow for and expect changes in business priority and requirements. Another key factor is for the IT team to commit to identifying smaller chunks of deliverables. This requires a lot more creativity and thinking than what may be required in a Waterfall setting.

Training

The importance of training a new team in the Scrum methodology cannot be overstated. While it’s true many teams have adopted an Agile methodology without training, the benefit of committing to two to three days of basic Scrum training reaps many benefits during execution.

For instance, the team needs a firm foundation in Scrum terms and principles, and having this sooner rather than later will eliminate a lot of confusion and misapplication of Scrum methods. Also, to be effective, the training should involve each team member, including the business (especially the product owner).

Ideally, the training should be held for the specific team and project being transitioned. The benefit of this is it allows the trainer and team to use actual project examples during the course of the training. Also, it facilitates greater team cohesiveness in that the team will have been collectively grounded in the new concepts and should understand the why behind the different concepts.

Additionally, the training should occur during a pre-discovery period. This allows the team (especially the Scrum Master) time to take the concepts learned in training and incorporate them in transition planning. If the team is able to focus on their specific project, as mentioned above, then they can actually begin preparation while in training (e.g., developing the product backlog and drafting user stories).

Preparation

In preparation for transitioning an active project from Waterfall to Scrum, the existing project manager and prospective Scrum Master (note this may be the same person) must work with the business and IT team to identify a logical transition point. The transition point may mean starting with a new release, a new phase/subphase or simply picking a certain date.

Ideally, the transition is in whole, not in part. In other words, the entire core team and project scope should make a complete and instantaneous transition, not just certain areas of functionality and not over an extended period of time. Having said that, each team should recognize and account for dependencies on external teams, many or most of which may not be on a sprint-based timeline (e.g., infrastructure teams).

The proper preparation of the product backlog is also critical to a successful transition. While the product backlog is fundamental to any Scrum-based project, its importance during a transition is absolutely critical. This is because the team needs to have a firm grasp on what user stories are going to be prioritized for the first and forthcoming sprints. The team should have enough user stories in the product backlog to support two to three sprints of development.

Also, it’s crucial that the user stories are very well written and properly scoped. While this topic is beyond the scope of this blog, it’s recommended that a coach or business analyst with prior experience be involved in this exercise. Also beyond the scope of this blog is the tool used (there are many), but don’t let the tool distract you and the team from the methodology itself.

Getting the logistics right is also critical to the transition. Scrum entails lots of meetings, which vary in duration and frequency. The key point is to agree on the iteration durations (e.g., two-, three-, four-week sprints) and start days (e.g., Mondays). Once these details are agreed upon, the team can schedule each of the necessary meetings around that (planning, daily Scrum, review and retrospective).

Note that some teams prefer mornings for the daily Scrum while others prefer afternoons. Whatever works for the team. It’s worth mentioning that if the team has an offshore presence (e.g., developers in India), it creates a lot of scheduling complications and requires some degree of sacrifice (e.g., meeting in the evenings for the U.S.-based team).

So, once you’ve identified your transition point, created your product backlog and scheduled your meetings, you’re almost ready for the transition. Although there’s no set timeline, you should allow yourself at least three weeks or more just to prepare for the transition (i.e., three weeks after training and before starting your discovery working sessions or sprints).

Other topics for you to consider, which were beyond the scope of this blog, include what tool to use, how to organize the team (e.g., application-based versus cross-application), resource allocation (e.g., 100%?), how to plan a release backlog and how to determine your team's velocity.