Why I prefer ScrumBan to Kanban

This content is syndicated from LeanAgileTraining by Joe Little. To view the original post in full, click here.

I have spoken before 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.

Of course, what ‘Kanban’ is actually in the wild varies a lot.

So, here are my concerns about doing ‘Kanban’ alone, without Scrum. And I describe many specific ‘Kanban’ practices or lack of practices. Each example item from the wild will not be correct in many a specific case (in a specific implementation of kanban).

1. No upfront planning.

It is fine and correct to say that waterfall does too much upfront thinking.  But 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.

In the wild, many Kanban people do not even do any Sprint Planning. Much less ‘agile release planning’.  Which I think is almost always sad. 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, well then I guess there is no point in Sprint Planning.  But I have never seen this situation (although it still may exist for some people). 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.

People (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.  But, we also must never again suffer the illusion that we have all the information upfront. That too is patently incorrect.

2. No Team

Kanban in the wild does not require 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 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.

Kanban is often played without any concept of a sprint or iteration time-box.  Although 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 that the Team and the people around the team can see productivity per Sprint (a measurement or feedback loop).

4. ‘Scrum does not allow any changes to  the Sprint Backlog’

This is a reason people give for using Kanban that is not correct.

First, it is true that Team productivity is getting killed by interruptions and whipsawing.  So, we want to minimize disruptions. And the first, overly simplistic rule to get the ‘kids’ straightened out is: No changes to the Sprint Backlog.

But Scrum is not opposed to common sense. So, 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’, this sprint at least, to the 2SP story).

So, this need to address to-be-identified-high-priority work is a false reason to switch to Kanban.

5. Dis-engagement from the Business

Kanban as played in the wild is often used 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 that is what I see happening.  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 Kanban used this way.  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) 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

Kanban in the wild often has nothing like a Daily Scrum.

All Lean teams do a short daily meeting (AFAIK). Why do ‘Kanban’ teams not do this?  Well, they often say they don’t want to stop ‘continuous flow’.  But then, still, everyone goes home at night and flow stops.  Lean 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.

So, I think the Daily Scrum adds a lot in enabling the Team to sync up, self-organize and self-manage.  As a Team.

(Kanban does not require any Team concept.  But sometimes it is played with a Team. So, a Daily Scrum would enable them to do a better job in collaborating, etc as a Team.)

One Team (and I think I believe they are a real Team) that uses Kanban 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.  Although, to be fair, many so-called Daily Scrums are…not really what they should be — they are not done professionally.

7. No Sprint Review

Kanban in the wild is often played with no Sprint Review or Demo. AFAIK, Kanban does not require any demo. (A problem with speaking authoritatively is that there is no ‘authority’ on ‘Kanban’ as used in software development. Surely there must be a ‘Kanban’ book that advocates a demo — but I digress. This conversation is about ‘Kanban in the wild’, not about any book version of Kanban.)

Related to that, Scrum requires a Demo every Sprint. That includes the business stakeholders.

Now, in Kanban one could have demos.  Ad-hoc. For example, of each ‘card’ when it completes, for example.

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.’

In Scrum one could still add additional feedback during the Sprint. (This can be very useful, and I generally advocate it.)  For individual stories, as one example. There is no restriction on additional feedback in Scrum.

8. No Retrospective

Kanban does not require any Retrospective.

Of course, something like a Retrospective could happen ‘naturally’.

But from lots of experience, we think the odds of a regular and good retrospective go down considerably if there is no ‘required’ meeting to make it happen.

Again, to be fair, lots of ‘scrum’ Retrospectives are done in name only. And are not good or not very good. I want them not to call that kind of unprofessional work ‘scrum’. But of course I and we cannot enforce that.


It is fine to add more 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. I totally understand.  Getting people to change is hard.  But as soon as you have that change made, start working on them to make some more change.  And adding each part of Scrum, piece by piece.


One response to “Why I prefer ScrumBan to Kanban”

  1. Pati says:

    Nice post. I like thinking about joining Scrum and Kanban as giving a very creative but a little chaotic person a list of the most important goals and ask him/her to write down a concrete plan to achieve them. As written short (yes, really short, I hate long texts ;)) here kanbantool.com/kanban-library/scrum-and-kanban/kanban-vs-scrum-how-to-make-the-most-of-both , they do have their differences but they’re a chance to create a very supportive tool. So I’m glad you write about ScrumBan, including some common mistakes.

Leave a Reply

Your email address will not be published. Required fields are marked *

nine − four =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”



To explore how we can help you, please get in touch