This Week in Kanbandev – Dec 29, 2010

Jan 07
2011

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!

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).

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.

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?

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!

Experience report for students

Jan 04
2011

As previously mentioned, I’ve got a talk coming up for a UBC class. This is the required software engineering class in the UBC Computer Science program, and a class I vividly remember as being a waste of my time. Fortunately, the course content has changed quite a bit since I took it – after four months in this class, I came out with a 25 page specification package and no code written. It was one of my least favourite classes, and it convinced me that I didn’t care at all about process (how things have changed!).

I spoke at this class during the summer, but I plan to deliver quite a different talk this time. Part of this is time – this summer I had two hours, and two weeks from now I have half that. Time isn’t the only factor – the more fundamental difference is in the content. While the talks I’ve given to previous classes before have been rather broad overviews of Agile (and more recently Lean) concepts, this time I’m going more with what I know best. That means less theory, and more description of how my team successfully delivers software. I’ve talked to the class instructor about this and she also thinks it’s a good idea.

I’m still finalizing an outline, and I need to make sure I present this at a level that’s approachable to a class of students who likely have no real (professional) software development experience. I also hope to find time to polish my slides, and make sure I’m not just reading list after list of bullet points, but I’ll have to see what time permits.

Starbucks tries Lean – sort of

Jan 03
2011

The article isn’t thick with details, but it looks like Starbucks is trying to apply practices (if not principles) from Lean manufacturing to their front-line staff. Unfortunately, it looks like they’re taking a top-down, command and control approach, pushing out rules that make no sense to the employees. They seem to be missing the key principle of empowering the workers.

It’d be interesting to see if they tried this out in a few stores and found substantially improved results. Hopefully they didn’t miss the “Check” and “Act” sections of PDCA.

Visit Our Friends!

A few highly recommended friends...

Pages List

General info about this blog...