Customer Kanban - From Customer Push to Customer Pull

This is an updated post/case study on the topic of achieving end-to-end flow with Customer Kanban. Many thanks to Patrick Steyaert for this insightful piece of content.

Enjoy!

Introduction

According to the English dictionary, flow is the action, or fact, of moving along in a steady, continuous stream. In business terms, flow is when value is created for the customer through meaningful work. Explicit in this definition of flow is that both the customer, that has a need or demand, as well as the workers, that fulfill the need or demand, are important. Implicit in this definition is the focus on short lead time. In general, this means that the time between starting something and completing it should be short. In the end-to-end flow, in a business context, it means that there should be a short time between suspecting a need and satisfying that need (or, at least, learning from the attempt to do so).

Figure 1: Lead time in an example of an end-to-end flow

Kanban systems are known to improve flow. In knowledge work, today, Kanban systems predominantly focus on the steady flow of work. Specifically, the flow of work in a team - or across a group of teams - that is/are providing a service to a customer (internal or external). For reasons that should become apparent, we will refer to these kanban systems as System Kanban. System Kanban starts from the point of committed work (i.e. a work item that is "Ready to start") and ends at a point just before delivery to the customer (typically a work item that is "Ready for Acceptance"). These two points form the boundary of System Kanban where system lead time is an expression of how fast (or slow) an item can be moved through the system.

Figure 2: System Kanban

System Kanban implements flow by allowing workers to pull work rather than having work being pushed onto them[1]. This is beneficial for the people that do the work in terms of creating a meaningful, collaborative work environment. It also has value to the customer as it results in a more reliable and attractive, fit-for-purpose, service. Pull is either implemented by means of a work-in-progress limit (WIP limit) or sometimes also by making use of explicit Kanban tokens[2].

Figure 3: System Kanban in the context of the end-to-end flow

System Kanban focuses on the flow of work within an established service. As illustrated in Figure 3, this is only a relatively small (albeit important) part of the end-to-end flow. Given that the boundaries of a pull system are (by definition) push-pull boundaries, and System Kanban is no exception to this, the implication is that while workers may be pulling work; the customer may well still be in the mindset of pushing orders (i.e. pushing requests, ideas, requirements,...).

Order pushing by the customer typically manifests itself Upstream as a (large) inventory of orders (backlog) in front of the System Kanban. The Downstream process manifests itself as work that has been delivered but not accepted by the customer. A situation that is all too common in many organizations, at the frustration of both the customer as well as the team.

Additionally, too large fluctuations in the demand may lead to temporary starvation of the System Kanban (a common phenomenon in e.g. project organizations) or a System Kanban that is not presented with the right variation of orders (e.g. variation of orders that does not match the diversity of competencies in a team). The team is starved from work or is working on low quality or low-value work while high-value work is stuck in the upstream process. This often results in higher costs (e.g. a supplier team that is starved from work) or a loss of potential gains (loss of opportunities because of the delay).

All in all, a steady flow of work can only be sustained to the extent that there is a steady flow of demand where customers pull value rather than just pushing orders. By making use of a case study we will explore Kanban systems that put the customer and customer demand at the front and center (see Figure 4 for an overview).

We will discuss Upstream Kanban as a way to create a steady flow of demand. Upstream Kanban visualizes the demand in terms of options[3] that are explored to define and select the work items that will be committed. In an Upstream Kanban process minimal options catalyze the customer collaboration that is critical to a steady flow of demand in a similar way that WIP limits catalyzes collaboration in the team.

Figure 4: Pushing the boundaries beyond System Kanban

We will also discuss the novel concept of Customer Kanban. As will be discussed in the article, Customer Kanban introduces a one stage Kanban CONWIP as a way to create customer pull and shorter and more stable customer lead times (the lead time from suspected need to satisfied requirement). As implied in Figure 4, Customer Kanban encompasses System Kanban in the same way that Customer lead time (the lead time that matters to the customer) encompasses System lead time (the lead time that matters to the team). While not the entire end-to-end flow yet, Customer Kanban does represent a next step in the evolution towards end-to-end flow.

The article will gradually build up the case demonstrating the evolutionary change that is so typical of Kanban. We will discuss how System Kanban led to success; we will recognize the limitations and the implications of these limitations on the end-to-end flow, and then discuss how we pushed the boundaries of Kanban in order to take the next step in the path to end-to-end flow. In conclusion we will give an outlook to even further (evolutionary) steps that can be taken with Discovery Kanban. We will also (briefly) discuss the importance of simulation (through what we call Okaloa Flowlab) as a way to mobilize change in the context of flow.

