Scrum as a Process not a Framework
- The essence of Scrum is to do things in shorter cycles or sprints, allow more self-organisation in terms of time allocation and managing backlog, the emphasis (and the language) is on product
- In my language, Scrum is clearly a method not a framework
- A method provides for a series of defined steps to achieve an outcome
- A framework would position said methods
- Scrum in 30 seconds
- A product owner creates a prioritized wish list called a product backlog
- During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces
- The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum)
- Along the way, the ScrumMaster keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder
- The sprint ends with a sprint review and retrospective
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again
Scrum as a process or method is not suitable for complex systems, because this would require multiple parallel contradictory probes, not just a single experiment
- It’s value is in the liminal space between Complex & Complicated domains