What Is the Difference Between Scrum and Waterfall Methodology?
As a trainer, I am frequently asked, “What is the difference between Scrum and Waterfall methodology”?
Let’s break down these two different methodologies so you have a clear understanding of the differences.
Let’s start with waterfall.
Waterfall methods use a sequential approach to development in which deliveries to customers are generally done infrequently. The idea of Waterfall is that we should follow a strict set of phases or stage gates to ensure that we do things “properly and in order.” Typically for waterfall software projects, we see phases around Requirements, Design, Coding, Testing, Deployment, and Maintenance. Once we “lock down” our requirements, we resist change and “stick to the plan.”
How long is a typical waterfall? Usually each phase lasts for weeks or months, and deliveries only occur every few months or even after a year or longer.
Waterfall is a project-oriented approach and has a poor track record of success in complex areas like software.
What’s the solution to dealing with complex work efficiently and effectively?
You guessed it. Scrum.
In Scrum, we tend to focus on products more than projects and more on continuous prioritization than detailed requirements. The approach shifts to rapid delivery cycles fueled by empowered, cross-functional teams. Scrum teams typically deliver a new version of their product every 1 to 4 weeks. These development iterations are called sprints, and can be thought of as all the functions of the waterfall phases occurring continuously. Development priorities are captured in a product backlog and can shift as we learn more from talking with customers and delivering new versions of the product to them.
Upcoming Certified Scrum Master Courses
[a4a_events type=”CSM”]
Thanks for posting this Steve. It’s something I’ve been thinking about as we work to move to an agile mindset. I think one of the key differences between the two methodologies is that traditional approaches start with an assumption that we know the right answer to the problem (and all the details about what makes it right). If we know the right answer, then it makes sense to plan the most efficient way to implement it. On the other hand scrum starts with an assumption that there may be things we don’t know, so let’s experiment along the way. No point in investing everything in the wrong answer, let’s invest just a little to test it and find the right solution along the way.
Hi Kevin – thanks for your thoughts on this! If you *really* know exactly what’s required then a traditional project management approach may make sense. I tend to think of building the same house over and over as an example of this. In software, I think it’s very rarely true that we can assume we know the right answer – even small tweaks were difficult in traditional projects and we didn’t have the early feedback loops to even figure them out. I’ve also come to focus more and more on the product backlog management – a good part of Scrum is finding the work not to do even inside the bigger features that are important. So for me, the net of this is that I don’t see many software projects where Scrum isn’t a better option – but I have to allow there could be some!
[…] Read More […]