System Kanban Success (Downstream Kanban)

We will use the case of an IT maintenance team[4] that handles change requests and also delivers small projects across Enterprise Resource Planning (ERP), Business Intelligence (BI), Electronic Data Interchange (EDI), and Java applications. Historically the team has been coping with a persistently large backlog (+80 items, see Figure 5) and long, unpredictable lead times. End-to-end customer lead times (from "request" to "ready to deploy") have been varying between less than 1 week and 30+ weeks. Also, system lead times (from "Ready to develop" to "Ready for UAT[5]") have been long (+13 weeks) and variable.

Figure 5: Demand versus Capability

To better serve its users, the IT maintenance team has started a Kanban initiative. The initial focus of the initiative was on the Downstream/System Kanban (see Figure 6).

Figure 6: Downstream/System Kanban

While the Downstream Kanban board visualizes work from "Ready to start" to "Ready to deploy", only the flow from the "Ready for start" to "Test" is managed through a true Kanban system[6]. This so-called System Kanban creates the conditions for flow by creating boundaries in which flow can be organized, introducing constraints that enable flow; and implementing feedback loops to sustain and evolve flow. Let's revisit each of them:

• Boundaries: The team implemented an explicit commitment point for committing work and it has implemented a point where it is explicitly released from the work. This provides a boundary in which the team can self-organize to manage the flow.
• Constraints: The team has implemented governing constraints in terms of policies such as "Done" policies (stipulating when a work item can move into a "done" column). More importantly, the team has implemented an enabling constraint in the form of Work-In-Progress (WIP) limits. The WIP limits create opportunities for collaboration between team members and catalyze further improvements by stabilizing the flow enough to allow controlled experiments.
• Feedback: Next to the daily meetings, input queue replenishment, and release planning meetings, the team collected qualitative feedback on the process through retrospective meetings (as a form of reflective observation with O-O-D-A: Observe-Orient-Decide-Act). As the WIP limits were put in place, and the flow started to become more stable, quantitative data (about the flow) started to make sense and the team could start active experimentation with PDCA (Plan-Do-Check-Adjust).

The result of the System Kanban is that system lead times (from "Ready to start" to "Ready for UAT") are getting shorter and more stable and delivery rate slowly increases. The team can now start to make promises on the basis of (quasi-) stable system lead times to the business users. Collaboration within the team is increasing and the team is starting to discuss how they can reduce knowledge bottlenecks in the team. A stable flow now emerges that can be further optimized by learning from small experiments (e.g. pair working to further reduce bottlenecks).

Limits to Success

Due to the System Kanban initiative, the IT team is able to communicate positive results to their users as their efforts to reduce work in progress (WIP) have led to shorter, more stable system lead times and higher delivery rates. The business users (the "Customers" of the team) recognize the improvements that have been made. Still, they feel that more improvement is needed.

For business users, the end-to-end customer lead time feels like a much more important metric than the system lead time. After all, for them, the clock starts ticking when they make the request, not when IT is ready to start working on their request. At least they want to get some insight on when they can expect that IT will start working on their request. They feel that IT could be more than an order taker and be more proactive in working with them on identifying what is important.

The manager of the team also has his thoughts about the situation. He feels that more collaboration with the business is required. He feels that the goal should not just be to deliver better against the requests that have been submitted but that they should collaborate with the business users to increase the business value of the requests. They need to better understand the problems that business users are trying to solve and be more innovative in providing solutions.

The team itself feels that while they may still (substantially) improve their capability to deliver, the low hanging fruit in the development flow has been picked and most of the turbulence and wait times now come from the incoming work (from the users) and outgoing work (back to the users). The time has come to start looking at the end-to-end flow from request to delivery.

A Deeper/Wider look (Upstream Kanban)

Next, to the System Kanban/Downstream flow, the team had also started implementing an Upstream Kanban flow. The purpose of the Upstream Kanban was to manage the stream of incoming requests before being able to commit the work for execution downstream. The Upstream Kanban was modeled according to the change request (CR) and project life-cycle that was agreed with the change advisory board (CAB).

