Scrum & Kanban
Jim Coplein today posted a very interesting post on Jeff Sutherland’s Scrum Log. It’s title is: An Alternative to Kanban: One-Piece Continuous Flow.
In the piece, Jim discusses the definitions and merits of Scrum and Kanban.
This is a subject about which I too have some passion. While not as talkative as Jim, I will summarize them. This will allow greater room for misinterpretation, and therefore for greater learning. (smile)
1. Let’s get more results. I am getting to the point where I don’t care if we use Scrum, XP, Kanban, scotch tape, or Grandma Berthe’s Bible. What we use or what we call it means less and less to me.
Show me the smiling faces. Show me how it helped you or your team or your customers. In real life, the results are what matter. The gods who spoke to Jeff and Ken and the scrum community knew this well. I better add: I still think Scrum is the place to start, and I don’t believe in Scrum-Butt. This is a good subject for another 10 blog posts.
2. Lean bias. I look at Scrum and Kanban as parts of Lean. And I like them all.
I recommend you be biased toward the Lean ideas, toward Lean Thinking.
3. Scrum. I think it is an excellent start. Scrum is as much as one team can change in a short period of time; and, yes, while it is simple, it takes years to become a master.
Scrum is only a framework, and while the team should not subtract from Scrum, stuff must be added to Scrum. Actually quite a lot of stuff, in my opinion.
Scrum’s ‘incompleteness’ is not a defect but a virtue.
4. Kanban. The cards in Lean were stolen from Piggly Wiggly (the grocery store). Which pleases me, since I have been to some of their stores, I like them, and my kids have “I’m Big on the Pig” t-shirts from Piggly Wiggly.
Kanban is one of several tools in Lean. Kanban may be classed with several Lean practices or tools under a group called “Visual Management.”
Kanban in Lean first refers to the sign-cards stolen from Piggly Wiggly, and of course also to all the ‘usage’ around that. Kanban has many purposes in Lean manufacturing, to reduce and manage inventory, set up a pull system, enable flow. To enable single-piece continuous flow and to provide some indicator of stoppages in flow.
It is important to note that Lean uses many other things in addition to the Kanban cards to attain fully all the goals mentioned above.
5. “Kanban”. This is becoming an alternative software development ‘framework’.
It has various definitions. There are of course now many implementations, many of which would no doubt be called “Kanban-but…” by some of the “Kanban” people.
Many good and smart people like the idea, and no doubt it does some good.
In Lean manufacturing, the Kanban cards represent things of the same ‘size’. In “Kanban”, the cards represent User Stories, but so far as I can tell, there is not a strong discipline yet to keep the User Stories the same size. To me, this is a meaningful problem. (Long discussion as to why.)
Related to the size problem, “Kanban” has no metrics. Or the metrics are very simple: “The process completed X number of cards last week.” Thus, it is hard this way to demonstrate success. (Yes, it is true that measuring success is difficult in almost every case.)
So, how much benefit “Kanban” provides compared to and separate from Scrum is hard to say, objectively.
5. Engagement with Business/Management. It seems pretty clear to me that Kanban tends to be used when engagement with the business side and/or management is not wanted or not possible.
Clearly, to me, this lack of engagement is not a good thing. However, if it is not possible, then perhaps it is not possible only for now.
Still, we tend to believe that Scrum, for example the Sprint Planning Meeting and the Sprint Review (demo), and Release Planning and Release Plan Refactoring (technically not a part of the core of Scrum)…tends to build trust between the Business and the Technology side. Admittedly, they often start in a state of mutual distrust, sometimes severe. These practices, if done well, smooth out the distrust and build trust.
6. Our recommendation: Scrum first, then add Kanban.
First, we must note that ‘standard’ Scrum comes with a Scrum Board. Virtually every initial implementation of Scrum uses a Scrum Board aka ‘cards on the wall.’ (Note: Technically the Scrum Guide does not get into the Scrum Board.)
So, Scrum + Kanban means changing the Scrum Board to act more like a Kanban board in lean manufactoring. It takes a lot of discipline to do this. Not use it is always useful, but it might help.
Some will note that this idea (Scrum + Kanban) is similar to ScrumBan.
We think that Scrum is plenty to implement on Day 1.
We recommend later, after they have Scrum working decently, that the team use the ideas from “Kanban” and Lean to modify the Scrum Board into a specific Kanban board that reflects their work. To us, the focus should include:
- Minimize WIP (work in process)
- Do not over-stress the system (a basic principle that deserves 15 blog posts)
- Single-piece continuous flow
- Aggressively identify and remove impediments (eg, stoppages in flow)
Kanban or “Kanban” should not be used to reduce contact with the Business, Management or the Customers, but rather the opposite.
Kanban and flow should not become a fetish. (Nor should Scrum purity be a fetish, for that matter.) There are good reasons to “stop” and do a Sprint Planning Meeting and a Sprint Review (demo) and a Daily Scrum.
If developers (coders and testers) still evince a preference for “Kanban” after these issues are discussed and explained, management needs to consider carefully the root causes. Humans (developers and managers) are of course complex, and many things could be at play.
Our first guess is that management is not aware how important it is for the team to have more fun when playing Scrum. If that has not happened (yet), then the Team might be wanting to try something new to find some fun.
Fun is actually quite key to more creativity. Which, in our kind of work, is key to higher productivity.