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 Jan 22, 2018 — Enterprise Agile Planning expert

The Push and Pull of Software Delivery: The Case for Kanban

Enterprise Agile Planning

It’s no secret that software is king in every industry today, and it’s more challenging now than ever for organizations to keep up with customer demands. Whether it’s mobile apps, the GPS system in a car or having the ability to buy products with the click of a button, customers are demanding more, quicker and better. And, what is the key to success for any business? Customer satisfaction. With disparate teams and toolchains that sometimes include dozens to hundreds of plugins, it’s no wonder that it is so challenging for businesses today to keep up. However, a tried and true method might be able to save the day – Kanban.

What’s great about Kanban is that you can adopt its principles on top of existing Agile and DevOps teams without having to re-write the script. In this article, I explain the difference between a push and pull (Kanban) system and emphasize the importance of value stream mapping to demonstrate how the two practices can help you deliver real value to your customers and win in the market.

Push vs. Pull Systems

Push System

In a push system, the upstream steps push work to the downstream steps. And typically, the focus is trying to maximize the productivity at each step in that system. So, let’s assume we have we have a customer and we have a flow of values. Our intent is to provide some value to our customer. Let’s also assume we have a really simple two-step system. Step one has a generated capacity of nine units per day, and step two has the capability to process three units per day. So, in a push system, what we’re going to be doing is producing as much as we can out of step one and pushing that over to step two. Of course, what’s going to happen is there’s going to be excess inventory, and that’s going to keep accumulating on a daily basis.

The problems with the push system are many:

  • One is that inventory is expensive to produce. Now, you may say, “We’re producing software, not inventory.” Think about inventory being something into which an investment has been made but it has not been sold, it hasn’t been released to the customer. There may not be warehouses full of pallets of machinery, but there is a source code, and there are products and services that may have been built but haven’t been released to customers yet. Inventory is expensive to produce and it’s expensive to maintain. What was ahead of its time last year or six months ago may not be as valuable now as it was then. So, the longer something sits in process, the value decreases over time.
  • Another problem with the push system is that when inventory builds up, it creates a bottleneck. When that happens, when there’s too much work in the system, the longer it takes for any single item or unit to get through the process. In other words, that’s a very long lead time on a unit-per-unit basis.
  • Finally, capacity constraints are often overlooked. With the push system, there’s an assumption that once something is pushed from one stage to the next, then everything downstream is going to be able to take care of it because we have been able to handle it at some upstream state. The capacity of downstream processes are overlooked often.

Pull System (kanban)
So, what is a pull system, or kanban? Really, it’s a visual pull system for managing the flow of the inventory. A kanban is actually derived out of Japanese manufacturing – it provides a visual signal from some downstream state to signal the upstream state that it’s okay to send some more input down the line.

Lean principles use kanban and there are a few Lean principles to keep in mind as we dig further into kanban techniques:

  • Identifying value, which means defining value through the eyes of your customer;
  • Mapping your value stream – visibility, knowing what it is that you’re really doing across your entire system, across your entire value stream;
  • Creating flow, or decreasing lead time;
  • Establishing pull which works to the capacity of the system;
  • Seeking perfection, which is just another way of saying we will continuously improve.

Let’s discuss how these Lean principles are affected and are facilitated by the kanban, why it’s important, and why this is something you should be interested in.

A kanban (lowercase k) is also a tool that’s used in Lean process management. The first step in this process is identifying values – knowing what you’re building and why you’re building it – and really defining what the conditions of satisfaction are in terms of the eyes of your customer. The second step is understanding what the value stream is.

A pull system is just the opposite of a push system in a couple of ways. First of all, the downstream steps are pulling work from the upstream steps. The other is that it seeks to optimize the flow of value through the entire system. So, it’s not looking to optimize around any one step in the system.

In a pull system, we are letting the downstream processes regulate, helping this flow to the system. For example, if a customer has taken a unit, now we know there’s capacity for another unit to come down the pipeline. This signals to step one to generate another unit and pass it on to step two. This helps regulate how things flow through the software delivery pipeline. Now, there’s no excess inventory and there’s lower lead time per unit of what we’re building. Assuming that we’re actually building things that are valuable to the customer, four of the Lean process management principles have been established, with continuous improvement obviously ongoing.

Kanban and Value Streams
Up to now, we’ve been looking at kanban, lower case k, which is a generic tool. When we talk about Kanban, uppercase K, we’re talking about a methodology that uses a kanban system. An interesting thing happens when either a Scrum team or a Kanban team working at the team level moves features through. When an organization is trying to reap the benefits of Agility on a large scale by implementing Agile teams, but the upstream process doesn’t change, the results are not pretty. When there are two different world views within the same organization, it really creates a problem. The organization sometimes will go sour on Agile because the entire philosophy of the organization as to how it approaches delivering value hasn’t changed.

Before diving into connected kanbans, and how they can remedy this issue, I want to start by looking at value streams and how they typically look in organizations before Agile is implemented. The term “value stream” is likely already in your lexicon today. But, for the purpose of this discussion, a value stream is simply the series of steps that are taken to provide value to a customer. Whether someone’s using a waterfall process or using an agile process, there are some general left to right steps where there’s a definite beginning to value creation, and then there’s ultimately delivery of that value.

So, if you take the entire value stream, which is from concept or strategic planning all the way through to delivery, and you try to divide it into planning, development, and delivery, conflicts develop because of unaligned goals and the prevailing mindset of each one of those parts of the value stream. For example, in planning, we want to be very predictable, we want to transfer the risk downstream to the development team. Then, the development teams, if they’re Agile teams, are focusing on adaptability. They’re not going to be afraid to take risks, they are going to perform small experiments, and adapt this as they go. And then, the folks from the delivery side are interested in stabilizing the build, and they want to avoid risk. These conflicting mindsets can create problems as we’re trying to look at things holistically from a single value stream perspective.

What we’re really after is a unified value stream, where planning flows into development which flows into delivery, and there’s a continuous flow of value to the customer. This is what we’re talking about when we talk about a unified value stream, we’re really referring to applying Lean management to the entire value stream from strategy all the way through delivery.

Want to learn more about how Kanban and value stream mapping can help your organization succeed? 

  • Check out this guide for the essential information you need to get started with Kanban.
  • Read more about how VersionOne Lifecycle supports Kanban.

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