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, for companies who have not previously used an Agile approach, they will test the "new" methodology using a pilot project. If successful, then the company typically expands Agile to additional projects.
As companies expand their use of Agile (or Scrum for this blog), 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 their and 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 is well-versed in the scrum methodology.
- Training – you need to get each team member, including the Product Owner, trained in Scrum, so that she/he understands the philosophy and "why" certain things are done in Scrum.
- Preparation – you need to ensure that proper planning and preparation have been done, so that the team is ready for and comfortable with the transition from Waterfall to Scrum.
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' 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 is 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 that 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.
The importance of training a new team in the Scrum methodology cannot be overstated. While it is true that many teams have adopted an Agile methodology without training, the benefit of committing to 2-3 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 that 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.
Also, 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 those concepts into transition planning. Also, 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 draft user stories).
In preparation for transitioning an active project from Waterfall to Scrum, the existing Project Manager and prospective Scrum Master (note that 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/sub-phase, or it may simply be 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 of 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 2-3 sprints of development.
Also, it is critical that the User Stories are very well written and properly scoped. While this topic is beyond the scope of this blog, it is 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 do not let the tool itself 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., 2-, 3-, 4-week sprints) and start days (e.g., Mondays). Once agreed to, then 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 is worth mentioning that if the team has an "offshore" presence (e.g., developers in India), then this does create a lot of scheduling complications, and requires some degree of sacrifice (e.g., meeting in the evenings for the US-based team).
So once you have identified your transition point, created your Product Backlog, and scheduled your meetings, you are almost ready for the transition. While there is 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, cross-application), resource allocation (e.g., 100%?!), how to plan a release backlog, and how to determine your team's velocity. We will address these other topics in future blogs.