Noodling on Kanban… Part Three

Earlier today we noodled on the secret sauce… maybe even THE most important value add… of implementing a Kanban system. Kanban gives us a very visual way of identifying and elevating the constraints in our system. The ONLY way to really get a team to go faster is to increase capacity at the constrained steps in the development process. Building inventory in other parts of the system leads to waste and re-work.

If you get nothing else out of this little series… that is your take-away.

For today… we are going to talk about going iterationless. So far we haven’t really talked about the iteration but most Kanban teams have figured out how to live without them. We’ll talk a bit about how to measure progress without being able to measure velocity at iteration boundaries. Without iterations… without velocity… we need another measure of team throughput…. and that is where cycle time comes in.

Going Iterationless

While agile is fundamentally designed to accommodate change, the idea of an iteration implies some degree of certainty about what it is you plan to build, even if that certainty is only two to four weeks into the future. In some environments customers can’t wait until the iteration boundary to introduce changes. In some environments requirements cannot be neatly fit into a consistently sized window of time.

This understanding has led some teams to abandon the iteration all together and now consider planning at iteration boundaries to be a wasteful activity. These teams have opted toward working directly from the prioritized product backlog and only bringing new work to the team when the work in process limits allow a new feature to begin. Agile introduced the idea of small batch sizes by limiting the amount of work that could be pulled into the iteration. Kanban teams take this approach to the extreme and reduce the batch size at any one time to that of a single user story.

Teams that implement this approach have ad-hoc planning meetings when the team is ready for new work. They conduct periodic operational reviews to asses team performance, communicate with management, and evaluate the overall health of the system. Teams choose appropriate boundaries for traditional retrospectives but they are not necessarily tied to the operational review or any predetermined time-box.

Velocity versus Cycle Time

Agile teams become predictable by stabilizing the size of the product backlog and establishing a consistent velocity over time. We can assess the delivery date of a fixed scope product backlog by dividing its total size by the velocity of the team. Likewise, we can use velocity to make trade-off decisions when trying to manage to a fixed delivery date release. Without the iteration, there is no longer a fixed period of time from which the team can measure team velocity.

Kanban teams replace velocity with the notion of cycle time. Cycle time measures the total elapsed time from when the feature was started until it is marked complete and accepted by the customer. Cycle time can be useful for predicting delivery and making both short-term and long-term customer committments. Becuase features are independent and not allocated to a fixed scope sprint, the team can always work on the highest priorities of the business.

Many Kanban teams will track the cycle times of similarly sized stories, making a distinction between the cycle time of a one-point story versus the cycle time of the other possible story point values. If the team becomes proficient at breaking down user stories into similarly sized increments of work, estimation is no longer even necessary, and cycle time becomes the only metric necessary to measure the delivery capability of the team.

What’s Next

The next and final post in this series will talk a little about why you might want to choose Kanban and a bit about Corey Ladas‘ work on Scrumban… an interesting hybrid of Scrum and Kanban for teams in transition. We’ll also hit a little on some work I am doing with a couple clients to introducing Kanban boards for project/portfolio management.