In this lifecycle, it is required that for (smaller) change requests, a scorecard is filled in to assess the priority of the CR. Possibly a clarification from the business user is required afterward when the CR is not clear. Projects require a so-called, blueprint to agree on the business requirements.

Figure 7: Upstream + Downstream Kanban Flow

The board that the team uses visualizes the end-to-end flow starting from the capture of requests and ending in work items that are ready to be deployed (see Figure 7). The flow consists of an Upstream + Downstream Kanban process with an inventory of "options" - i.e. work items that are waiting to be committed - in between.

The commitment point is right after this inventory. On the board, system lead time - the stable part of the lead time - only represents a small part of the end-to-end customer lead time that the business users are interested in. The only reliable promise that can be made, however, is the promise that is based on system lead time. This is due to two reasons:

• 1) Looking downstream, the fact that the "Ready for UAT" and "UAT" columns on the board do not have a WIP limit means that there is no control over the amount of time that is spent in these workflow steps. Some business users respond rapidly when an item is ready for them to accept, and some business users never seem ready to accept work items.
• 2) Looking upstream, the team cannot make any reliable lead time promises earlier than the commitment point because of the large inventory of "options" right before the commitment point.

a.) Some items are rushed through the Upstream Kanban inventory. Often, these are small, but highly visible projects that are ushered through the Upstream process with urgency. Sometimes projects like these need to be expedited despite the fact that they were requested already quite a while ago. For the team, they appear to suddenly become urgent without any warning. The business users, on the other hand, do not understand that the urgency was not clear to the IT team.

b.) Many other items, such as low priority changes, get stuck in the inventory. Some of them even die there.

The result is a highly variable end-to-end customer lead time as shown in the picture below (x-axis = customer lead time in weeks; y-axis = frequency of occurrence). Note that reality is even worse because the graph only shows the customer lead times of items that have actually been delivered (for items that are not delivered yet, lead times cannot be determined).

Figure 8: Distribution of Customer Lead Times

From the above analysis, it is clear that there is room for improvement. While the team refers to their board as the "Kanban board", except for the area from "Ready to start" to "Test" (System Kanban), the rest of the board is visualization without any real underlying Kanban system (also sometimes referred to as "proto-kanban"). The visualization does, however, surface the problems in the end-to-end flow.

On the upstream side of the System Kanban, demand for work (aka "Options") is pushed into the inventory in front of the commitment point from which it is pulled into the input queue of the team. At the other end, on the downstream side, of the System Kanban, work is pushed back to the customer for acceptance. In the next two sections, we will explore how the scope of the Kanban system can be enlarged to cover a broader section of the end-to-end flow by revisiting the Upstream Kanban and introducing a Customer Kanban.

Pushing the Boundaries

In order to get a more reliable Customer lead time and better collaboration with the customer, the team in our case study needed to push the upstream push-pull boundary further upstream and the downstream boundary further downstream. First of all, the team needed to revisit their Upstream Kanban. The purpose of the Upstream Kanban flow is to evaluate the different options and prepare work items so that they are ready to be committed. The objective is that work items can be executed by the team without undue delays.

The System Kanban board and the cumulative flow diagram (CFD, see Figure 9) indicated to the team that they were not entirely succeeding in properly preparing the work items in the upstream process. The team noticed the large WIP in the "Analysis ongoing" column after the "Ready to start" column. In the CFD it can be noticed that the large WIP in "Analysis ongoing" is not accidental.

It persists as a large area in the CFD (the light-blue area at the top of the CFD). Further investigation revealed that items tended to get blocked because the work item was not properly prepared. Typically, it was not entirely clear what, to be done, further clarification of the business user was required, and/or the item needed further analysis. Other problems such as the fact that sometimes conflicting viewpoints between users only became apparent once the work had already started, provided a strong indication that the upstream process needed to be revisited.

Figure 9: Cumulative Flow Diagram (CFD) for the downstream flow

The team decided that both CRs and (small) projects needed to go through a similar Upstream Kanban process. They also found it important to make a clear distinction in the upstream process between synthesis and analysis (see Figure 10). The first step - synthesis - seeks to find consensus between the different users and their fragmented and sometimes conflicting demand by building a shared coherent concept.

Only after that, the concept could be further detailed, analyzed, and, if needed, broken down into work items that can be allocated to the team for execution. The team felt that a proper synthesis was essential to avoid misunderstandings later on in the process. See Figure 12 for how the upstream board was redesigned.

