“The Only Thing That Is Constant is Change” – Heraclitus
Unlike Scrum, in a traditional waterfall methodology all planning is done up front. For example, say the objective of your project is to get from Block A to Block B
In Waterfall, all steps will be planned out and base lined up front. Once planning is complete, the team will set off on their voyage to get from Block A to Block B.
Using Waterfall, your up front project plan might look something like this:
Here’s the problem, delivering complex software is a lot like finding your way through the dark. You have to take small steps and feel your way through. You have to adapt and make changes as you find your way.
This is why project teams run into trouble using a Waterfall methodology. They are not ready to adapt to changes when needed, and changes will be needed.
To make things more challenging, using Waterfall customers are only engaged during the start and end of the project. This means all throughout design, build and test the customer is in the dark. This leaves a risk of a system built that is completely different than what the customer actually wanted.
In Scrum, the software teams builds workable chunks of software in short iterations. The team is feeling their way through the dark and adapting to changes as needed. These iterations are called Sprints, and they usually last around 2 weeks. At the end of each sprint, the customer gets to see the built functionality. The below picture represents Scrum iterations:
By building software in short iterations and keeping the customer engaged, you can adapt to change. The final outcome of the project might look completely different than original expected.
The customer may have realized they actually need to get to Block D, not Block B. Maybe they realized Block D provides much more value than Block B.
See example below:
Actual results using Scrum
For more content like this, subscribe to the MacIsaac Consulting Blog.
To contact us about our services, click here.