I met up with Jean Tabaka last week for a coffee and we chatted over various things, including Lean, Kanban, “The Don”, Tufte, and Systems Thinking. One of the other areas was around the origins and original intents of Scrum. Jean mentioned an early paper(*) by Jeff Sutherland, written before the current terminology became standard, where he described his process in a very simple way
- Decide and agree on an Outcome, in terms of working software
- Use daily Sync Steps to decide how to best achieve the outcome
Since we had that discussion (which also touched on GTD), I have found that this a great a way of describing the essence of Agility. Inevitably it has also triggered thoughts on ways of comparing and contrasting Kanban with more traditional Agile methods such as Scrum.
In a Scrum based approach, the Outcome is defined by the Sprint Goal, with the Sprint Plan being a means of making a commitment to the Outcome. There is a single Outcome, which is constrained by the length of the Sprint. The Sync Steps are provided by the Daily Stand Up Meeting.
In a Kanban based approach, the Outcomes are the limited work items in the system. There can me multiple Outcomes in progress at a time, but the WIP limits constrain the Outcomes. Planning, and as a result any commitment (or SLA) on the Outcomes is done per Outcome, and Just In Time. The Sync Steps are usually provided by the same Daily Stand Up Meeting, but could also be formed by other forms of Cadence.
So both Scrum and Kanban focus on team Outcomes, with regular Sync Steps to achieve the Outcomes. The way in which those Outcomes and Sync Steps are managed are different.
(*) Unfortunately, I don’t have a reference to this paper. If you recognise it, please let me know!
Update: Jeff actually calls them SynchSteps. References can be found in this 2001 paper, and in early emails. He also refers to Outcomes as Mutations.
Hi Karl,
Thanks for the blog – nice and concise expression of agility.
Regarding Scrum, some Scrum teams also have multiple Outcomes. Or maybe I should say, there’s one Outcome and a number of intermediate steps towards that Outcome that are smaller Outcomes in their own right.
Those intermediate steps would be individual backlog items/user stories/features that may or may not be delivered at the same point in time. That is, while a Scrum team might have a sprint goal (Outcome) of “Charge Our Subscribers” they might deploy the ability to charge credit cards into production four days into the sprint, electronic invoicing a couple of days later, etc.
What I describe here isn’t canonical Scrum, perhaps, but it’s not exactly against the dogma either.
Thanks Lasse. I agree that modern Scrum teams will use individual backlog items as sub Outcomes. I was primarily referring to the original thinking behind Scrum.
Jeff Sutherland describes SynchSteps in this paper: “Inventing and Reinventing SCRUM in Five Companies” http://www.agilealliance.org/system/article/file/888/file.pdf
Thanks Rowan 🙂