Continuous Delivery and Kanban: The Perfect Marriage

The evolution of project management for software development has reached a new era. Some of the solutions, such as Scrum and Kanban, have increased productivity and product quality significantly. In this post we describe the challenges of using Scrum with continuous delivery and how we have solved that at IT Glue™ by implementing the Kanban methodology to keep producing awesome new features flawlessly.

The Scrum methodology

Since its inception in 1995, Scrum has become the most applied framework for agile software development. Scrum’s short iterations became popular due to its relative rapid delivery of software. Instead of months or years, software is delivered at the end of every sprint (typically 1 to 4 weeks). But in recent years software development organizations have started moving away from end of sprint delivery in favor of continuous delivery. Rather than batching an entire sprints work, reviewing and delivering it, teams prefer to ship features to production as soon as they are complete. This decreases time to feedback and value to users.

The continuous delivery model is incongruent with the Scrum methodology. Scrum includes a “Sprint Demo” meeting, where product owners provide final feedback and approval before “User Stories” are approved and deployed. This demo becomes meaningless if the feature has already shipped to production. A potential solution is to have product owners approve individual features as they are completed and ready to be deployed, but then why do we need Sprints at all?

At IT Glue we propose that Sprints and Sprint demos are not needed. Instead our engineering team follows the Kanban methodology with feature demos and daily stand ups. Work in the form of stories, bugs or tasks enter our Kanban board, flow through our system and out to production continuously. Kanban works seamlessly with continuous delivery.

Product owners still sign off on features during short feature demo meetings, where the principal engineer of a feature will demonstrate the implementation for the product team. At IT Glue we decided not to waste time with sprint planning meetings, instead our engineers spend that time doing what they love; writing code.

Work in Kanban starts with a prioritized backlog, it is then pulled through the pipeline until it reaches production. When one of our engineers is ready to work on an item they pull from the done section of the preceding step into the work section of their column. The separation between work and done within each column allows us to identify bottlenecks at any given column, if items are piling up in done, the following column cannot keep up with the throughput of the rest of the pipeline. This pull model is very important to the methodology, it ensures that the person receiving work is ready to work on it instead of work being pushed onto a queue, where it could sit untouched for a long time.

Limit WIP FTW

A core principal of Kanban is the idea that Work In Progress (WIP) should be constrained.This is represented by a WIP limit at the top of each of the columns, this number is the maximum number of items allowed in the column. If any column reaches its WIP limit no new work is allowed to enter the system. Instead, we look to add resources to the constrained column to ensure system flow is maintained.

Key metrics for success

Kanban is all about flow. The objective is to get items through the system and into the hands of users as soon as possible. Two useful metrics to track flow are cycle time and lead time. Cycle time is the total amount of time from the start of work on an item until it is complete (which in our case means it is in production). Lead time is the total amount of time from the time the request is received to the time it is complete (including time sitting in the backlog). If the standard deviation of these metrics is low they can also be a powerful leading indicator of delivery time. These are metrics we are constantly working to improve at IT Glue.

As with all methodologies take that which applies and discard the rest, focus on continuous improvement through feedback loops and success will follow.

Recommended reading for learning more about Kanban:

• Implementing Lean Software Development, Mary and Tom Poppendieck, Addison-Wesley Professional; 1 edition (Sept. 7 2006)
• Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson, Blue Hole Press, (April 7 2010)
• Lean from the Trenches, Henrik Kniberg, Pragmatic Programmers, LLC.; 1 edition (Dec 24 2011)