≡ Menu
Pawel Brodzinski on Software Project Management

Scrum versus Kanban

Agile

These days every blog discussing agile topics should have a big hairy article on Scrum versus Kanban, so here it is. Well, just joking. Actually many people, way wiser than me, approached that subject some time ago already presenting different arguments. If you want to hear some of the strongest opinions out there check Ken Schwaber’s post on how Scrum is good and Kanban sucks. If you look for more weighted opinion David Anderson shared one. Just recently Mike Cohn also added very reasonable two cents to the discussion even though he actually doesn’t agree with David.

Also there’s been a lot written about Scrumbut and Scrumban. I don’t see the point in repeating once again that if something works for your team – go for it, no matter if that breaks the orthodoxy of the method of your choice.

Note: I’m well aware that until now I just share what I’m not going to write about. Is this post is going to be just a set of links to some good articles though? No, not exactly, but please do check mentioned articles – they’re a piece of good reading. Anyway, to the point. There’s one thing which is often mentioned as one of main differences between Kanban and Scrum but I think this is the core of the whole this versus that thing.

The point

From pretty much every Scrum and Kanban comparison you’ll learn that introducing Scrum is a revolution while with Kanban it is rather evolution. You’ll also be pointed that both approaches foster improvement. Now, finally, after all that beating around the bush: my point here is how Scrum revolution differs from Kanban evolution in terms of introducing improvements and why it is so.

Team model and software development process

Let me start with something I was learning for quite a long time (no, I’m not that bright to catch it during the first class):

Scrum proposes pretty damn good team model and process for building software.

If you look for model team which would work in majority of situations go for a Scrum team: cross-functional, small and tightly-integrated. If you look for healthy approach to software development you can’t really go wrong with Scrum. Scrum is well-thought and well-weighted approach. No surprise it ruled the agile world.

On the other hand Kanban tells you that your team model is good for now, no matter how it is organized. And your process of building software is OK even if it’s pretty chaotic. For now.

Kanban doesn’t propose any specific team model or software development approach.

It basically means that you get no hints whatsoever how the well-organized team would look like. Nil. Nothing. Find out by yourself. No help here. Well, almost.

The difference

When organizing Scrum team you can basically turn your thinking off. Well, sort of. It’s all in the book. Someone took the effort to propose team model which I’ve just labeled “pretty damn good.” Same with the process you’re meant to follow.

Kanban chooses the other approach: we don’t know what optimal solution for your team is. Here’s some help but you’re going to learn it by yourself.

The difference? Pretty damn good doesn’t automatically mean optimal. Scrum is optimized for majority of teams, not for your unique group. Yes, of course, Scrum has improvement mechanisms, retrospective being the flagship here, but in terms of general rules it stays unchanged.

Kanban accepts that starting point may be way worse than in Scrum case but leaves you all options open. You aren’t really constrained with specific practices or models. What you’re going to end up with is totally on you and your team.

Help you get

You can put it in other words if you prefer. Scrum tells you how you should change, at least to some point. Scrum is like your mother-in-law – she always knows that you suck here and there and how exactly you should act to be um… better.

Kanban on the other hand is like your friend, close but probably not the best one you have. He’ll try to show you where you could improve but won’t state it explicitly. It’s just not that kind of relationship. It will be rather a set of hints and smoke signs – it’s you who chooses to use them to change yourself or just ignore them.

Which one is better

Neither. Despite comparisons I’ve just use I really think there’s no winner here. And yes, I’m generally considered as a Kanban guy but I also strongly believe there’s no silver bullet.

If you need a kick start Scrum may give you one even though it imposes some constraints on the way you work. On the other hand if you have in your team someone who is experienced with variety of different methods it may be a good idea to start with Kanban and check where it’s going to lead you.

After all, since I’m not an orthodox, I’ll also tell you should experiment like crazy, no matter which path you choose. Heck, that’s where all those Scrumbans started – people were changing their process, people were breaking The Holy Rules of The Method just to end up with something more optimal for them.

Final thought

If I want you to remember one thing from this post it would be: Scrum tells you explicitly how to organize work and improve things, while Kanban tells you nothing about the ideal models and helps you find out the optimal way by yourself.

After all, this post is big and hairy so I guess I succeeded with the task anyway.

Advertisement: Protect your business from a surprise software audit with License Dashboard.

 

in: kanban, project management

