On my recent trip to China, I visited several companies with vast and impressive Kanban initiatives. In this 3-part blog series, I will share my realizations about the value of Kanban and the potential to do more, even at enterprise scale.

In part 1 and  part 2 of this blog series, I discussed how organizations benefit from Kanban but leave much value on the table by not embracing its full potential. Making the changes to implement a true enterprise-wide pull system is very possible so what is getting in the way of progress?

Six Reasons Impeding Adoption of “pull”

What I see is this…

1. Not Starting with a Customer Facing Service

Most Kanban initiatives are started deep within the organization, remote from external customers. Often much or all the work delivered to the team, department, or product unit, is already committed. It is irrefutable demand.

The goal with Kanban is to flow that work more smoothly and predictably – faster would be good too. Kanban plays the role of a flow management solution within an early commitment, “push” paradigm workplace – often with highly deterministic planning and high risk individual commitments on schedule and budget. To make progress towards “pull” you need to address the irrefutable nature of demand, or switch to a customer facing service where work requests are refutable.

2. “We are just order takers!”

It can be common in large enterprises, for historical and/or political reasons, for service delivery and engineering organizations to be established like vendors who merely take and fulfill orders. This is particularly common in low trust organizations and cultures.

As Kanban is a means to improving service delivery processes, it is the delivery organization that implements it. The implementation is seen as out of the scope of the business owners, product marketing or whoever may be placing orders for work. There is a lack of collaboration across the organizational boundaries and a lack of ability to influence the selection, sequencing or scheduling of work requests. Work orders are seen as “irrefutable” and “pushed” and this is entirely incompatible with the desire to get to “pull” at enterprise scale.

The solution is to use the trust built from improved quality and improved predictability of delivery from a period of proto-kanban in order to persuade the “other side” that greater collaboration will produce mutual benefit and increased economic performance for the business as a whole.

Breaking down the culture of “order taking and fulfillment” and replacing it with a more collaborative culture of stewardship and consensus on what to select, when to start it and how quickly to process it, is vital to achieving “pull” at enterprise scale.

3. A Lack of Understanding of Business Need and Risk

With many Kanban implementations, the practitioners not only struggle to articulate who the end customer is, they often don’t know. They fail to know the intent of the request and its context. There is a lack of Einheit – alignment and unity of purpose.

To improve the depth of Kanban implementation, firms must develop a capability at business risk assessment and visualize risks throughout the workflow. Customer intent should be maintained and communicated through at least 2 levels of cascading service requests. Workers should know why someone up to 2 kanban systems away from them has sent them a request, and they should understand the business risks and opportunities inherent in those requests.

4. A Lack of Mathematical Literacy

The “pull” paradigm requires a shift to work with facts, provide accuracy, and to collect real data and analyze it. The “push” paradigm is riddled with speculation and false precision. Practitioners need to learn what to study and how to collect the right facts – facts such as lead time on work requests. Often the facts produce scary data that is at odds with the deterministic mindset of individuals who desperately want to control the world around them.

Learning to let go of the desire to control that which cannot be determined, to accept the non-deterministic nature of the work, and to embrace the dramatic spreads of variation that exist in the real data and in reality, is a true challenge for the best of people. This skill can be taught but embracing it requires both experience and true “skin in the game.”

For example, why does traditional deterministic planning using estimates actually work on large scale, so called “waterfall” projects? This can be explained with mathematics.

The size of work requests will exhibit a Gaussian distribution, equally the estimates of size of work requests will exhibit a Gaussian distribution of estimation errors. When you aggregate enough work into a big batch, the estimation errors cancel out as the Central Limit Theorem applies to the nature of the data set. Hence, traditional planning works, not because it is accurate but because the nature of the domain means that mistakes cancel each other out.

 

 

The “pull” paradigm requires a shift to work with facts, provide accuracy, and to collect real data and analyze it. The “push” paradigm is riddled with speculation and false precision.

When you reduce the batch size, there are no longer sufficient data points to cancel out errors in estimation. As a result, there is an increased drive for ever more precise and accurate methods of estimation. I have called this the “Tyranny of the Ever Decreasing Time Box” – as you reduce the batch size, it becomes less and less likely that your planning method remains “fit for purpose”. As soon as the plan is more than 10% from the actual outcome, it is unlikely that stakeholders will tolerate the deviation.

If you don’t want to go back to large batches and long timescales then you need to embrace a new approach – a probabilistic approach. The required mathematical knowledge is not large or terribly difficult but the mathematics of probability distribution functions is not taught to engineers and not covered in high school or most university curricula. Ignorance breeds fear! A little education goes a long way to enabling managers to embrace uncertainty, probability and non-deterministic methods.

