≡ Menu
Pawel Brodzinski on Software Project Management

Surprising Truth about Kanban Improvements


My session at GOTO Copenhagen was on Kanban improvements. My goal was to show the mechanics of improvements in teams adopting Kanban and you probably know me enough to know I wanted to build the session over real-life examples. Here is what I ended up with.

The result was a bunch of stories following similar pattern: we introduced Kanban, then some existing behaviors became visible and finally we started improving doing it either consciously or not. That was basically the point I thought about when I started building the presentation.

However when you think about it longer you notice that it’s not that simple. I mean the pattern itself is simple, but that’s not all. It’s just the tip of the iceberg.

Let’s take collective code ownership – one of my favorite examples. Consider you start with a typical situation where code ownership isn’t collective at all. You deal with bus factor of one and your life is miserable. Given that you adopt Kanban, your developers should start pulling different features to work on, not necessarily features which deal with the code written by themselves. They want it or not they have to start learning code written by others and knowledge is slowly spread among the team members. Eventually, after some time, the code is owned much more collectively than it used to be.

It’s a nice example. If we stop here it is still a nice story of improvement. But if you look a bit closer there’s much more than just that.

Let’s go back to developers pulling features from codebase they aren’t familiar with. A question: what do you think a decent developer will do in such situation? Probably they’re going to start with learning what a feature is all about. Then, and it now becomes interesting, they will start learning the code they will be changing and updating. This activity has even a name – code review. You may argue, but it actually is code review. It probably isn’t very formal but last time I checked you weren’t getting point for making code reviews as formal as possible.

It starts looking better, isn’t it? Let’s move to the next step then.

We have the situation where a decent developer is reviewing someone else’s code. I bet they spot some bad code out there. It’s kind of safe bet – we aren’t machines so we do make errors on occasions. What’s next? Well, one of ideas is to find the one who wrote that crap and make them fix it. Except it doesn’t work, because the author is either busy, already working on different project or left the company 3 months ago. It’s much more likely that the developer would improve the code by themselves. And you already have guessed – this one also has a name: refactoring.

It looks like it’s not only collective code ownership but we also get code reviews and more refactoring in the package.

That’s not all.

Look at the situation focusing on how it changes people. You teach them good practices and you do it by example. You don’t just try to convince the team that code reviews are good. You kind of trick people to actually start doing it. You give them a precious gem – real experience instead of just an opinion. You push people to learn.

Quite much of that already, but if you think I can’t draw another connection you’re wrong. This is the last one, I promise. At least for now.

Probably the best thing which happens here isn’t really about engineering practices. It isn’t about learning either – after all you shouldn’t need to push people to learn anyway. The best thing is you draw people out of their comfort zones on so many levels. They start working on unfamiliar code, they start using new practices, and they start learning new things. In terms of everyone’s personal development you couldn’t do them a better favor.

OK, now remind me where we have started. I believe it’s been drawing a connection between introducing Kanban and collective code ownership. How come we’ve gone that far?

This is exactly the surprising truth about Kanban improvements. There is no detailed plan of adopting specific practices or improving specific things. You just set the proper framework and let people figure out the rest.

I really like the metaphor David Anderson shared: it’s like organizing a good party. You bring food and beverages, you have music, you organize enough room to chat, eat, dance, etc. And most importantly you invite the right people. In details you don’t know what will happen. Your goal isn’t to plan everything to the last possible bit. You just create a framework for people to have fun.

Same applies to Kanban. It’s just a framework for people to improve. You bring your board and a bunch of simple rules. You show them the idea, but then it’s up to them where they’re going to take to whole thing.

You end up observing interesting connections between Kanban, collective code ownership, code reviews, refactoring, learning, moving people out of their comfort zones, etc. Continuous improvement in Kanban is rather a complex mechanism inside, yet it doesn’t mean it is hard to operate it. It kind of operates itself. And this is exactly the reason why it is so great.

Advertisement: Want to have such nice Kanban boards in your presentations as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.


in: kanban

6 comments… add one

  • Zsolt Fabok May 17, 2011, 3:17 pm

    Very nice and useful presentation, and excellent post. Kudos!

  • Josh May 17, 2011, 7:30 pm

    Awesome as usual Pawel. I’m so addicted to Kanban after having used it with my project teams for nearly a year now. The continuous improvement aspects are amazing, we just made some new discoveries about our optimal value stream and development cycle a few weeks ago. The visualization enables it.

  • Vasco Duarte May 18, 2011, 5:33 am

    Interestingly enough the party example is also used to explain how Scrum does exactly the same! :)

    BTW: here’s the origin of the party story: http://www.youtube.com/watch?v=Miwb92eZaJg

  • Pawel Brodzinski May 19, 2011, 1:20 am

    @Vasco – Not a surprise really. Because every reasonable approach would work similarly. I’m far from saying that this or that approach is unique in terms of fostering improvements.

    However if you want to put Scrum and Kanban on a prescriptive-vs-flexible axis Scrum would be closer to the left and Kanban to the right edge of the axis. So a Scrum party would be more planned than a Kanban party.

    Another difference is Scrum starts with revolution while Kanban doesn’t. So again, you deal with more preparation to hold a Scrum party than you do with a Kanban one.

    A final thought: depending on people you want to party with the right approach can be one or another. There is no recipe for a perfect party. Same goes with methods we use.

  • Pietro May 19, 2011, 2:18 am

    As a developer working on the codebase with collectively ownership for the last three years, I have to say that this is something I really disliked. It is quite frustrating.

    Even though I believe this approach is good for managers and alike….

    It would be good to post some comments from non manager developers probably….

  • Pawel Brodzinski May 19, 2011, 6:52 am

    @Pietro – I’d love to see your thought on the subject. Why didn’t you like collective code ownership. From your perspective: what worked and what didn’t work? Why was it so?

Leave a Comment

Next post:

Previous post: