Why I prefer ScrumBan to Kanban

June 1, 2013

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.

***

Joe’s Conclusions:

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.

Comments?

***

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.

 

« « Story Points rather than hours || CBA: new Maserati vs. used Lexus?? » »

Posted in: Kanban, Key problems
Tagged: Tags: , , , ,

17 thoughts on “Why I prefer ScrumBan to Kanban”

  1. Benjamin Darfler

    You seem to have judged Kanban through the microscope of Scrum instead of engaging with Kanban based on its own goals and intent. Have you practiced Kanban before at the same level and with the same rigor that you have practice Scrum?

    ↓
    1. Joe Little Post author

      To be fair, no. I have studied and worked on lean a lot over the years. But clearly I have done more Scrum than Kanban. Let me say again, I am a strong advocate of Kanban when used within Scrum, aka Scrumban.

      But discuss the issues…I am listening.

      If you wish to assert that I have mis-defined Kanban as you know it, please say so.
      Or if you think most people play it a different way than I have suggested, please say so.
      However much I may have played Kanban (or you have), our individual sample sets are always quite small.
      So, do share yours.

      Thanks, Joe

  2. Abraham

    Hi Joel,

    Interesting points. There are a couple of things I’d like to comment:

    3. No Sprint: there is a difference between measuring productivity
    in a weekly manner and having a one-week sprint: the latter is a commitment, while the first one is just a report. The commitment will encourage (or force) the developers to stick to the expected schedule, often leading to shortcuts that create technical debt in the long-term.

    5. Dis-enhancement from the business: the engagement of the business is independent of the methodology. I have seen many places where the business think agile is just a way to manage development, so no matter whether you call it Scrum, XP or Kanban you will still miss the business. The same applies to retrospectives, etc, a review of the process is independent of the process itself.

    Mind you, I am actually quite sceptical about Scrum, as I evidenced in a post of mine called Is Scrum a Trojan horse for Agile?, so I admit I may be biased here 🙂

    All in all, good post.
    Abraham

    ↓
    1. Joe Little Post author

      Hi Abraham,

      3. No Sprint. Yes, agree there is a difference. But, I do not agree that a professional Team should or would necessarily cut corners or create technical debt. I take the point of view that adults can be adults. I speak loudly and often about how we must be digging out of technical debt, as a general rule.

      5. Dis-engagement with business. Well, Kanban does not call for any engagement. Scrum does. And that engagement is quite essential to Scrum (and part of the Agile Principles too, for that matter).

      You are of course right to say that some people can play Kanban (or Scrum) with high or low engagement. Still, I do think under Scrum, it should be and it is likely to be more and better. For several reasons. But of course, people are people, and the ideas of Scrum can never guarantee that anyone will do anything. (Equally for Kanban)

      But, I think where we both want to discuss is this… There is Scrum, as it should be played, and there is a whole lot of ‘scrum’ (or so people are calling it) that is, IMO, not very good. Maybe some advantages, but much much less than we could get if we got professional. And surely the same could be said of Kanban.

      So, surely you have seen bad ‘scrum’ implementations, and you are surely right to be unimpressed. But I think you are unfair to judge the ideas of Scrum based on how some people mis-understood them, or, without any passion or energy, tried to do them in an initial way.

      The next thing to say is that I have not seen what you have seen, nor you what I have seen. So, it makes it hard to discuss without going into lots of detail.

      Good luck with your work. And happy to talk further.

      Regards, Joe

  3. Agustín Villena

    hi!

    IMHO you are comparing two different things. Kanban is a flow management method, not a project management one.
    Kanban asumes workitems are roughly the same size, therefore if you have a complex problem to resolve, cocreating between business and development you agile management practices.
    In short, if we accept that software develop is like an expedition, we need scrum like practices to find and validate rapidly the different paths of possible solutions to our problem. Kanban would serve then as a method to transform uncertainty in knowledge in the most efficient way.

    Best Regards
    Agustín

    ↓
    1. Joe Little Post author

      Hi Agustin,
      I am fine with what you said.
      Hence, I advocate (typically) a combination of Scrum and Kanban.
      If you explain more, I might learn more about what you mean. And maybe disagree a bit.
      Thanks, Joe

  4. Felix Rüssel

    Hi Joe,

    I like your summary, saw (and continue to see) most of the described difficulties when examining “Kanban” implementations in the wild.

    Very often the teams dropped Scrum to the “process overhead” but as most of these teams are not really mature/experienced teams they usually end up working in a chaotic way and try to visualize it on a “not so update” Kanban board. However, when questioned about their process there is very often a “team leader” who insists that they are doing Kanban and everything is fine – which is not the case as all numbers and the business results usually tell.

    Really experienced teams with good people doing Kanban is a different story but usually you will find ScrumBan concepts there even in case they don’t name it “ScrumBan”.

    To make a long story short (using the SHU-HA-RI concept): A SHU team without guidance and coaching will have severe problems with Kanban while Kanban might be a perfect match for a RI team.

    Felix

    ↓
    1. Joe Little Post author

      Agree.
      And I think most great teams will do a crisp clean ‘core’ Scrum thing as well as the Kanban.
      Specifically these meetings: well, first, a sprint timebox, but then … a sprint planning meeting (assuming the work warrants it), a daily scrum, a sprint review (when all the business stakeholders are together), and a Retro (to get better).

      Thx, Joe

  5. Al Shalloway

    Joe, there is so much misinformation here I have no idea where to start. Can you tell me where you’ve gotten your Kanban/Scrumban experience? I mean, what books you’ve read, conferences you’ve attended or courses you’ve taken? There is so much misinformation out there that just observing what is happening in the wild is likely not to get you there.
    Instead of picking apart your post I’ll just send the interested reader to an article on Kanban

    http://www.netobjectives.com/files/resources/articles/Demystifying-Kanban.pdf

    as well as a blog on the differences between Scrum and Kanban
    The real differences between Scrum and Kanban http://www.netobjectives.com/blogs/real-differences-between-kanban-and-scrum
    Al Shalloway

    ↓
    1. Joe Little Post author

      Hi Alan,

      I think you are quite fair to say that I am picking on ‘kanban in the wild’. Which is somewhat unfair to some of the people (like you) who have written about it.
      I am sympathetic. ‘Scrum in the wild’ can be quite ugly too.
      I will re-read my blog post and take a look at your links, and consider some changes.
      Regards, Joe

    2. Joe Little Post author

      Hi Alan,
      After looking at your article…. In the blog post, I was not in any way attempting to provide insights or a critique about what you said (at your links).

      As I said, my comments are about what I see ‘in the wild’. And I have seen these things with my own eyes or from the mouths of those doing ‘kanban’ (or so they called it). Yes, no doubt this is not what many writers would have had them do or say (insert a list of writers, such as you, David Anderson, many others).

      I, like you, am upset that these things are happening in the wild.

      So, to me, if they do “X” and avoid the errors I speak of, it seems to me they may be doing something useful.

      I, like you, love the Lean ideas. To you, I add this. Let us talk more about doing fuller, more robust Lean in new product development. Let us not bend a simple Lean tool (Kanban) into a new Agile method. It distorts the word ‘kanban’, is unfair to Lean, etc. etc.

      If you or others want a different basic agile method to compete with or as an alternative to Scrum, then give it a new name and a fuller definition. I guess you could call it ‘kanban’, but good luck getting the other writers and practitioners to agree on what it is.

      But, anyway, these last comments are more general and not on point with my original post and your initial comments about it.

      Regards, Joe

    3. Al Shalloway

      Joe:
      Thanks for your comments. I agree that the Kanban method has been a bit of bending lean to create a brand. But Kanban software development, what you are describing, if very similar to Scrumban in many ways. The underlying mindset of scrumban is much closer to the underlying mindset of Kanban than it is to Scrum.

      I have actually been getting very vocal that teams in Kanban are very important. I don’t like that many in the Kanban community are missing this.

      In any event, discuss intents, not how it’s being used wrong. Otherwise, one could talk about Scrum-but as what Schwaber & you are intending – which, of course, it isn’t. Scrum is not being practiced by folks who, in the wild ;), are only doing daily standups and nothing else. It doesn’t serve anything to contrast with that.

      I think i even posted a blog on this – that not doing practices in Scrum doesn’t mean you are doing Kanban 😉

    4. Joe Little Post author

      Hi Alan,

      A few comments.
      In your first paragraph, I don’t know how to agree or disagree. I personally take a Lean approach to Scrum. So, in that sense, Scrum, Scrumban and Kanban all share some Lean attitudes. Jeff Sutherland calls Scrum a simple implementation of Lean for new product development.
      To really discuss this, you would have to describe the 3 mindsets carefully. I would probably disagree on your description of the mindset of Scrum.

      More and more in recent years I am totally with you on the value of Teams. There is a group of people who talk in favor of teams. Still, I see lots of people who really mis-understand, even though they say they ‘get it’. I guess that should be expected, to some degree.

      Yr 3rd paragraph: Umm. It is useful to talk in the positive. What we should do. It is useful to talk about mindset. AND, it is also useful to talk about classic mistakes. Lots of people learn mainly by making mistakes. My Hapkido master would say: ‘You have to get the gross movement started, before we can start to refine it. And by gross I partly mean “ugly”.’
      You do not need to get defensive about Kanban-butt. Nor should I or Ken or Jeff get defensive about Scrum-Butt. These are things that happen. We don’t own or control people.
      And I think talking about the ‘Butts’ helps people stop and think. And maybe change what they are doing. For the better.
      Regards, Joe

  6. Aleem Khan

    Kanban doesn’t assume all estimation is unnecessary, but it suggests looking at value received for time invested. Kanban pulls well from the features identified by the portfolio team. If you are fairly certain of your feature estimates, you may discover that detailed story estimates are not necessary.

    Whats your take on estimation in Kanban?

    ↓
    1. Joe Little Post author

      Hi Aleem,

      First, Kanban is not a person, so does not think. But that is a minor point.

      So, at least you do not assume all estimation is unnecessary, but… well, do you estimate stories in story points or not? Not clear to me.

      Kanban per se does not define a portfolio team. But you use one. Ok. Tell us more about it. It sounds like the portfolio team defines the stories in the queue from which ?? someone pulls.

      Ah, then you speak of feature and story…. I am guessing I know what you mean (others use those concepts in what I guess is a similar way…)….but I would rather not guess. Please explain how you use those concepts.

      My take? Umm. Too short….
      Kanban was built on the cards representing exactly equal ‘things’ (at Piggly Wiggly or at Toyota). So, in software, I would want my ‘things’ to be as close to exactly equal as I could get them. Then pull and flow and other things would work better.

      First, I want full engagement between business and technology. I don’t think Kanban by itself does that. Although of course it could happen. But I find Kanban typically used when engagement is low, and it is used to accommodate the impediment rather than FIX the impediment (of low engagement).

      Then I would want the Team to understand the vision, and the higher level epics, and how they might fulfill the vision. And have some discussion about that between the Team and the PO (and the business stakeholders). Then I want all the stories small — that are about to be built by the Team — and about the same size. Maybe 1 or 2 SPs each. Not much variation. And I want a Team — Kanban does not require a Team at all (although some have it). Then use Kanban on the small stories starts to help. But it would be ScrumBan by then.

      We agree estimation takes time and effort. Why do it? Well, we need the stories small and about equal in size, and the more that is so, the more effective and useful the Kanban board is in showing meaningful stoppages in flow. Also, the Team learns all sorts of tacit knowledge in the process of estimating. This is huge, and actually more valuable. The numbers drive a better conversation. But we agree there is some cost to estimating.

      Let us also agree that some managers or some people can use the estimating, here or somewhere, and do dysfunctional things. But this is an issue that must be addressed, I think, rather than avoided by not doing any estimating.

      That’s the direction I would go. I am sure I have not explained enough. Regards, Joe

  7. Simon

    Joe,

    I don’t normally bother commenting on blogs like this as the net is already full of enough ‘opinion’.

    However, I came across your post whilst pulling together some material on defect management and as I read I began to scratch my head a little.

    As I said, I’m not normally given to being critical but I found this post to be of very poor quality.

    There’s nothing new in that. The internet if full of poorly written and poorly thought out material relating to Agile. What I struggled with is that your listed experience, your professional associations (Sutherland, Schwaber Tom and Mary Poppendieck) and the organisation you represent would seem to suggest you that this surely could’t have been written by you!

    It most certainly does not read as from a man of over 20 years in the profession!

    I don’t really want to go through the whole piece, but perhaps I might highlight them offending theme?

    You open the piece with some statement about Kanban in the Wild (or at least what you have observed).

    So, right from the off you are contrasting Scrum (by which I assume you mean Scrum Done Correctly) with Kanban done incorrectly.

    The comparison is absolutely facile. What on earth does that tell us about either Kanban or Scrum?

    This then leads you to all sorts of other questionable statements about ‘no planning’, ‘no team’, ‘no review’ etc. None of which I can find an underpinning for in well regarded sources of information on Kanban.

    Instead you then keep throwing up the ‘In The Wild’ qualifier to justify your comparison or criticism.

    All you are therefore saying is you feel Scrum (done correctly) is better than Kanban (done incorrectly).

    I can assure you there are many more instances of ‘Scum In The Wild’ than ‘Scrum Done Correctly’. Can I therefore infer that Scrum overall is a bad thing?

    If I may quote you directly….

    “So, surely you have seen bad ‘scrum’ implementations, and you are surely right to be unimpressed. But I think you are unfair to judge the ideas of Scrum based on how some people mis-understood them, or, without any passion or energy, tried to do them in an initial way.

    This is precisely what your entire article did with Kanban….

    ↓
    1. Joe Little Post author

      Hi Simon,

      Your basic concerns are fair in general. And I was trying to agree with them in my post.

      I will see if I can modify my post a bit to deal with your concerns.

      It is, IMO, a good instinct in you to want to defend good “Kanban”. The idea does have something to offer (IMO), and it is not my purpose to move away from the good things within ‘Kanban’ or Kanban.

      I was trying to explain why I prefer Scrumban to ‘Kanban’. I think my post explains my preference.
      But I do agree that it can be construed as an attack on ‘good’ ‘Kanban’. That was not my intent. (I agree with you, that if that were my intent, it would be unfair.)

      And I agree with you that, as soon as I write almost anything I want to say, people will take it the wrong way. And they do. (Ex: You are not the only one who is upset with me (Cf Alan Shalloway), but you want to defend something I do not, and do not know how to, attack — good ‘Kanban’.)

      One of my problems is this: There is, to me, no one short defining statement of what ‘Kanban’ (eg, in software development) is. (In Scrum, we have the Scrum Guide.) So, I find it impossible to say, clearly, what ‘Kanban’ is. So, if I were to try to address my concerns with ‘good Kanban’ (I think I would have some) — anyone and everyone would say: “Joe, you defined it the wrong way.” And they would be justified to say that, since there is no one short definition, at least AFAIK.

      I agree there are multiple disparate long definitions. Yikes! This is a blog — I can’t read all of them, much less address all of them.

      I completely agree with you that comparing bad ‘Kanban’ to good ‘Scrum’ is unfair. Just as comparing good Kanban (as I implied, I am unclear how that would be identified) to bad Scrum would be unfair.

      Maybe a better title to my post would be: “If I were asked to do ‘Kanban’, here are the first things I would add.” Would that be a better title?

      To be honest, Kanban is defined to me by what the Lean manufacturing people do. It is only a small tool within the context of Lean. And it tries to help achieve big goals like pull, flow, and single-piece flow, and visualizing the stoppages in flow, etc. But it is only one small tool to help with those goals. But I don’t think any Lean guy would say — “if you want to have a good Lean company, just start with Kanban and you will figure out the rest.”

      Side Note: If David Anderson or Alan Shalloway or others are trying to create (or are creating) a new agile method, it would help me greatly if they gave it a new name. But there we are. Words, word, words.

      So, to me, any fair definition of ‘Kanban’ is very very simple. It is only the cards and the board with the cards. Which, from my reading of David Anderson, is all he ‘requires’ it to be. And his idea is that you add other things to it. But those other things are not defined.
      And it is the same with Scrum. Similarly, Scrum by itself is not enough to do effective work.

      So, one very real question is: Is ‘Kanban’ or Scrum too small a place to start? I really do think ‘Kanban’, alone (as I defined it above — the cards and the Board and the idea of flow), is too small a place to start. Scrum is arguably too small, except I find it impossible to start with anything bigger (maybe not every time, but almost every time, we cannot ask them to change more). The people just can absorb only so much change at one time. So, we start with the bare framework of Scrum, and move forward.

      And the same could be said about ‘Kanban’. And, one good reason for using ‘Kanban’ is that the people won’t agree to do anything more complex. That is a very good reason to start there. But to me, Kanban (as I define it) is not enough. You need to have more ‘constraints’ (in the lingo of complex adaptive systems) before the system will ‘take off’…or start to be noticeably more functional.

      So, Simon, to you three questions:
      1. What do you think is a fair short definition of ‘Kanban’ (in software development)? (~20 pages??) Or is there one?
      2. If you think a good ‘Kanban’ team would be doing more than just this minimal thing called ‘Kanban’, tell us what you think they should add to it.
      3. Of my concerns about ‘kanban in the wild’ — are there any you disagree with?

      You are welcome to talk about ‘scrum in the wild’ — certainly there are many problems! You will not hurt my feelings.
      I am unhappy with lots of ‘scrum in the wild’ too! Thanks! Joe

Leave a Reply