Geek Philosophy

Buoyed by the success I had in sticking to a post-a-day schedule in November, one of my “end of year personal goals” (new year’s resolutions, you might call them) is to write more. Another goal is to keep more in step with the current state of the art of the Kanban community. Combine the above with positive feedback I received about my summarization ability, and you get a new series – This Week in Kanbandev, a weekly update where I discuss some of the happenings on the always-interesting Kanbandev mailing list.

The initial goal of this series is pure self-improvement. It will get me writing, and it will get me reading Kanbandev, two things I’d like to do more of. Summarizing and explaining my reading will also help me solidify what I learn. These posts may be useful to some people, but that’s purely by accident . I can’t promise not to color my commentary with my own personal worldview, knowledge or experience (or lack of any of these), but I’ll try to call out any relevant biases when I can.

Now, onto the first week!

• Why should we size?

The value of estimation gets discussed quite a bit on Kanbandev. This thread reinforces the fact that Kanban doesn’t actually say anything about whether a team should estimate or not – if it provides value, keep using it. That said, there’s a heavy bias (possibly justified) on the list against using detailed estimates for planning. Personally, I’ve gone away from doing estimates for small, flow-based projects, and for larger batches of functionality I’m trying to shift towards using “t-shirt sizes” (Small, Medium, Large).

• Working on one item vs. multiple items

Limiting work in progress is one of the Core Properties of Kanban, so of course it gets a lot of mind share on the list. This conversation quickly turns into a pretty standard checklist of the steps to go through when trying to determine a WIP limit – keep policies explicit, measure lead time to gauge effect of changing the WIP limit, and keep stakeholders involved in the process and informed of the results.

• John Seddon about “Lean”

This thread got into the semantics of Lean, a mindset and series of tools that are in many ways a spiritual predecessor to the Kanban Method. The thread got a bit derailed by cries of commercialization, but it did spawn a great discussion on the topic of leadership – who are the leaders of Lean community? What does it mean to be a leader?

• Batching up releases… necessary or just patching over a symptom?

This was the most interesting thread of the week, in my opinion. I first heard of the concept of continuous deployment when I saw Eric Ries speak 18 months ago at the Agile Vancouver Lean mini-conference. The idea makes sense, especially with the “Stop Starting, Start Stopping” focus of Kanban, but there are differing opinions as to whether single-issue deployment is always a worthwhile goal to try to attain – for my current team, I prefer batches, albeit small ones. This thread also forked off into interesting discussions of the negative aspects of the phrase “Kanbanista” (summary – don’t use it, it fosters cliques and ossification), and what to do when your Kanban board says you’re overstaffed (summary – layoffs are sometimes the answer, although give new products a shot too).

Well, that’s it for week one. Next week, I’ll take notes as I go so I don’t need to re-read every thread of interest!