The topic of Kanban and scale comes up often in my professional discussions. It has been part of my consulting practice for many years. I’ve been able to give insights and advice that largely matched what people saw and needed in the real world. This has led to many requests for me to present them together as a system. I’ve been able to give a brief summary of such a system within my immediate circle of colleagues and clients. This text below presents this brief summary, breaking down the concept of scale, identifying key situations, and giving practical advice for each. I’m sorry it will be curt, shortening to theses instead of full sentences at times. It is an abridged version of the fuller, more explanatory, and better illustrated text I’m still working on.
Why Is This Important?
In the last 10-20 years, many companies in creative, intellectual industries have applied Kanban as their management and improvement method. This has been a global phenomenon, including companies in many industries and countries. Kanban helped these companies achieve greater productivity, teamwork, service or project delivery performance, customer satisfaction, business agility and resilience. Collectively, the companies also discovered deeper insights into the phenomenon of knowledge work and unlocked some of its mysteries. It takes awareness of several Kanban stories from multiple companies to see it that way, and many in the international Kanban expert community have such exposure. Some of the insights are about scale.
Note that the insights discovered with the help of Kanban apply to all companies whether they use Kanban or not. Having practical guidance on Kanban and scale means good news for improvement in general. It is effectively a general improvement blueprint enabling its holder to anticipate and deal with challenges arising from scale.
What Do We Mean By Scale?
The word “scale” generally refers to size. Real-world companies come in all shapes and sizes. This cliché expression reveals scale is more than one number representing size. The intuitive notion of “shape” refers to the several possible ways to measure the size. The size of a company or an organization could mean the number of employees, teams, work locations, products, services, customers, transactions, revenue, budget and so on.
Scale reveals itself in two primary modes. In the first mode, Kanban application evolves from a smaller footprint to a larger footprint: greater number of employees, teams, departments, products, services, projects, revenue, budget, percentage of the organization by any of those measures. In the second mode, two companies already have two improvement footprints. The companies’ activities and outcomes (and Kanban practices, if the organizations apply the Kanban method explicitly) are different. For the purposes of this article, we’re interested in the differences arising and owing to the different scale of the two footprints.
The presence of multiple ways to measure size, or the intuitive “shape” concept, lead us to an important step. We can introduce dimensions of scale as a logical construct to break down the scaling problem. In each dimension, scale affects differently how you understand, manage, sustain, and improve flow. Each dimension presents its own set of challenges, which we can anticipate and respond with proven practices. If you know the “geometry” of your company’s footprint, how it is expanding (“scaling”) in your company, or how it differs from a reference company’s footprint, you are ready for the challenges.
Speaking of Scale Isn't Independent of Scale!
The expectations about the scale of this article are important. The medium and the message aren’t independent. I need to cover five key problem areas. Each area has several key patterns, examples, stories and recommendations. If I could unpack each of these 20 or 30 boxes in an hour of consultation, or in a training class module of similar duration, or with a proportional amount of text, 1000 words or more, that would stretch this article’s size beyond the attention limit of most readers. Therefore, it is at this scale, key points on each of the five dimensions, that I’ll have to draw straight lines around the fractal boundary of this article. I believe this will be a useful mindmap to a patient reader. But it may feel not explanatory enough, despite being a longread.
The Scaling Dimensions
The following system of five dimensions is a distillation of my experience with improvement of flow in different companies and at different scales. A good amount of it coincides with the experience of other consultants and well-known Kanban method guidance. The Width, Height and Depth have always been mentioned in the foundational manager-level standardized Kanban training. Width and Height have been intuitively understood thanks to their geometric analogies. I do want to take the opportunity to expand and recategorize the known experience and available guidance in ways I believe are important for Kanban method users – leaders, managers and their improvement consultants and coaches.
The short list:
· Width (Breadth may be a better word for reasons I’ll show later) – the Kanban footprint expands from the relatively narrow section to a broader section and potentially the whole end-to-end workflow or value stream
· Height – the footprint expands across the hierarchy of work items. It deals with decomposition of work. For example, projects break down into constituent work items, larger work items into batches of smaller ones, software epics into stories, and so on
· Depth – from one service where Kanban applied initially to multiple services, potentially dependent on or impacting each other as a network
· Scale-Free Opportunities – Kanban handles some scaling situations with surprising ease, essentially independent of scale. It is important to recognize such situations and not create scaling problems where we don’t have any
· Knowledge – the social problem of propagating relevant knowledge from one or few expert heads to the broader community of practice across the company. This may be the hardest of the five dimensions. Sociology isn’t scale-free
As an illustration of this shortlist, I'm including the photo of a flipchart I drew while advising a client on this topic several years ago.
The Breadth/Width Dimension
This dimension represents the Kanban expansion along the workflow. Kanban starts with one or few teams responsible for part of the workflow. It may spread downstream, potentially reaching the customer delivery point. It may also spread upstream, potentially reaching the commitment point and even further decision points in Upstream Kanban.
A short story from one of my clients gives a good feel for this dimension. Lisa was a Scrum Master of a software team maintaining API in an e-commerce enterprise. The teamwork was great, lots of done “user stories” every two-week sprint. And “done” meant, mind you, deployed to production via a continuous deployment pipeline. The “done” column of the team’s board often overflowed with cards.
Lisa discovered eventually that the primary consumer of her team’s “done” work was the mobile app development team that built features using the API. They started building the features not immediately after Lisa’s team “done” them, but often after several months of delay. Lisa also discovered that output of the platform team fed into her team in a similar fashion.
Lisa’s improvement footprint was about to begin its expansion to cover the entire development workflow, to which three teams contributed.
This pattern has a name in the Kanban method: the Aggregated Team Kanban. A proven effective approach to situations like Lisa’s is a key part of the Kanban method, it’s STATIK (the Systems Thinking Approach to Introducing Kanban). It’s a good idea to reapply STATIK when significant new information about the system is discovered. We use STATIK to redesign the Kanban system anew, in a broader context. Instead of the previous design around a team, we design it around a multi-team service. The new system also changes the focus from facilitating teamwork to customer commitment and delivery, customer needs and expectations. This is known as Kanban’s Service-Orientation Agenda. All the terms in this paragraph have been key parts of Kanban for many years, discovered and documented extensively before 2014, polished by many practical applications over the years, featured in many Kanban conference presentations, and taught in many foundational classes.
What are the key patterns and bits of advice for this dimension?
I’ll start by admitting my mistake. When I wrote the first draft, the first paragraph I wrote was about psychological problems, such as the change of perspective involved in the Service-orientation agenda may negatively affect the self-esteem of several people involved and trigger their emotional resistance. While this is technically true, it is not specific enough. All organizational changes may hook people’s hidden identities and trigger emotional resistance.
I wrote some good text and then made another, smaller mistake. I wrote about tools, specifically how team-centric tools in Lisa’s company didn’t give her, her colleagues, and customers an end-to-end view. True, tools as consolidation practices (a Kanban Maturity Model term), solidifying the practices of a process improved in the previous improvement initiative, can be impediments when we pursue further improvement and need to change the status quo. Scaling in the first meaning, expanding the footprint, means, by definition, changing the status quo in the area not covered by the pre-existing footprint. So, resistance from consolidation of prior improvements may be common to all scaling dimensions and not specific to any.
What pattern or advice is specific or even unique to scale and this particular dimension of it?
First, reaching the commitment point as the footprint spreads in the upstream direction (for non-Kanban-fluent readers, this is to say we debug the management of that section of the process). Then we have to deal with a group of problems we happily avoided up to this point. Previously, we could treat our improvement initiative as a simpler, constrained problem: work comes from a “backlog”, then it flows through a team or multiple teams in our sphere of influence, then it exits this sphere of influence before it reaches the customer, improve process capability and outcomes between these endpoints. But now, we have to understand how this backlog arises in the first place and improve how we make decisions in our business, such as making various promises to customers. As most services have multiple customers, we’re likely to encounter a conflict of customers and their proxies (“stakeholders”) over the finite service capacity.
(The reward for attempting to solve this bigger problem is one of the most lopsided asymmetric payoffs available to those applying Kanban. It’s satisfying customers by criteria that matter the most to them, be it time, quality, selection of product components and so on. It is much more than a better process, it’s happier customers and better business.)
Turning the conflict of customers or stakeholders A, B, and C over the finite capacity of Service XYZ into cooperation; collaborating across teams/departments of X, Y, and Z in the Service XYZ; both require a step up in leadership. It takes an individual sacrifice for the common good, taking a small local loss for a larger global gain. These are higher maturity leadership traits than simply fighting for the Market Segment B or the Department of X. The Kanban Maturity Model documents these leadership traits at the Leadership Maturity Level 3. Therefore, scaling in the Breadth/Width dimension (upstream) is likely to increase demand on ML3 leaders within the company. For every charismatic ML5-6 leader making a compelling business magazine cover story, the same company needs an army of ML3 leaders. I would not take their availability for granted.
Second, as the footprint spreads in the downstream direction, it may reach the customer delivery point. This will, too, open a group of previously hidden problems. It may challenge the existing economics of delivery batch sizes and even what “done” means and what constitutes customer value. In the first two decades of the 21st century, many software companies decreased their delivery batch sizes and increased delivery frequency, often with continuous delivery pipelines. They soon began to realize that the customer value is realized not from an automated push to production, but from the users’ uptake of the new functionality, resulting in the increased productivity or enjoyment or what else was their purpose for using the software. Achieving this uptake may require training or education of end users, activities outside of the current process definition. I encountered this pattern first in 2003. Fifteen years later, it received the following compact, humourous illustration in my actual exchange with a client:
Me: “Do you still have your Change Advisory Board meetings regularly?”
Client: “No, we used to have CAB meetings weekly, but eliminated them after implementing continuous delivery.”
Me: “Since you have continuous delivery, do you use feature toggles?”
Client: “Yes, we do.”
Me: “When and how do you decide when to turn each feature toggle on?”
Client: “We have a new weekly meeting for that.”
Third, the Breadth/Width dimension is where time in process ticks. As we include a longer workflow, more activities in our improvement footprint, that changes how we measure, understand, and manage time in our process.
There are many reasons and ways for measuring time in process, from and to various points. I would like to highlight two of them that are most broadly applicable.
One good universal reason to measure time in process is because it is a customer fitness criterion. Whether customers care for duration, predictability, or timeliness, it’s virtually universal that they care about time one way or another. So, we need to find a pair of points in the process, “from”, where customers perceive a promise is given to them, and “to”, where their needs are met with a delivery. Some customers care for commitment to doing, others for commitment to start; whichever it is, that’s the “from” point. Kanban being more than a visualization tool, it has a practice formulated shortly as “limit WIP.” In a very generous and forgiving interpretation of this practice, if we care to satisfy time over some process span as a fitness criterion, we must acknowledge the inventory (work in process, WIP) over the same span is a leading indicator, and we must keep this inventory under control. Kanban dispenses with wishful thinking that we can ignore the inventory and satisfy the time criterion in the same process span.
Another good reason to measure time is informing important decisions. Decisions’ consequences or outcomes are often not immediate, there’s some time lag, known in the Kanban terminology as the lead time. One thing precedes – leads – another by this much. One classic example involves a fixed-date work item: we want to know when to start it. In another example, we want to know when to begin exploring a rough idea so that we have real options before we need to go to market with some embodiment of that idea. We want to know how much this lag is to make better decisions, and better includes the optimal timing of decisions. Similarly, if this time interval matters, so does the inventory (WIP).
In both cases, we have a de facto Kanban system in the same process span where the important times in process are measured. The business objectives – satisfying customers by their fitness criteria or making better decisions – provide motivation for introducing a Kanban system or scaling it in Breadth/Width dimension. An effective enough Kanban system of this scale becomes an operational solution answering to the business objective.
There is an important what-if: what if some or all of the important “from” and “to” points are outside of our current improvement footprint? This means we don’t have managerial capabilities yet to satisfy important business objectives. (This statement assumes business objectives involve satisfying the company’s customers, which is often true.) It is an important skill for improvement coaches (and Kanban teaches them that effectively) to recognize such situations. Scaling Kanban in the Breadth/Width dimension would then be of high priority. However, if this is an overreach, infeasible in the company’s current political climate, the coaches should advise and pursue improvements elsewhere.
Collaborating along the longer workflow, moving upstream catching the commitment point, turning conflict into cooperation, moving downstream catching the delivery point, potentially rediscovering the customer purpose, and my favourite topics: time, time, time. This was a brief summary of the Breadth/Width dimension.
The Height Dimension
The Height dimension represents the hierarchical nature of value represented by the work items. Work items delivered to customers (and sometimes whole markets) may be large and comprise multiple smaller work items. Several hierarchical levels are possible.
Kanban systems designs for such situations typically include a work item type for each level of hierarchy and identify parent-child relationships between them (a “parent” work item breaks down into several “children”). The commitment point for the parent work item type occurs typically before the decomposition point, although some information about the parent work item composition may be available prior to the commitment, for example a rough estimate of the number of child work items. Downstream of the decomposition point there is a commitment point for the child work item type. It is often understood as commitment to start, while commitment to do is assumed for child work items as a consequence of committing to the parent, but there may be exceptions. If there are more than two levels in the hierarchy, there is another decomposition point, the commitment point for “grandchildren” and so on. Recombination points where child work items merge back into one parent may exist further downstream, before the customer delivery point.
Users of such hierarchical Kanban systems sometimes use literary analogies in naming the work item types, with words such as story, epic and saga. They try to communicate intuitively not only the relative size of work items of different levels, but also the decomposition: an epic may consist of several stories and a saga may consist of several epics. Such analogies are not essential; I’ve seen fairly “technical” work item type names in Kanban system hierarchies that were perfectly acceptable for as long as everyone understood the parent-child connection.
Users of hierarchical systems often create hierarchies of Kanban boards as well. It is usually difficult to visualize more than two levels of hierarchy on one board effectively. “One level and a half” is an effective approach: The highest-level board has the full visualization of work items of the parent type, all that we care to visualize about them, the decomposition, and only the most essential information about child work items. The more detailed information about child work items lives in separate, lower-level board or boards, which may include, if applicable, further decomposition, essential information about “grandchildren” and so on.
My first advice on scaling in Height dimension: more effective system designs exploit opportunities not to represent each parent and child as tickets – cards that are supposed to flow, but instead mostly just occupy space on a board. I observed many times that “everything is a card” (of some type) approach leads to overly complicated designs. Remember, “overly complicated” in the language of improvement initiatives means less likely to stick.
Here is a short catalog of patterns on how to simplify hierarchical designs, roughly from bottom up.
Tasks – a relatively small work item consists of several tasks. It is possible to represent this as another level of hierarchy and a separate board where cards representing tasks flow from “to do” to “doing” to “done.” When all tasks are done, the work item is considered done or ready for the next workflow activity. A simpler solution could be to create checklists as part of the work item type’s definition of done, one for each workflow activity, and visualize them as explicit policies.
Child work items hiding workflow activities. Many people in situations similar to Lisa’s (from the Breadth/Width dimension section of this article) made this mistake. (I’m leaning on Lisa’s story here just to avoid telling another story with a different set of details, but exactly the same pattern of flow.) They created a customer-recognizable work item type, representing a fully enabled mobile app feature. Then they “decomposed” each work item into three team-level work items. Then they realized the team-level work items cannot be done in just any order, there is a web of “dependencies” among them that must be tracked in the backlog. An attentive reader would realize at this point that a much simpler solution was to visualize the team-level work not as work items—cards, but as workflow activities of the customer-recognizable work item type, in other words, Kanban board columns.
Another often unnecessary work item is “release.” Let’s say the frequency of releases of our technological product is quarterly. There is no reason for one big ticket to sit on a Kanban board predictably for three months and then move to “done.” You can visualize product releases using input and output buffers with the explicit replenishment and emptying policies.
A project running for several months also doesn’t necessarily need a ticket sitting in “doing” all that time. You can visualize it as a swimlane on a Kanban board, showing what part of the available capacity is dedicated to this project. The project breaks down into several customer-recognizable work items, flowing in this swimlane and showing the progress. When the project finishes, you can reallocate the swimlane and the capacity it visualized to another project.
Strategic initiatives, which often involve initial and renewable funding for multiple streams of work, are another candidate for “does this really need to be a work item?” An executive funding an initiative for $10m /year would be already fully justified (and the greater the funding, the stronger the justification) in wanting to see a visualization, whose height, literally the height dimension of the computer monitor, shows the capacity bought with their budget and how the organization is currently using this capacity as it is spending down the budget.
What all these examples have in common, they get rid of an unnecessary work item type and its instances – cards occupying space on the board and not conveying enough information. They all introduce different kinds of Kanban system visual elements, such as columns and swimlanes, and create space instead. Visualization screen real estate is expensive. Hierarchical workflows are inherently rich in detail. Too much visual detail increases cognitive load. Cognitive overload does not align with improvement. If you find yourself in this conundrum, apply the principle shown in the above examples: instead of occupying space, look for opportunities to create space.
The first advice on the Height dimension doesn’t assume changing the work item hierarchy, it only simplifies how the hierarchy is represented in Kanban systems. Opportunities exist, too, to change – simplify the hierarchy itself. The fan-out or child-to-parent ratio is the key indicator of such opportunities.
As a reminder, we are all in some kind of creative, intellectual business, where customers pay us to produce some non-trivial knowledge or information. If we pursue activities that are expensive, time-consuming, involve administrative and cognitive overhead, yet produce little information, customers and markets are unlikely to reward us well for them. And what if such activity is decomposition?
The fan-out ratio is a measure of information produced by decomposition. The average ratio of 1:20 on average may include possibilities that some parent work items consist of fewer than 10 child work items, while others consist of more than 40. Knowing, upon decomposition, that a particular parent breaks down into exactly 23 children, or somewhere in the range 20-25, is valuable information. If the fan-out is only 1:2 or 1:3, decomposition produces very little information. It points to a different improvement pathway: simplifying the hierarchy to fewer levels with greater fan-out ratios between them.
For better or worse, I’ve seen 1:2 fan-outs more often than 1:20. (I wanted to write “unfortunately” to open the previous sentence, but realized there’s good news, an untapped improvement reserve!) In one extreme case, a client claimed five levels of hierarchical work items. It turned out upon close inspection that the fan-outs between the top three levels were exactly 1:1 – they produced no information at all, three different senior managers signed off separately on the approval.
While the fan-out ratios place informational constraints on the optimal work item type hierarchies, there is also a physical constraint: time. The flip side of decomposition is recombination. Can we track effectively how child work items accumulate towards a parent work item? Can we get effective feedback into this process? Yes, and this requires the typical child’s time in process to be much shorter than that of the parent. How much shorter? One-tenth is a good approximation. Imagine a cumulative flow diagram (CFD), where the WIP band is one-tenth of the height or the average time in process is one-tenth of the width.
With three levels of such hierarchy, we’re looking at typical highest-level work items taking 100 times longer than the lowest-level work items. If the lowest-level work item can be completed in one day on average (not a trivial amount of work, but pretty fast, too), we’re looking at highest-level work item completions in months (on the order of magnitude of 100 days) – not bad! But remember, there’s approximately 2000 working hours in a year. With four levels, we’re operating with hours at the bottom level and close to a year at the top level. With five levels, we’re looking at a five-year plan at the top level micromanaged down to an hour at the bottom. Either that or – a more reasonable delivery timeline, but with very low fan-outs, about 1:3, hitting the informational constraints.
Summary of the Height dimension: modeling hierarchical workflows is inherently complicated. To scale effectively in this dimension, we must look relentlessly for opportunities to simplify. One important source of simplification does not involve changing the hierarchy. It only questions whether every parent-child pair needs to be represented as two types of cards on Kanban boards, whether everything “needs to be a card.” Many simplifying alternatives exist, unified by the principle of scarcity of visualization space: prefer creating space to occupying space. Further simplification is possible by changing the hierarchy, reducing the number of levels. Two constraints enable such simplification: informational, fan-out ratios between levels, and physical, time scales of work items on adjacent levels.
The Depth Dimension
The Depth dimension represents expansion of Kanban application in a company from one kanbanized service to several. As service processes in a realistic company are likely to be somehow connected or dependent on each other, we can anticipate a network effect. The services should evolve and improve not independently but impacting each other all the time.
To give a simple example and to save space a longer story would occupy, I’ll lean on Lisa’s story once more. Suppose Lisa’s peer’s mobile app team, instead of receiving Lisa’s team output, had a direct intake interface with the customers and two external dependencies, on the platform and API teams. That would be a network of three interdependent services, potentially a “subnet” of a bigger organizational network. This would clearly be a different flow pattern from the chain of three knowledge discovery activities performed by three teams.
The Depth dimension played an important historical role at the very time of Kanban method discovery by its originator David J Anderson. Transitioning from a single kanbanized XIT service at Microsoft to applying Kanban to many teams, projects and services at his new company, Corbis, David encountered a strong network effect and quickly learned to harness its power to advance the company’s improvement initiative. This involved several practices that were social in nature and developing a system of organizational feedback loops so that the network of interdependent services could balance itself. The result was what we now know as the Kanban method. An obvious example of such Kanban practice enabling an organizational feedback loop is the Operations Review cadence. A less obvious example is visualization – not essential in a single-service Kanban implementation, but vital when managers of various groups, services and projects needed a rich visual language to describe to each other the designs and behaviours of their Kanban systems. Such designs and behaviours meant and still mean, in plain speaking, how the managers see, manage, and improve the processes and systems whose results the managers are accountable for.
The most important element and focus of scaling in the Depth dimension is the Kanban system of cadences.
Suppose there is a responsible and accountable manager of one of the company’s services. The manager pays attention to the incoming demand, tries to deliver on customer expectations, strives for the balance of demand and capability, and finds improvement opportunities. As the manager’s service doesn’t exist in isolation, there is a network effect, any change in its policies or capability can impact the demand-capability balance or performance of another service. Such an impact may not be immediate; in practice, it occurs or is detected often with some time lag. The impacted service may spread the impact to still other services.
Timely propagation of information signals from one service to another, across the network of services and back to the service where the information originated, is essential. This is what the Kanban system of cadences accomplishes, particularly the replenishment meeting, the service delivery review (SDR) and the Ops Review.
The regularity of Kanban cadences is important. Don Reinertsen’s Cadence Reliability Principle (F7) and Variability Substitution Principle (V14) underpin this system. We trade variability of time for variability of content. The system of Kanban cadences embeds the preference for a weak signal to propagate within predictable time over waiting an indefinite period of time for a stronger signal.
Companies typically introduce the explicit replenishment meeting and the SDR after mastering the daily Kanban meeting, which is more prevalent and present even in low maturity Kanban implementations. Ops Review typically occurs later in the adoption sequence. There have been cases of Ops Review introduction before the SDR, but there were good contextual reasons for that, including taking advantage of a crisis.
A brief summary: from one service to many, network effect, Kanban cadences are essential, include Ops Review as one of the goals in the improvement plan, don’t forget the important principles of flow.
Scale-Free Opportunities
Scale-free is technically not a dimension, but a category for all phenomena that are independent of scale. If we have such a phenomenon in our present or future improvement footprint, we intend to exploit it, to “ride it for free.” We prefer not to create a scaling problem where there isn’t one.
The key Kanban method construct that takes advantage of scale-independent effects is the work item type.
Real-world businesses enter transactions and make promises to customers at very different levels of scale. When we model these real-world processes with Kanban systems, we can design work item types in these Kanban systems to represent these processes units of commitment, no matter what their size. There is a general preference in Kanban that, if you actually do something in your business, model it as-is in your Kanban system. Don’t follow a scale-dependent methodological prescription and try to shoehorn your real world into it.
How does this work in practice? At the largest end of the scale, a life sciences company decided to kanbanize their entire drug development pipeline. It is a Kanban system with a workflow, including various R&D activities, multiple stages of clinical trials, government approvals, and production and go-to-market preparation. A “ticket” in this Kanban system is a drug development program. So, “drug” is a work item type. Each instance of this type is a giant work item, representing the work of many specialists. It takes several years for this “ticket” to travel from the left side of the Kanban board to the right. The “daily” Kanban meeting is only needed monthly. Strange as this work item type may seem, this is the unit of commitment the company makes to the customers in the markets it serves.
At the opposite end of the scale, there is a typical IT support help desk ticket. Each ticket is a very small amount of work, often completed by the same specialist the same day. Many tickets are completed within hours or even minutes. And each ticket is a unit of customer commitment, too.
What these two vastly different work item types have in common, they’re both units of commitment. With global Kanban adoption, across various services and industries, the work item types of all these Kanban systems cover the entire continuum between the two extremes. Kanban doesn’t prescribe work item types, instead it calls the Kanban system designer to discover them in the real world.
Suppose we took a different, prescriptive approach to work item types. A software development methodology may define a feature as something taking a certain range of person-days or hours of engineering effort. Another methodology may define a system enhancement as something fitting a certain budget. Fitting such definitions into real-world processes would involve, politely put, scaling challenges. Kanban’s work item type construct sidesteps such challenges completely.
Each Kanban system’s definitions of its work item types may be evolutionary. Suppose you’re meeting with your customers. The conversation goes well, and you both feel like you understand each other, that you’re speaking the same language. The conversation includes sentences with the following structures: “We should deliver A before B”, “C and D are exposed to the same risk, which E is not”, “from proposals F, G, and H we can select only two.” Then what these letters represent are relatable examples of work items of the same type. The definition of this work item type may evolve guided by this fitness test: does it help us keep dialog with our customers and enter commitments?
A brief summary: Kanban seeks to exploit scale-free opportunities and not to create scaling challenges where they aren’t. The construct of work item type scales freely in practice across several orders of magnitude of cost, effort, and time. Work item type definitions may be evolutionary. Ease of customer engagement and commitment is the fitness test.
The Knowledge Dimension
There is a challenge in every improvement initiative, how to transfer knowledge from one or few experts to the many people in the company who need to apply it practically. From someone who knows the improvement method deeply to the many who need to know some elements of the method and apply it just well enough to pursue improvement of their organization and its outcomes.
Several traditional approaches exist and they’re all not without shortcomings. Training can deliver the essential knowledge to many people quickly, but with a large gap between the expert-teacher and the students, both in terms of the knowledge amount and the skills at its practical application. One-on-one mentorship and coaching can result in deeper knowledge and skill acquisition, but at a significant expense of time, especially if many layers of coaching relationships are needed to reach a critical mass of people in a large organization. All approaches run the risk of signal attenuation and dissipation of quality each time information passes from one person to the next. Sociology isn’t scale-free.
How did the Kanban community deal with this challenge historically? When we discovered a tool that helped us bridge gaps in the Knowledge dimension, we quickly came to appreciate it for its powers. We then started to apply it consciously and that included making sure that all of us at the expert levels of the community, teaching Kanban to others, were proficient in this new tool. Such discoveries weren’t frequent, but when they happened, the resulting knowledge became cornerstones of the method.
I’ll give two examples, the first one is STATIK (the systems thinking approach to introducing Kanban).
When I began working as an independent consultant, teaching my clients to apply STATIK revealed something interesting. I thought at the time the client companies’ internal improvement coaches were at a disadvantage compared to me. I learned STATIK directly from David Anderson and Mike Burrows. But my clients were not so lucky, because they had to learn it from me. Not only that, but they had to explain it to many people across the company, including those outside my reach as a consultant. The dissipation of quality was supposed to start with me. How much worse could it get and how quickly?
It turned out the quality didn’t dissipate at all. The quality of Kanban systems designed internally by managers of various services was just as good as if you gave the task to some of the best Kanban trainers or coaches. Designing Kanban systems with STATIK gave these managers a rich visual language to represent their process and their current understanding of it and to communicate how they were running and improving their process to other managers.
My second example is the Kanban Maturity Model (KMM), which appeared several years later and solved a similar knowledge-transfer problem for leaders and improvement coaches. KMM gave them language to speak in whole patterns of companies’ practices, culture, and outcomes; to tell concisely entire sagas of improvement initiatives. KMM also enabled effective transfer of skills critical to improvement coaches: how to give contextually appropriate advice, sometimes diametrically advice dependent on the context, and how to avoid failure modes known from the past improvement initiatives?
Although it’s speculative and probably a topic for a different article, it may be worth noting that tools that helped the Kanban community scale in the Knowledge dimension have expressive capabilities similar to those of languages. This may be more than a coincidence. Written languages, literacy, education (or at least a critical mass of literate or educated citizens in less than universally literate societies), using written texts, better yet, printed books for knowledge transfer are among the factors that enabled human societies to scale. A nation of one million citizens is considered small nowadays, but the primitive hunter-gatherer societies did not scale beyond several hundred.
Conclusions and Practical Considerations
We have just completed a quick overview of five scaling dimensions. Each of them represents a measure of size we cannot easily substitute for size in another dimension. For example, having four activities in a workflow is not the same as having four services. Three levels of work item hierarchy are not the same as three degrees of separation in the social network of knowledge carriers. Yet regulatory requirements for insurance companies may fit the same flow pattern as IT operations support tickets, despite orders of magnitude difference in implementation effort.
Each improvement initiative is unique. Each company has a unique improvement footprint, extending differently in each dimension. The footprint is also not static. As the improvement initiative progresses, the footprint expands and likely not evenly in all dimensions. It is therefore important for leaders and their improvement coaches to realize which scale dimensions are prevalent in their situation, perhaps even the one most important dimension, focus on that and worry less about the rest.
It may also be possible to identify whole classes of companies or their improvement initiatives where one or two dimensions are dominant. Such classes may encompass whole industries or geographical regions. It would then be desirable to tailor improvement methods, based on Kanban or not, with more prescriptive guidance in the dominant dimensions and looser guidance in the other dimensions, to increase the method’s effectiveness. Adopters of such tailored methods will find them easier to digest, relate to and implement successfully.