Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 06, 2009 — Enterprise Agile Planning expert

Noodling on Kanban… Part Three

Enterprise Agile Planning

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

The post Noodling on Kanban… Part Three appeared first on VersionOne Blog.

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us