≡ Menu
Pawel Brodzinski on Software Project Management

What Kanban Really Is


I promised to share more thoughts on my Kanban presentation from AgileByExample. Actually during abe2011 there were 3 sessions which touched Kanban in one way or another. And then, well, and then there was a heated discussion, mercilessly cut off by the conference hosts. Even though we didn’t convince each other to our points (after all it isn’t the goal of discussion, is it?) I definitely learned a lot from it.

First, to set the tone, my presentation.

I shared the story how, thanks to Kanban, in one of my teams we improved our engineering practices and changed our behaviors. Kanban is such a nice improvement vehicle and I wanted to show it.

Then, Marcin Czenko shared his experience with Kanban pointing that it is a tool for more experienced teams and that, generally speaking, teams shouldn’t start with Kanban. They should start with something more structured, like Scrum, and only then evolve toward Kanban.

That’s how the beast has been awakened.

I’m a living counterexample of Marcin’s hypothesis but that’s not the point. Actually Marcin’s session was just one example of something I kind of know. I mean I remember when I treated Kanban the same way. It was a couple of years ago.

Let’s consider for a moment that Kanban is a project management of software development approach. With just a few rules Kanban can be a dangerous tool. I mean it leaves much freedom which can obviously be used in many different ways. To sanction chaotic process for example.

OK, the moment has passed: Kanban isn’t goddamn project management or software development method! Kanban doesn’t tell us how we should build our software. It doesn’t say a word about managing projects. I don’t say you can’t use Kanban to help you dealing with software projects though. You sure can. Heck, this was the initial idea, or so I believe at least. But I beg you; please don’t rely in this area on Kanban alone. And if you do, don’t complain later.

Kanban is a tool which helps to deal with changes and improvements. If used as they say in the instruction it should allow you to improve. Improve your process, your practices, your behaviors and your attitude. However, Kanban is no guarantee that you will have the best organization around. It doesn’t even give you some sort of benchmark which allows you to compare your team to others.

With Kanban you don’t go to a specific point, or a specific organization, which looks like for example Scrum by the book. With Kanban you just try to be better tomorrow than you are today. Oh yes, it means that tomorrow you totally can have crappy process, useless practices, bad behaviors and negative attitude, but at least the direction of changes would be right and they would be slightly better than they used to.

Now, if you treat Kanban as your project management or software development method you are disappointed and rightfully so. You could have done better applying one of proven methods which, when done right, sort many things out from the day one. But don’t blame the method. Blame people, in this example meaning: yourself.

Coming back to unfinished discussion with Marcin: I would advise Kanban as a good choice for many teams which aren’t experienced much. They actually might very quickly move past the point, which they would have been in if they’d chosen to start with by-the-book method. It all boils down to their attitude to Kanban. As long as they understand how it works achieving quite impressing results is that hard.

I am well aware this whole thing isn’t obvious and people treat Kanban differently. Especially when they played with it only in one specific environment. I don’t blame them. I explain, I bring examples, I discuss. It seems sometimes I even argue and write longish rants. But it is work which I really love to do. So, thank to Marcin, here it is: an overgrown explanation of one of my favorite David Anderson’s quotes:

Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.

in: kanban

4 comments… add one

  • Agile Scout September 19, 2011, 8:41 pm

    On point friend. I wrote about this before in a kanban post titled “Kanban is GREAT for n00bs… – Beginning Agile teams.”
    Why is it great to start with? Because it really is that simple. Just as you said, it’s a start… in which we hope to improve on tomorrow.

    Here’s the link if interested:

  • Kenneth van Rumste September 20, 2011, 1:06 am

    Pawel, please add a tweet button to your blog posts, it makes life easier… :-)

  • Pawel Brodzinski September 21, 2011, 11:20 am

    @Kenneth – I probably should, although up to this point no one complained :) There’s probably more of blog grooming waiting for me soon.

  • Pawel Brodzinski September 21, 2011, 11:31 am

    @Agile Scout – I had quite a few heated discussion on Kanban in this context recently. Actually, I believe you oversimplify the problem. However, even then I’m closer to your approach than to “you have to go through all that Scrum/XP stuff before you proceed to Lean” attitude.

    I said that Kanban alone is not enough quite a long time ago. You can perfectly go toward disaster using Kanban and you won’t be saved.

    However making excuses that first you have to be great in terms of engineering and/or process before you evolve to Kanban is, well, just that – making excuses.

    You can improve starting from a total chaos and, as long as you don’t expect overnight success, there’s sort of satisfactory point somewhere in the future. And yes, Kanban is a very good tool which you can use to support this process.

    I will object to statement that Kanban is a sure-shot method for noobs or for inexperienced teams. It just can, but not necessarily has to, help.

Leave a Comment