Figure 10: Upstream Kanban process

The team also recognized that the upstream process is essentially a triage process: not all requests that are captured will be realized in the end. Each request needs to go through several steps of selection (see also Figure 11) and the quality of the selection process is critical. In the past, the selection was mainly based on "readiness": once a request, like a small, low priority change, was ready for the next step it actually got selected for that next step.

Because these small requests didn't require a lot of synthesis nor analysis, they tended to flood the inventory before the commitment point (they almost immediately moved from "Idea/Request" to "Ready to commit" on the upstream Kanban board). Higher value projects that did require more elaborate upstream work (synthesis and/or analysis), on the other hand, got stuck until suddenly becoming urgent.

Figure 11: Option selection in the upstream process

Rather than selection based on "readiness" the team needed to have a way of making selections that would ensure a proper diversity of options at each step in the process. Specifically, it needed to ensure that at each step sufficient attention was given to projects and that not too many small requests got selected.

The team decided on a solution where, at all times, and for both types of requests (CRs and projects), a minimum inventory was guaranteed at each step in the triage process. This way they would always have the option to advance a project to the next step. On the other hand, if the minimum inventory for small requests was fulfilled they stopped adding more, thereby preventing flooding of the inventory.

On the upstream Kanban board, the concept of "minimum inventory" was realized through minimum options limits. Rather than WIP limits that impose a maximum limit on the work in progress, the minimum option limits impose a minimum on the number of options that are on the board. The minimum option limits work like an order point. It requires the attention of the team and the business users when a limit is not reached.

Once the limit is reached, the attention can be directed elsewhere again (e.g. back to delivery downstream for the team members, and the day-to-day business for the business users). Proper policies can guide the team and the business users on which priority should be given when minimum limits are not reached.

Figure 12: Upstream Kanban with minimum options limits

Upstream Kanban alone is not sufficient. While the Upstream Kanban flow allows to make sure that the team is presented with sufficient options of the right variety at all times, it does not prevent the customer (or business user in the case study) from pushing orders onto the team.

Often, this takes the form of business users that issue requests and use all their power to get the work on those requests started, but are not available to help the team when their input is needed. Often, this manifests when the work is made ready for acceptance by the business users but the business users are not ready to accept.

Figure 13: Customer Kanban

The team needed a creative solution to deal with this situation. The idea of a Customer Kanban emerged. As shown in Figure 13 Customer Kanban introduces a one-stage kanban CONWIP (CONstant WIP) limit on top of the System Kanban WIP limits and the Upstream Kanban minimum options limits. In practice, Customers receive a number of Customer Kanban tokens[7].

Each customer can at all times issue new requests (in the "Idea/Request" column), but is only allowed to pull a new request for further processing (preparation of the work) when a Customer Kanban token is available. The Customer Kanban token is then attached to the request (when it is pulled). The token is recuperated when the customer accepts the result of the work that was done to fulfill the request (i.e. when the item is "Ready to deliver"). The overall idea is that the customer should not push new orders into the system when older orders are still being processed or waiting for acceptance.

While System Kanban WIP limits are essential to short and stable system lead times (the lead time that is important to the team), the Customer Kanban CONWIP limit is essential to short and stable customer lead time (the time between suspected need and satisfied requirement, and the lead time that is important to the customer). Business users and the team need to collaborate to remain within the constraint of the CONWIP limit. The CONWIP limit is essential to achieve customer pull on top of the worker pull that is enabled by WIP limits.

All in all, Upstream and Customer Kanban push the boundaries of Kanban. They introduce two new constraints/feedback signals. The first is a minimal options limit and the second is a CONWIP limit. While, in practice, they may be introduced separately, both need to be present to create a steady flow of demand and customer pull.

While the CONWIP limit has a more global character (ensuring that the total number of requests in progress are kept in check), the minimal options limit has a more local character (ensuring sufficient options at each step in the Upstream Kanban flow). Because they are so connected, often we use Customer Kanban as the umbrella term for both Customer and Upstream Kanban at the same time.

