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.