12 comments… add one

  • Jim Benson March 7, 2011, 2:53 pm

    Pawel,

    Nice post, except for the fact that you left out the name calling and finger pointing. :-)

    The one thing I would say is that kanban does provide you with a model, but it’s a discovery and adaptation model. Yes, it can be laid over any existing process. But it seeks to improve whatever process you pair it up with.

    Jim

  • Pawel Brodzinski March 8, 2011, 12:21 am

    Jim,

    Yes, Kanban provides you with tool to improve… as long as implemented well. But basically the same thing you can tell about pretty much any method out there. Actually I don’t know any approach which tells you “don’t improve.”

    What I like about Kanban that much is you often improve unconsciously, which also looks effortlessly even if the latter isn’t really true.

  • Vin D'Amico March 8, 2011, 10:16 am

    Interesting perspective. I believe that Scrum offers an approach or at least some guidelines for developing good software in a team-oriented environment.

    Kanban does that too but is more focused on staying lean and continuously improving. In the end, there is a large overlap.

    Development teams need to ask themselves what is important to them and to the company. If my priorities are different from yours, we will never agree on an approach. It’s not about whose ideas are better. It’s about whose ideas best align with the priorities.

  • Zsolt Fabok March 8, 2011, 11:43 am

    Hi,

    We (I) recently moved from Scrum to Kanban (+XP), and the overall feedback is quite satisfactory ;-) . I’ve wrote a post about the reasons (http://www.zsoltfabok.com/blog/2011/02/05/xp-with-kanban-instead-of-scrum/). Maybe one can find some usable thoughts in it.

    Cheers,
    Zsolt

  • Pawel Brodzinski March 9, 2011, 2:17 am

    Vin,

    Actually I’d go even further: suboptimal process which is applied correctly and everyone agrees with it is much better than optimal process implemented wrong or with a lot of controversy attached.

    Some time go I wrote: good waterfall is better than bad agile and I thought about exactly that situation.

  • Pawel Brodzinski March 9, 2011, 2:23 am

    Zsolt,

    Thanks for a link. Interesting reading. We were driven by similar reasons when we decided we don’t want to go with Scrum and then tried Kanban. I shared our story as well.

  • Zsolt Fabok March 9, 2011, 12:49 pm

    Hi Pawel,

    Nice series of posts. I like the idea to stop doing stand-ups and retrospectives. If the team members are working very closely they are not needed anymore.

    Cheers,
    Zsolt

  • Pawel Brodzinski March 9, 2011, 1:34 pm

    No-meeting culture (that’s the term we coined) was a kind of epiphany for me. I mean I knew the value of stand ups and retrospectives and I would never just resign from them, but somehow I didn’t think about, well, just changing the form of them into something different, yet yielding similar (or better) results.

  • Zachary B March 30, 2011, 3:01 pm

    To me it seems like the development teams that want to be agile and implement the scrum methodology, but end up going on their own path (with some scrum characteristics) decided to just name it. Hence, Kanban was born.

    Cheers,
    Zachary
    Axosoft.com

  • Pawel Brodzinski March 30, 2011, 10:45 pm

    Zachary,

    The more I think about it the less I’m convinced Scrum and Kanban are just different flavors of the same method. Actually the approach you describe already had its own name – Scrumbut.

    Kanban doesn’t start with Scrum as the beginning point. It starts in a completely different area. Of course you’re perfectly free to bring Kanban pretty close to what you have in Scrum but that’s not the only way.

    I used to think that Kanban is similar to Scrum but a bit lighter but I don’t anymore. But then, since I use Kanban versus Scrum comparison not only in this post but also in my presentations I guess this is the perspective which we should accept and get used to.

  • John Quincy October 29, 2011, 5:55 pm

    I have never witnessed SCRUM working — ever! Any project that started out as ‘agile’ but ultimately succeeded did so only because common sense finally set in and the decision makers decided to abandon the fad.

    I’m convinced that the following video hit the nail squarely on the head as to why any company has ever attempted agile:

    http://www.youtube.com/watch?v=nvks70PD0Rs

    John

  • Pawel Brodzinski October 31, 2011, 3:26 am

    @John – I’ve seen Scrum working. I’ve seen Scrum helping teams. And you give a clue how it should be approached, or used, to make it useful – common sense should always trump any by the book method.

    However, books are there for a reason. I like the story someone shared with me in the past: they started with Scrum, trying to choose reasonable parts of it. After a couple of failed tries, when changes didn’t stick, they decided to start with by-the-book attitude. This time they succeeded with the change. And then, they started evolving the method to adjust it to their specifics.

    It seems adopting the named method, which formalizes different things, helped them to change attitude of the part of organization. Then, of course they were able to improve the method as leaders of change knew what they were doing.

    Personally I don’t know which method I would use if I was there, but since they improved, I consider it a success.

Leave a Comment