Geek Philosophy

All of this Kanban reading I’ve been doing has been great, and as I’ve mentioned before I’ve started implementing some of the techniques and metric tracking. However, after meeting with my manager (himself an experienced Agile thinker), I’ve realized that in some ways I’m trying to solve problems I don’t have, while neglecting some of my bigger issues.

Limited WIP is of course one of the key techniques / philosophies of Kanban (and lean in general). It’s not important in and of itself, but instead because out of it comes increased collaboration, reduced cycle time, identification of bottlenecks, and all of that other great stuff. We haven’t really reaped any benefit from this (yet) besides limiting the backlog, which has fostered cross-business-unit collaboration, but it’s only been 3 weeks or so and we were a fairly disciplined team before that. Some of the metrics I’ve been tracking (such as how long bugs have been in the system before we ship them, and how long items are blocked for) will definitely come in handy to measure the team’s effectiveness and customer responsiveness.

That said, we’ve never really had much of a problem with Work in Progress, at least at the task level. After talking with my manager, we realized that we had another problem, one that was discussed by Johanna Rothman at the recent Agile Vancouver conference – far too many items in our project portfolio! We have 8 people on the team, and had limited our active WIP to 12 (to allow for some blockages), but it turns out that we were working on 7 different, mostly independent projects.  Most of these projects were rather small, and the diffusion of resources was mostly due to the fact that there was no obvious parallelization for most of the projects, but still – that’s almost 1 independent project per person!

Due to the nature of my team (maintaining 3 products, and integrating these products once monthly with software from elsewhere in the company), it’s unlikely that we’ll ever get down to a project WIP limit of one. After we clean up the current mess, we’re going to try 1+1 – a maximum of one project on the go at any given time, with the exception of these small monthly integrations. With the slack time, we can clean up some of our (ample) technical debt. Part of the metrics I’ve been tracking is the percentage of our work spent on “failure load”, a combination of technical debt and missed requirements.

This will likely start in earnest in the new year, but I’m already excited about the results. I’m actually surprised that I let it get this bad – we’d been effectively doing a 1+1 project WIP limit for most of the past year and a half – but I think by formalizing the process a bit more (not making it heavier though!) we can keep ourselves to good habits.