Today I’m going to talk about the difference between Scrum and “kanban” type approaches.
To make things simple, I am going to coin a new acronym — CFS — meaning continuous flow for software development — as a genericized “kanban” approach
There are many interpretations of kanban and so dealing with it as a general sotware case — as opposed to it’s legacy manufacturing heritage or even David Anderson’s “Kanban” will uncover what is really the magic sauce here.
Therefore I will use “CFS” or “continuous flow” instead of the word “Kanban” most of the time.
In a nutshell a CFS
- Focuses on doing the most important work first
- Focuses on completing work already started
- Focuses on quality of each step completed
- Limits work in progress
That is it. Don’t worry about the Japanese, the manufacturing, anything else. In a nutshell that is what a continuous flow system looks like.
Worrying about whether the system is “push” based or “pull” based is also not really important; it could be either or both; what matters is that the highest priority work is worked on, and things get completed.
How is that different from Scrum? Don’t they both have a taskboard with roughly similar columns?
To understand this, consider the difference between a 4 stroke gasoline engine and a jet engine.
In a 4 stroke engine, power is delivered in discrete phases — sort of sprint like chunks. There is a lot of complicated gearing and timing to make sure that the fuel is sprayed in at the exact right moment, etc.
Fuel can only be added during the injection cycle — just like tasks can only be added to the beginning of a sprint.
A 1 cylinder gas engine would lurch forward every so often, just like a one man team “sprinting” through scrum. In a gas engine multiple cylinders are staggered in time to simulate continuous power output. In scrum however, all the cylinders are aligned so that the entire team lurches forward every sprint, but farther.
As you can see above — there is a lot of complex gearing and overhead just involved in keeping all the timing coordinated. Just like in Scrum.
In a jet engine, everything is happening all the time, or at any time. You can add fuel whenever you want to, air and fuel get mixed and combusted with no particular regard to the timing of any particular sets of molecules, etc.
In the diagram above, the yellow/orange areas are where fuel is burning. It can burn at any time or all the time, air moves from the front, and out the back. Note there is no need to correlate and synchronize any of the blue arrows. It’s a continuous flow system.
Scrum requires but CFS does not:
- Tasks/stories be delivered together in chunks, called sprints
- To achieve this, these need to be estimated
- Scrum commits to completing these tasks even though the estimation is vague
- There is huge pressure to complete tasks at all costs in a given, with quality and technical debt as the first casualties —
- There is a huge set of sociopolitical theology associated with Scrum, such as no titles, do the simplest thing first, no prototypes, YAGNI, etc
- Scrum focuses on timeboxing work into discreet phases for no apparent purpose, similar to how a gas engine focuses on discretizing combustion — for a small car that might be ok, for a passenger plane it isn’t efficient enough to consider doing anymore
- Everything must be potentially shippable — all prototypes are endless maintenance exercises since the product is the prototype
CFS does not require
Estimates? You can do them or not do them in CFS.
All day planning sessions? Relatively unnecessary in CFS, but they can be done if you want them.
Retrospectives? Up to you.
Demos? Whenever you want.
Delivery? Whenever you want.
Documentation and prototypes? Up to you.
User stories or tasks? Tasks are fine.
No experts? Architects and planning/prototypes are fine
Etc.
I hope this helps and please feel free to ask questions
PA
Post Agilist 