Skip to main content
Enterprise Agile Planning Image

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
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us