Recently I had a lot of occasions to discuss Kanban with other people, the coolest one being last meeting of Engineering Academy “Diamond Polishing” (for you who speaks Polish there’s video recording available online). One of things which I stressed during these discussions is that Kanban is not enough to manage a software project.
I already shared practices we employ and those we don’t. But it is important and worth stressing: you can’t just base on three simple rules of Kanban (limit WIP, visualize workflow, measure lead time) alone. Without best engineering practices your product would suck even though you rigorously followed the rules. That’s not the problem of Kanban only – the same is with Scrum. Kanban is here just to help you to organize work better. If you do crappy job it’s still going to be crappy, just organized a bit better.
What more, while heavy-weight methods enforce some order because of specifying scope of work up front, using formalized acceptance tests etc, Kanban leaves it all open. In other words doing Kanban wrong way you can do much worse than doing Prince2 wrong way.
We set up a list of practices to avoid the problem. When I think what results we would achieve if we had no continuous build, no unit tests, no knowledge exchange in terms of learning other developers’ code and no coding standards I’m scared. We’d probably land in never-ending loop of dirty-fixing old dirty-fixes to old bugs just to get anything done.
All these practices sound very natural now but, to give one example, I confess that’s my first successful approach to unit testing since I manage software development teams.
So no, don’t treat Kanban as a silver bullet which fixes everything in a second. It’s just the part of the job. The rest isn’t enforced, but you have to figure out right pieces by yourself. Continuous integration and automatic testing are rather mandatory if you care about quality and want to ship often, but there is no universal way which works for everyone.
Read the whole Kanban Story.
If you like the story or hate it or just want to win signed copy of Scott Berkun book Confessions of a Public Speaker leave some feedback here.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
5 comments… add one
This is a valuable reminder that we shouldn't be dogmatic with our approach. I particularly liked " it’s still going to be crappy, just organized a bit better." – that made me smile :)
We often fall in something I call methodology trap. We get excited about some cool idea and we're all "this is so cool, let's do it." At the same time we forget implementing this or that method isn't a goal.
I agree with your post, but I don’t think I’ve ever read anywhere that Kanban alone is enough. That’s one of the big differences between Scrum and XP, for example. Scrum doesn’t prescribe how you write your code, whereas XP does (TDD, pairing etc). Kanban as a technique is directed at a different level of the problem.
Joshua,
Yes, Kanban doesn’t say how exactly you should code, but the same XP doesn’t say how you should manage your tasks. If you’d try to run a project using XP alone I wish you good luck but you aren’t going to succeed. Anyway Kanban is way closer to project management as we understand it than XP.
Anyway, I’m not surprised to see people trying Kanban alone as their panacea which is plain stupid. That’s how different ideas are adopted pretty often. Scrum or XP not being different here.
It’s all about people though. They either choose a practice to adopt because it suits their situation or because it sounds cool. In the latter case I wouldn’t like to work with them.
Yes of course, no one suite of techniques or principles is going to solve your problems.
I also agree that adopting a technique or practice should be in response to some issue, not just ‘because it is cool’.
I am working on a blog post on my thoughts on that subject.