Waterfall, Scrum or Kanban?
How do you decide to use waterfall, scrum or kanban to manage your product team?
Wanting to refresh my Product Owner skills I’ve just come to the end of the first day of a Certified Product Owner session in which Roman Pichler retrofitted the Stacey diagram to explain where waterfall, scrum and kanban are of most value.
Roman’s interpretation of the diagram:
- A waterfall management methodology, like PRINCE2, is suited to simple products (i.e. high certainty and high levels of agreement) because it is a sequential approach based on setting an initial plan that is unlikely to change.
- Kanban is suited to complicated products (in which a degree of certainty is balanced against an expectation of change) because it assumes that workflow is understood but that conditions will change. Mature software is an example of product that might be suitable for management by kanban.
- Scrum is suited to complex products with little certainty because it focuses on short-term goals that validate assumptions and reduce risk. Software in development is an example of a product that might be suitable for scrum.
This model rings true from my personal experience and helpfully overcomes the snarky assumption that waterfall should never be used whilst also demonstrating its limitations.
Working in the UK government where the digital agenda is maturing one can assume that the strategy will shift from delivery to maintenance. I’m interested to see if the pervasive use of scrum shifts towards kanban.