We’ve been talking about room-sized visual heijunka/andon boards for large teams, but it’s also reasonable to apply the kanban idea to smaller projects. Much of the current discussion about kanban in Agile circles seems to be of a simpler variety than the enterprise-scale concepts that David and I have been so concerned with. I think it’s important to recognize that kanban is more of a principle or pattern than it is a process. It’s not at all surprising that it would take different forms, and I would completely encourage that way of thinking.
Lean Production is different from either Mass Production or Craft Production. You can apply a kanban system to a mass production system like the SDLC in order to move it in the lean direction. You can also apply a kanban system to a craft production system like Scrum in order to move it in the lean direction. From two very different starting points, you can end up at the same outcome.
A few years back, I was developing a training program on Lean and Theory of Constraints concepts for product development. We started managing the project using Scrum, but the subject matter practically begged us to evolve the process in a leaner direction.
- I wanted to change the backlog more often than the timebox allowed
- At any given moment, only one item in the backlog needs to be prioritized. Further prioritization is waste.
- I wanted a specific mechanism to limit multitasking
- I hated estimating
- I hated negotiating Sprint goals
- Sprint planning implicitly encourages people to precommit to work assignments
- The ScrumMaster role is prone to abuse and/or waste
- Burndowns reek of Management by Objective
- Preposterous terminology
The thing that I wanted most was the smoothest possible flow of pending work into deployment, and Scrum just didn’t give me that. So, I proposed a simple spreadsheet-based method:
- A daily standup
- A single (roughly) prioritized backlog
- Each person on the team is responsible for exactly two work items by the end of any standup
- Every work item is associated with a workflow, and work item status is indicated by workflow state
- A work item requires some kind of peer review and approval in order to be marked complete
- New items can be added to the backlog at any time
- There is a regular project review
- The backlog must be regularly (but minimally) re-sorted
- Status reporting is by cumulative flow only
One inspiration was a bit of folklore that programmer productivity peaks at 2 concurrent tasks. One task should be a high-priority primary task, and the other task should be a lower-priority task that you can work on when the first task is blocked. Another inspiration was the Cumulative Flow Diagram (CFD). We had been applying the CFD to Sprints as an alternative to the burndown, which makes it perfectly obvious what Scrum’s limitations are with respect to flow. Limiting multitasking and deferring the binding of people to tasks could give us at least one smooth stripe on the diagram. The more you learn to use the CFD, the more useless the burndown chart seems. For all of the Scrum talk about feedback, the CFD is simply a better indicator.
I’ve learned some things since then that enhance the original design. My notion of managing WIP was more of a CONWIP style like Arlo Belshee’s Naked Planning than the workflow style we use on the big boards. I required a defined workflow, but not the division of labor that would make internal inventory buffers necessary. The Boehm priority scheme might blow out the lead time, so I might do 1 small item + 1 larger item, or perhaps make separate service classes. I might also add a constraint indicator to the workflow.
The revised spreadsheet might look something like this: