Scrum & Kanban

November 20, 2011

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.kanban-card

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.

« « Scrum teams and living in packs || Why call it “BV Engineering?” » »

Posted in: Better Agile, Kanban, lean
Tagged: Tags: , , , ,

5 thoughts on “Scrum & Kanban”

  1. Matthias Marschall

    Thanks, Joe, on your thoughts on Scrum, Kanban, and Lean. Too often people forget that Scrum and Kanban both are founded in Lean and that none of them is complete in itself. It's really important to understand the underlying Lean principles – only then people can improve their processes to make them more successful.

    ↓
  2. Joe Little

    Hi Matthias,

    I agree. I guess I will add this. To me, Scrum's 'incompleteness' is a virtue. While, if by Kanban one means the cards and some small usage around that, then Kanban's in completeness is a problem.

    I think/hope most decent Kanban implementations avoid the problems I am concerned about to a fair degree.

    I hope I explained those two comments in the post well enough.

    Anyway, completely agree with what you said.

    Thanks!
    Joe

    ↓
  3. Jay Packlick

    Joe,
    Ahh..you can almost feel the learning in the air, can't you? (smile). It must be that time of year.

    I couldn't agree more with most of what you've shared above; either the tools we're using help our teams and customers or they're not. Sometimes it's a problem of fitting the tool to the context, and sometimes it's a problem of learning and maturity.

    Re. mastering Scrum before attempting Kanban; generally, I've found that teams unable to curtail their carryover lack the skills to limit WIP in activity queues. This is patently obvious when you realize that, from one point of view, a Sprint is essentially Kanban with a single time based queue (i.e. where the WIP cap = estimated capacity of the team for the duration of the Sprint)

    Regarding those smiling faces, on the teams in which we've implemented 'Scrumban', I've observed the opposite phenomena you describe; business has been ecstatic about the increase in flexibility and reduction in cycle times. They're more engaged, not less (and in a healthy way). The teams seem happier too. Maybe it's just a difference in contexts or execution?

    Regarding metrics, I'd be interested in hearing what problems you've encountered with 'cycle time per story point'. It seems to provide fairly useful feedback for evaluating the outcome of tweaks to the way the team manages flow (nothing's perfect of course). It's also a pretty handy way to spot deficiencies in the team's ability to estimate effort relatively (the yucky graphs just jump out at you).

    I'm looking forward to reading about your thoughts and/or experience on the discipline of story decomposition (size) to improve flow. Regardless of methods of visualization, it seems a vexing (and sometimes fruitless) pursuit for some categories of problems. In lieu of that, I've seen some pretty good results limiting WIP in activity queues based on story points rather than story counts. Oh… wait… that's what we do with Sprints in Scrum. Never mind. Old news. (smile)

    Extremely thoughtful post,
    Thanks!
    J.

    ↓
  4. Joe Little

    Hi Jay,

    Glad to hear that Kanban has gotten MORE customer/business engagement. As you suggest, anything is possible depending on the specific people involved.

    I have observed (although not proven to myself) that the business can want too much flexibility, ie, they become 'whimsical' not because real life is changing, but because of their political dysfunction. I do hope that is not the case for you. I can imagine it not being the case, too.

    My next concern about 'pure' "Kanban" is that we lose the demo. And the right attendance at the demo. To me, we want people there who will tell us: "Well, it's pretty much what we said, but now that I look at it, it's not what I want." At most of my clients, we can only get a bunch of those guys to show up about once every 2 weeks. Now, if you can get them to show up daily (and I have been in a few places where you can…well, every day that 'their' story is being worked), then it's a different problem.

    My last concern is the tendency of me and others to be lost in the weeds. We need a cycle (every 2 weeks?) of looking up and saying "now, where were we actually trying to get to?" Or, to put it a different way: what do we think the minimum marketable feature set is today? Again, most of the kinds of firms I work with need this. I have also seen firms where this issue is very different.

    One more thing you point out… we do not do Scrum or Kanban or whatever without thinking about the principles that the related practices are attempting to put in play. Only when we are in sync with the music do the dance steps become wonderful. I think many of us are dancing the steps, but no longer hear any music. It is a wonderful thing for a man to see a beautiful girl realizing the music in her dancing. Much the same applies, by metaphor, to our work. It can be wonderful.

    Thanks!
    Joe

    ↓
  5. Jay Packlick

    Joe,

    Thanks for the response.

    Any mode of development that increases intimacy with business or extends decision event horizons brings with it the risk of gratuitous vacillation in choice. Coping with that very real threat is one of the reasons why the "Individuals and Interactions" side of the Agile equation get's the bold letter treatment. Mastering when (and when not) to change design decisions requires discipline and the acquisition of that discipline is heavily influenced by corporate culture (what isn't?).

    I find that with a little creative coaching, seismic swings in direction can usually be nulled out without abandoning an otherwise helpful approach to creating products.

    My "Warning Will Robinson" ring tone goes off whenever I hear words like "pure" and "true" used in close proximity to any process or tool in a sentence. Process purity should always take a backseat to team effectiveness. Most Scrumban teams I've seen continue to realize value from doing demos and maintaining a planning / review cadence so.. why change? That's really up to the team. What's cool is that with iterative approval by product owners, there's a LOT fewer surprises when you get to those mile marker ceremonies. As mentioned, you do have to keep an eye on the thrash.

    I LOVE the music / dancing metaphor!! Grace and elegance emerge when the fundamentals become second nature; the trick is getting them to stop staring at their shoes, lift their heads, and find that harmony of flow (…quickly ducks before the metaphor police come by to clobber him with their night sticks…)

    Cheers!
    J.

    ↓

Leave a Reply