“When you’re finished changing, you’re finished.” – Ben Franklin
Lean software development was actually my introduction to agile through the Poppendiecks’ book, but we brought in an agile coach to refocus our teams on what it means to actually run a lean software shop.
So, as I often do, I dove headfirst into studying. I read anything I could get my hands on even remotely related to the Toyota Production Systems (TPS) and quickly realized that while TPS concepts have been around since the 1930s (and lean principles much longer than that), lean software development is very much in the early stages of application. There is really no consensus in the community as to how to run a project, but James Shore wrote a really good article that contained a sketch for a Kanban Planning Board. Below, I’ve modified it to incorporate a non time-boxed retrospective concept that was discussed on the Kanban Development Group and added a couple of team motivation concepts.
At the top of the board is the overall goal of the current project. Having this so prominent should help the developers not get so involved with the trees (Minimal Marketable Features) that they lose sight of the forest (the project).
Along the left hand side, you have the current MMF that the team is working on as well as the backlog. The order of this backlog can be changed at any time by the stakeholders (Corey Ladas has a great article on using perpetual multi-vote to schedule this queue).
In the middle, are the development tasks that are required to satisfy the current MMF as well as Work In Progress (WIP) and an area for Done tasks. James left off the second two areas, but project management is about managing people as much as it is managing projects. People like to mow their lawns because once it is done there is a psychological boost to look over and see what you’ve just accomplished. In the same way, a “Done” area allows the developers to see the grass they’ve mowed during the current MMF. In an environment where the team is local, you could do away with the WIP area as the developers would have the cards at their desk, and in a situation where a software based board was being used there could be a current MMF progress bar instead of the done area.
On the right hand side, there is an Urgent box that allows for an MMF to skip the backlog and focus the developers on an emergency situation, and there is a retrospective queue. Rather than time-boxing retrospectives, this queue allows the retrospective to fit more naturally into a pull system.
While this board is my take on improving what I’ve seen out there, I have high hopes that Kaizen Conference will help us as a community move to a more standardized approach to managing projects in a lean, efficient way. (update 2014: spoiler, the conference didn’t help out at all)
