Why I prefer ScrumBan to Kanban
I have spoken about why I like Lean and why I like ScrumBan, a combination of Scrum and Kanban.
Some people prefer ‘Kanban’, as it is being called in the software development community. Sometimes: Kanban Method.
To be honest, I think I know what Kanban is in Lean Manufacturing. But I am unsure what ‘Kanban’ is in software development. This is because there is no agreed upon definition of ‘Kanban’ (AFAIK). So, while I think I have concerns about ‘Kanban Method’, I am unsure how to fairly define it, I will not comment on it here — at least not much directly.
Let me discuss “kanban in the wild’ (KITW), which allows me to discuss my concerns, without getting into an argument about what is or is not included in ‘real Kanban’.
What ‘kanban in the wild’ (KITW) actually is varies a lot too. I am picking ALL the bad things, one could say. It allows me to describe my concerns. Again, it might be fair to say that ‘good Kanban’ does not have any of these problems — again, I don’t have a clear definition of ‘good Kanban.’
Here are my concerns about doing ‘kanban in the wild’ (KITW) alone, without Scrum. I describe many specific ‘KITW’ practices or lack of practices.
Not every KITW implementation will do these ‘wrong’ things. Many specific KITW implementations might only do one ‘wrong’ thing (again, in Joe’s opinion). One hopes some KITW implementations do none of these ‘wrong’ things.
Some of the leading advocates of ‘kanban’ may well be advocating the opposite of my concerns listed below. I am just talking about what I see ‘in the wild.’
The purpose here is not to attack ‘good Kanban’, but to explain why I prefer Scrumban.
1. No upfront planning.
It is fine and correct to say that waterfall does too much upfront thinking. This does not mean we should do zero upfront thinking.
In general people who do Scrum also advocate (as I do) some upfront planning before starting the first sprint. I call this Agile Release Planning, and have talked about specific techniques extensively. These are patterns that I use. Not always, but almost all the time. To be fair, the bare framework of Scrum does not include ‘release planning,’ although it does hint at something like that.
A KITW implementation may not do any Sprint Planning, much less ‘agile release planning.’ Both of which I think are almost always not good. Yes, I can imagine a few odd cases where agile release planning is not necessary at all.
If the Team is doing purely maintenance work (bugs and small enhancements) and has ZERO work in backlog at the beginning of the Sprint, then I guess there is no point in Sprint Planning. But I have never seen this situation (I do hear about situations close to this). I have seen where a lot of the work for the Sprint will be defined later, as the high priority problems come in. So…minimal Sprint Planning might make sense.
The customers and the implementers, etc. need to see the big picture. It affects creativity about designing the better solution, it affects motivation, and makes them better able to address dependencies. Agile Release Planning or Sprint Planning allows them to see a bigger picture.
Still, we must never suffer the illusion that we have all the information upfront. That too is patently incorrect. But the lack of perfect information upfront is not a reason to have zero upfront planning.
2. No Team
KITW (sometimes) does not have a Team concept. Certainly some people are involved, but how they are involved and whether they are a real, stable team is left totally open.
The Team concept, which involves many things (self-organization, etc, etc) is so important. And it needs to be a whole, real, stable team. By whole, we mean in part that it must include the business side, as we usually call it. At least good people representing the ‘customers’ well. Inside the Team.
3. No Sprint
KITW is often played without any concept of a sprint or iteration time-box. Frequently people will say “we got 20 cards done in a week”, which implies a 1 week sprint concept.
There are many many advantages to having a sprint. One is so the Team and the people around the team can see productivity per Sprint (a measurement or feedback loop).
We will talk about other advantages when we talk about Sprint Planning, Demo and Retrospective.
4. ‘Scrum does not allow any changes to the Sprint Backlog’
This is a reason people give for using Kanban over Scrum that is not correct.
First, it is true that Team productivity is getting killed by interruptions and whipsawing. So, we want to minimize disruptions. The first, overly simplistic rule to get the ‘kids’ straightened out is: No changes to the Sprint Backlog.
Scrum is not opposed to common sense. For example, inserting 2 SPs of ‘bug’ work (higher priority) to replace a 2SP story (lower priority) that has not been started — this can be done. It should be explained to the Team why we are doing this. And the Team is not being asked to do a higher velocity than what they ‘committed’ to. And they get to re-commit to the new work too (eg, sometimes there are technical reasons why the 2 SP of bug work is not ‘equal’, in this sprint at least, to the 2SP story).
Also, having an ‘interrupt buffer’ of X story points in the Sprint Backlog can accommodate new high-priority work identified during the Sprint.
So, this need to address to-be-identified-high-priority work is a false reason to prefer Kanban. (Of course, logically, there could be other reasons to prefer Kanban to Scrum or ScrumBan.)
5. Dis-engagement from the Business
KITW is sometimes done, IMO, to enable dis-engagement between Technology and the Business.
I seriously doubt whether any advocate of Kanban is advocating disconnecting from the Business side. But, nonetheless, that is what I see happening with some KITW. And that is what I infer is the root (unspoken) motivation. Of course that does not have to be so and is not always so, but it often is.
Often the Business side does not want to engage. At first. The solution to this is not to give up, but to attack the issue, and ‘force’ them to engage. So, I am very discouraged when I see this kind of KITW. People seldom admit overtly this is the purpose, but it often is. IMO.
Scrum forces engagement, by making a business person (well, usually a business person) become Product Owner of a real Team (and the PO is part of the Team). And then, if the PO is not engaged enough, that should become apparent quickly as an impediment, and hopefully fixed (if high enough in priority).
6. No Daily Scrum
KITW often has nothing like a Daily Scrum.
In general Lean teams do a short daily meeting (well, some good Lean people advocate this — I have seen no survey about frequency of usage). And I suggest that all ‘Kanban’ teams do this. And I know that some KITW teams do not. Some say they don’t want to stop ‘continuous flow.’ But then, still, everyone goes home at night and flow stops. Scrum has a short daily meeting, because it helps the Team stay in sync, etc. And the stoppage ‘cost’ is repaid the same day by higher productivity (well, at least on average).
The Daily Scrum should give the Team, summarized, the key information to self-organize and self-manage. So, I think the Daily Scrum adds a lot in enabling the Team to sync up, self-organize and self-manage. (This is important and apparently we need to repeat that idea many times.)
Some KITW is played with a Team, and often a good Team. (As we said above, some descriptions of Kanban do not require any Team concept, and certainly some KITW has no Team concept.) So, a Daily Scrum would enable them to do a better job in collaborating as a Team. Again, some KITW has Team and even a Daily Scrum-like meeting, although often they call it something different.
One KITW Team (and I think I believe they are a real Team) does a kind of Daily Scrum every day at lunch. Still, I am thinking this is less effective than a regular Daily Scrum. If done professionally. (This reminds me that Scrum in the wild often has the problem of a weak or unprofessional Daily Scrum.)
7. No Sprint Review
KITW is often played with no Sprint Review or Demo.
Scrum requires a Demo every Sprint. That includes the business stakeholders, so they can give feedback.
Now, surely some KITW teams do have a demo. Perhaps ad-hoc. For example, of each ‘card’ when it completes. Or maybe a demo roughly every 2 weeks.
But this is not nearly as good, usually, because the best people to give the best feedback are the business stakeholders. They are often fairly senior or at least very busy. So, it is better for them if, fairly far in advance, they can schedule that every two weeks (or every Sprint), they will come to the Demo (Sprint Review). This leads to better attendance and better feedback, based upon all the stories, seen together. ‘The whole is greater than the sum of the parts.”
Some KITW teams do small demos often in a 2 week period. Good! Faster feedback. But, keep in mind that in Scrum, one can also add additional feedback during the Sprint. (This can be very useful, and I generally advocate it.) A mini-demo (perhaps only to the PO) as each individual story is completed, as one example. There is no restriction on additional feedback in Scrum.
One could say the following for every item listed here — There is probably a KITW Team that does a good Demo at the end of every Sprint. Regularly. And gets good feedback. But Scrum ‘requires’ this, and so I prefer Scrum.
8. No Retrospective
KITW often does not have any Retrospective.
Of course, something like a Retrospective could happen ‘naturally.’ And does with some KITW teams.
Indeed, I am told that some years ago, there was no Retrospective in Scrum. That a Retrospective was added because it was so good and useful, and if it was not ‘defined’, then many/most ‘scrum’ teams would not do it. Or so was the experience. So, Scrum added a defined Retrospective.
What benefit does a Retrospective add? IMO, in the Retrospective, the Team should identify its top impediment and, usually, start taking serious action to fix or mitigate it. And in this way, the Team’s productivity can increase without any additional hours of work.
Having thought about these concerns over a good period of time, they make me prefer Scrumban to just Kanban.
Now, you are welcome to say that my deductive reasoning is unfair. For example, have I fairly compared ‘good Kanban’ (as you define it) to ‘good Scrum’ (as in, say, the Scrum Guide)? Ok, maybe so, maybe not. But at least you can start to see why I prefer ScrumBan to ‘Kanban’.
I do think it is GOOD to add Kanban ideas to Scrum. And specifically the Scrum board (which out-of-the-box is a basic kanban board). And to focus on flow, pull, single-piece flow, minimizing WIP, etc. Excellent ideas.
And sometimes you can’t get a Team to do all of Scrum. At first. So you start with Kanban (however you define it). I totally understand and am in sympathy and support. Getting people to change is hard. But as soon as you have that change made, start working on them to make some more changes. And adding each part of Scrum, piece by piece if necessary. Or that is my opinion.
Note: I made some substantial changes to this post on 11/24/2013. Maybe those changes would change the opinions of people who made comments before that date.