jml's notebook
Reading: Kanban in Action
Around June I made some pretty big changes to my team at Memrise.
One of the things I was convinced of was a greater need for discipline in our process. It's not that people were skiving off, or running amok. It's more that we have a lot of things to do, and it felt like I was always figuring out what we were doing from scratch.
I've long believed in "lean thinking", ever since being indoctrinated by the Poppendieck's in 2007, and seeing it work well within the Launchpad team at Canonical. However, I've never actually run a software engineering team according to its principles.
I reached out to Kanban in Action by Marcus Hammarberg and Joakim Sundén because I was looking for a practical "how-to" guide for actually using kanban in my day-to-day. It served that job pretty well.
The book is pretty short, but still a lot longer than I'd like, and the illustrations (both the pictures and the examples) are a bit too cutesy-woo for my taste, but that can be glided over to get to the meat of the book.
Part of the reason for the book being too long is that it starts by justifying kanban and lean thinking, and this is justification that I don't need... or at least thought I didn't.
The book's rallying cry is "stop starting and start finishing". And it turns out, I am really bad at not starting things. Time and again I'll do some little thing that turns out to have non-trivial consequences, or I'll do a refactoring that's been on the back of my mind for days. This isn't necessarily a bad thing, and in a job interview I might even call it "initiative", but the "init" is the easy part. I'd much rather have "conclusative".
In the first few weeks after implementing kanban, it quickly became obvious that my habit of starting things created too much work-in-progress, which in turn slowed everything else down.
This is why the authors' efforts to justify kanban were worthwhile. The justification is a predictive model that you'll finish work faster if you do less. When you start kanban, this is a bit of a leap of faith, and it certainly felt uncomfortable for me. "Knowing" (or at least, being repeatedly told) that things would be better if we reduced work-in-progress helped me be disciplined with myself, and also to enforce the limits on my team.
That said, I also had some specific questions going in that the book helped me answer:
- how should I run my standups?
- what other meetings or rhythms do I need to support the process?
- what breaks or opportunities for celebration can I build in, to avoid kanban becoming a constant grind?
- what exactly should people do when WIP limits prevent them from starting new work?
- how should I set my WIP limits?
The book has relatively decent answers to all of these questions. Most of the time, the answers are "it depends" The authors gently mock themselves for this, pointing out how typical it is for consultants to say just that., but the authors provide enough guidelines that I was able to figure out something that worked for me.
I'm still searching for "the" book on lean software development. This isn't it. It's OK, and if you're looking to implement kanban and need guidance, you could do a lot worse.