As a practicing project manager with eight years’ experience and PMP®
certification, I am well versed in the Waterfall method of project management. But lately, all around me I hear words such as Agile
, and backlog
. With my company’s recent adoption of Agile using the Scrum framework, it made sense for me to see what this was all about.
With curiosity, I embarked on educating myself, and I ultimately led my own development team in a number of sprints to deliver our product owner’s vision for a business continuity management initiative. What helped me transition was a compare-and-contrast exercise that I would like to share with you here.
Similarities between Waterfall and Scrum
Mapping the Project Charter to the Definition of Done
In Waterfall, we have a project charter, which defines what we are going to do, how we are going to do it, what our goals and constraints are, who the key players are, and who our stakeholders are. What, then, is the equivalent in Scrum?
In Scrum, we have our Definition of Done, which is short, concise, and tells us what we need to do but allows us the agility to revisit it in our weekly sprint reviews and update it as necessary. A product owner is defined in Scrum as one who has the product vision. He or she sets our scope at the onset. Our stakeholders, again, are identified, and they participate at minimum in our sprint reviews.
Mapping the project plan to the Scrum artifact
How does a Waterfall project plan translate to a Scrum artifact? The product backlog used in Scrum, which the product owner creates and organizes in priority sequence, becomes the guiding project plan for the team during its sprint planning and creation of the sprint backlog for sprint execution. It identifies what is to be done (product backlog items), when it is to be done (sprint execution), and who will do it (the development team).
Mapping Waterfall meetings to the Scrum framework
What about some of the key meetings in Waterfall — how do they translate into the Scrum framework? In Waterfall, we have weekly status meetings with our project team in which we gather status information on project tasks.
In Scrum, the frequency of team meetings is escalated to Daily Scrums with our development team. These are not status meetings but an opportunity for the team to hold one another accountable for the work they have done and will be doing, and to assist one another if impediments arise. This is also an opportunity for the ScrumMaster to assist the team with resolving any impediments.
Mapping lessons-learned meetings to sprint retrospectives
Lessons-learned meetings in Waterfall translate well to sprint retrospectives, in which we identify what went well, what did not go well, and what can be improved for the next sprint. One of the missing follow-through actions with lessons learned was applying these lessons to the next project. By contrast, Scrum takes the lessons learned from a sprint and specifically asks that we create an action plan and implement it in the next sprint. Thus, immediate application and growth and correction are a few of the outcomes from the sprint retrospective meetings.
So this was not all that different. There are a number of familiar processes in Waterfall that translate easily to the Scrum framework. What, then, were some of the key differences between the two?
Differences between Waterfall and Scrum
In Waterfall, we have a vision that is created once, documented in the project charter as the scope, and not changed throughout the life of the project. In Scrum, we have a product vision documented in the Definition of Done and frequently revisited. This allows the product owner to address the unknowns and tweak his or her vision. It allows the project team to be Agile, flexible in its delivery, and closely in tune with the product owner’s needs.
When a Waterfall project plan is created, it is created once and then updated on a scheduled basis. With Scrum, the project team creates and frequently updates the sprint backlog daily rather than following a plan, which can be rigid or static and that is created without their participation.
Individuals and roles
What about the individuals and roles? How do they compare between Waterfall and Scrum?
A Waterfall project manager is accountable for directing the team in following the plan and for management reporting. In Scrum, the ScrumMaster is responsible for educating the team to self-organize and develop their own plan and to create their own reporting and metrics charts. Stakeholders are an integral part of the sprint reviews of the product and are more involved and engaged from sprint to sprint. The product owner is the one person accountable for the vision of the product deliverable, highly and constantly involved in the acceptance of the product in small increments.
The development team is the one group in which I noticed the biggest difference between Waterfall and Scrum in terms of roles, methods of organization, and task completion. In Waterfall, we have specialists who work only on tasks within their area of expertise, within their own "silos" so to speak.
In a Scrum development team, the team dynamics and the method of work are such that there are no specialists; everyone is responsible for the delivery of the sprint goal. To effectively work this way, the development team members need to ask themselves these questions:
- Do I know enough to help you out? Great, then I'll help you out.
- Do I have specific knowledge that no one else has? OK, then I'll share that knowledge with my team.
- Is there an activity that I can help you with that is skill agnostic? Then I will offload it from you so that you can concentrate on other prioritized, highly skilled activities.
My key takeaways and learning was that Scrum does
have a structure within its framework. The ideas that "We are Agile; therefore, we can do whatever we want when we want to" or that "Scrum lacks structure" are incorrect.
The Scrum framework consists of structured roles, activities, and artifacts, most of which have a direct comparison to similar concepts in Waterfall. However, with Scrum, activities are executed more frequently, roles are more participatory in nature, and artifacts are light in documentation but not in thought or substance. There is much more interaction within the development team, and the product owner and the customer are brought into the team's fold.
In all, the Scrum world may be new for some of us, but by comparing it with how we used to do things, we can easily see the similarities between Waterfall and Scrum. It’s a brave new world. Embrace it with confidence!