5. A Lack of Skill in Negotiation or in Forming Business Agreements

Switching to “pull”, implementing deferred commitment and the kanban system replenishment meetings that go with them, requires some careful diplomacy with the customers. Switching to “pull” shifts significant risks upstream, where it belongs, but this shift represents a significant change. Risk management is shifted onto customers or business owners, who’ve been used to avoiding it and abdicating responsibility by pushing risk downstream when they ask for fixed scope, fixed budget and fixed delivery dates.

Asking business owners, product managers, strategic planners and the like to do their jobs, justify their decisions and collaborate on scheduling, sequencing, selection and discarding, requires skills that many technical managers or process coaches do not possess. Easier, then, simply never to engage and to leave customers alone – don’t ask them to change their behavior, don’t change the interface or the contract or the service delivery business model.

Again, the skills required to tackle this challenge can be taught. Ultimately customers do not want failed outcomes and they are willing to collaborate for successful outcomes, if it is presented to them in the right way and at the right time. It is often necessary to build trust as a first step. This is one reason why we embrace proto-Kanban – get good at delivering, do so with transparency, build political capital, then spend it to push through the necessary changes to enable a full pull system implementation.

6. A Lack of Confidence Planning and Scheduling at Scale

It has been clear for some time that a lack of confidence in how to plan at larger scale has impeded the changes required to get to end-to-end “pull” at enterprise scale. Partly this is a consequence of reasons 2 and 3 above. Because there is a lack of understanding of context, customer intent and business risks, especially cost of delay, there is a failure to understand how to appropriately schedule work, how to choose a class of service, and have faith that capacity will be available where and when it is needed across a cascading set of services within the network that makes up a product or business unit in an enterprise.

This lack of understanding creates a fear that results in clinging on to a “big planning up front” deterministic approach. The existing approach prevails. It’s expensive and time consuming and often produces brittle plans that break under stress from any uncertainty of emerging changes, but such plans give a sense of control and reassurance.

What has been needed is a comprehensive dependency management solution that provides reassurance that capacity on dependent services will be available when and where it is needed. A dependency management solution is needed that can provide guidance on the use of dynamic reservation systems, tooling to support risk assessment, cost of delay, urgency, and guidance on class of service selection. This would enable a probabilistic, non-deterministic paradigm, such that work can be “pulled” from external customers, at the right time, with an appropriate contractual promise.

With reassurance that dependencies will be managed and capacity on dependent services will be available when and where it is needed, it should be possible to select, sequence and schedule customer facing work appropriately. Doing so means we can discard outmoded, expensive and time-consuming deterministic, reductionist planning and the use of abusive deadline setting and other mechanisms that produce squeezes, insert stress and invoke turbulence across the entire enterprise network.

Better Results Come from Training & Tools

It should come as no surprise that to deliver solutions, especially for the list of reasons enterprises are failing to get to “pull”, requires considerable training. The reality is that to unleash the benefits of up to 8-fold productivity improvements, not to mention the economic improvements from selecting the right things at the right time, and managing risk quantitatively across entire product portfolios, managers have to change their behavior.

If we desire that managers behave differently, we need to subject them to a comprehensive management training program and we need to provide them the tools to implement what they’ve learned. Managers need the knowledge and confidence to use the techniques that enable “pull” and unleash the productivity and economic benefits available. By embedding most of the algorithms in the tooling, managers can trust the decision advice being offered and authorize commitments and schedules without having to recall all the fine-detail and intricacies of the training.

Businesses need to commit to training their managers and providing them with the right tools. Meanwhile leaders need to make it safe for the management team to experiment in the use of their new knowledge. There needs to be a culture of “failure tolerance” as managers with years or decades of old behavior to unlearn, gradually feel their way into a new way of decision making.

Managers can be trained in the risk assessment techniques, the mathematical literacy and the ability to use a dynamic reservation system, demand shaping, and capacity allocation to facilitate selection, sequencing and scheduling appropriately. The required skills are embedded in our Enterprise Services Planning (ESP) training program. These same techniques are being delivered in Enterprise Services Planning tools such as SwiftKanban ESP. The vision for ESP is simple, “ESP is MRP for professional services work.” ESP tools will bring the kind of rigor to scheduling, sequencing, selection and capacity.

LEARN MORE

Kanban Coaching Professional Masterclasses and the modular Enterprise Services Planning management training program are offered through the David J. Anderson School of Management based in Seattle, WA. Classes are also offered at locations around the world and on-premises for private corporate clients.

Enterprise Services Planning tools are available in SwiftKanban ESP from Digite