To end this section, note that much more can be said about Customer and Upstream Kanban. Quite a few questions are left open in the above explanation: how to set the CONWIP limit; how do you allocate the CONWIP limit over different types of customers; how to determine minimum options limits; do you need maximal options limits on top of the minimum options limits (I suggest you don't, especially if a CONWIP is already in place); which feedback loops and cadences need to be put in place; etc. This is left to further publications and presentations.

Conclusion

System Kanban focuses on the flow of work, and collaboration in a team that is delivering a service. It implements pull through WIP limits. However, as with any pull system, it has a (push-pull) boundary. In the case study we saw that this push-pull boundary formed the boundary between the order taking team and their order pushing customer(s).

In a fast-moving world, however, it is not sufficient to just serve a customer; nor is it sufficient for a customer to just push work orders to an order-taking team (even if that team is "pulling" work). More than order taking, it requires teams of (knowledge) workers to intimately collaborate with the customers that they are serving; more than order pushing, it requires customers to closely collaborate with the teams of which they require a service.

Figure 14: Customer versus System Kanban

Customer and Upstream Kanban cover a larger part of the end-to-end flow than System Kanban does. Upstream Kanban introduces the notion of minimal options as a way to create a steady flow of demand. Customer Kanban introduces a one stage Kanban CONWIP as a way to create customer pull.

Together they foster the collaboration between teams and their customers resulting in shorter and more stable customer lead times (the lead time that the customer is interested in) and a more stable overall flow. Figure 14 summarizes how Customer Kanban (including Upstream Kanban) compares to System Kanban.

While not entirely there yet, Customer and Upstream Kanban are a stepping stone to the ultimate end-to-end flow. The reader might be aware of an even more encompassing flow that takes learning from the customer feedback into account (as depicted in the end-to-end flow in Figure 1).

This flow is addressed by an even larger set of Kanban systems that is called Discovery Kanban. Additionally, to flow of demand and customer pull with Upstream and Customer Kanban, Discovery Kanban includes Kanban systems for innovation and change. Particularly it includes Kanban systems that support learning through reflective observation and active experimentation.

This brings us to our last point. While it was not addressed in this article, reflective observation and active experimentation were an essential part of the change in the case study. The concept of flow, as discussed in this article, is not an easy concept to master for people that have not experienced it. Rational explanations of flow only go so far. Often, they are not sufficient to mobilize a team or organization into action. Flow needs to be experienced.

This is a bootstrap problem: in order to mobilize a team, flow must be experienced; in order to be able to experience flow, the team must be mobilized. In the case that was discussed (and many other cases), we made use of extensive flow simulation - in what we call a flow lab - to solve this bootstrap problem. In the flow lab, teams are immersed in flow thinking, reflective observation, and active experimentation through simulations that cover team flow (at the level of System Kanban) as well as end-to-end flow (at the level of Customer and Upstream Kanban).

Other simulations may include cross-team flows (dependencies between teams) and weaving experiments through the flow (Discovery Kanban). More information on the Okaloa Flowlab and/or Discovery Kanban in addition to Upstream and Customer Kanban, can be obtained through the author (patrick.steyaert@okaloa.com) or through the Okaloa website (www.okaloa.com).

Footnotes

[1] System Kanban also implements flow through a cadence of planning what the team can work on and reviewing what is ready to be delivered. These cadences and other feedback loops such as regular (operations) review meetings help to sustain and evolve flow. The overall purpose is to create a customer service that is fit for purpose through collaborative work and improvement.

[2] Figure 2 shows both at the same time, as both are essentially equivalent, albeit with a different emphasis. WIP limits emphasize the importance of constraints to enable the collaboration that is necessary for a steady flow. In other words, the team needs to work together to keep WIP low and lead times short and predictable (and flow stable). Explicit Kanban tokens emphasize the importance of feedback signals. The Kanban token is a signal that new work can be started, or that no new work can be started. It signals that team members need to work together to finish work before starting new work.

[3] Technically, an option is the right to do something but not the obligation. In plain English, it is a thing that is, or maybe chosen. The reader is free to interpret the term "option" in either sense.

[4] The case study is composed based on the experience of different teams from different organizations (including an IT maintenance team but also teams from software product organizations). The case study material is representative for these different teams.

[5] User Acceptance Testing

[6] On the Kanban board we clearly see a distinction between the columns from "Ready to start" to "Test" and the columns from "Ready for UAT" and "Ready to deploy". While the former columns have a WIP limit, the latter do not (hence the ∞ sign on top of these latter columns).

[7] In the case, the Customer Kanban tokens were actually assigned to groups of users (e.g. HR, Production, Supply-chain,...). The repartition of the tokens was based on an analysis of the historical demand.