The Science of Kanban – Economics

This is the fourth part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of process

Having a good understanding of how creative people can have an efficient process still isn’t enough however. As Russell Ackoff is often quoted as saying, “It’s better to do the right thing wrong, than the wrong thing right”. An understanding of economics is needed to avoid “doing the wrong thing right”, by focussing on the “right thing”, whether that involves financial return, risk management or information discovery, all of which are of value. One financial model that I picked up from Chris Matts is that features should increase future revenue, protect existing revenue, reduce existing costs, or avoid future costs.

Life Cycle Profits

A basic understanding of investment over time helps explain why smaller batches and smaller increments are preferable from an economic perspective. In Software by Numbers, Denne and Cleland-Huang show the investment, payback and profit periods. A smaller cash injection, over a shorter investment period, can enable a product to become self-funding and break-even sooner, such that the profit can be invested back into the product for continued development.


Cost of Delay

The Cost of Delay concept, as popularised by David Anderson, further informs scheduling decisions based on cost over time. The four most common archetypes used (but limited to) are:

  • Expedite – the cost of delay is high and immediate. These items are genuinely urgent and should be prioritised above everything else.
  • Standard – the cost of delay rises linearly. Examples are items with an opportunity cost, where the later the delivery, the more opportunity for gain is lost.
  • Fixed Date – the cost of delay rises sharply at a specific date. Examples are regulatory dates at which fines may be imposed, or seasonal dates such as Christmas or trade-shows.
  • Intangible – the cost of delay is likely to happen in future, but the exact nature is unpredictable. Examples are technical debt or infrastructure work


Information Theory

Value does not have to be purely financial. In particular there is often value in information generated, as suggested by information theory.


Information Theory says that for experiments with pass/fail results, a 50% failure rate is optimal. Always failing suggests that nothing is known, and subsequently nothing is being learned. Always succeeding suggests that everything is already known, and thus nothing is being learned.

The Lean Startup approach is essentially based on information theory, with the goal being to loop through the Build, Measure and Learn cycle as quickly as possible.


This can be thought of as buying information, and asymmetric payoff curves help explain the benefits of this approach. Given some notional performance target, an asymmetric payoff curve is one where being below target results in a loss, being above target results in a gain, and hitting the target results in breaking even. Buying information enables the shape of the curve to be changed such that losses below target are minimised, and gains above target are maximised.



Having a good understanding of the economics enables better decision making when designing and scheduling the work. Usually selection of what work should be pulled next relates to cost and value. Higher value for lower cost generally trumps lower value for highest cost.


An example is risk reduction. There is value in risk reduction, where the higher the risk, the greater the value there is in reducing it, and there is also a cost associated with reducing the risk. Having an understanding of the relative values and costs of risk reduction activities informs the sequencing of high value, low cost items earlier and low value, high cost items later.


Similarly Set Based Concurrent Engineering can be informed by economics. SBCE involves working on multiple parallel initiatives in order to reduce risk. Multiple initiatives should only be run while the total cost of the initiatives is less than the value of the risk reduction. Each additional initiative adds less value exponentially, while the total cost rises linearly. Multiple experiments are like buying insurance; when the cost of the insurance is greater than the economic benefit, it’s not worth paying for.


In the final part, I’ll draw together some conclusions.

VN:F [1.9.22_1171]
Rating: 4.8/5 (8 votes cast)

The Science of Kanban – Process

This is the third part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of people.

Even though a kanban system describes knowledge work, we can still apply formal sciences such as mathematics. Rather than applying them at a detailed, micro level, we can take a system approach and apply them at the broader, macro level. As an example, if we try and predict the result of a single coin toss, we are only able to do so with 50% accuracy due to the unpredictable, random nature. However, if we to try to predict the result of 1000 coin tosses, we can be more accurate, albeit with less precision and some degree of variance.

Queuing Capacity Utilisation

The most common mathematics used with kanban systems is associated with queues and utilisation. Queuing capacity utilisation suggests that as capacity utilisation increases, queues increase exponentially. Thus extremely high utilisation will result in large queues.


Further, Little’s Law tells us that the time something is in a queue (lead time) is equal to the size of the queue divided by the processing rate.

Lead Time = WIP / Processing Rate

It follows then, that if we want to complete work quickly (i.e. with a short lead time), then should reduce queues, which requires reducing utilisation. Reducing utilisation too much, however, will begin to have diminishing returns.

Traffic Flow Theory

Traffic Flow Theory gives an explanation as to why a work-in-process limit on one may be too low.


Originally observed by Bruce Greenshields in 1934, Traffic Flow Theory describes how, as speed (in miles per hour) goes up, the density of traffic (in vehicles per mile) goes down, and vice versa. This is observable on roads with a low density of cars (i.e. empty) which are able to travel at high speeds, and roads with a high density of cars (i.e. gridlocked and bumper to bumper) which are stationary. Flow is defined as the product of speed and density, and thus there is an inverse u-curve, with high flow in the middle, and low flow at either end due to either low speed, or low density.

For product development, density can be viewed as work in process, speed correlates to lead time, and flow correlates to throughput. If work in process is too low for the available capacity, then lead time will be short, but throughput will be low. Similarly, if work in process is too high for the available capacity, then lead time will be long, and throughput will be low.

An interesting effect happens on either side of the flow curve.

On the left side, if density is increased (increasing work in process), speed decreases (increasing lead time), and flow decreases (decreasing throughput). The decreased flow causes a further increase in density resulting in a negative reinforcing loop.

However, on the right side, if density is increased (increasing work in process), speed decreases (increasing lead time), and flow now increases (increasing throughput). The increased flow causes a decrease in density resulting in a balancing loop.

Thus, while the optimum density is unlikely to be achieved precisely, it is better to be on the right hand side, with slightly less work in process, where a slight increase will balance itself out.


It’s generally recognised that software development is a non-linear activity, due to the many feedback loops, so it’s useful to understand the effect that the feedback loops have on a process.

One of the impacts that a feedback loop has is related to its delay, where a long delay can lead to instability and oscillation. Taking a shower as an example, if when trying to turn the heat of the shower up, there is a long delay between turning the tap and the water temperature increasing, the natural reaction is to turn the temperature tap further. Eventually, when the change in water temperature comes through it will be too hot. The same can happen again when trying to turn the heat of the shower down again.


Thus it is a good idea to minimise delays in feedback, or put another way, have fast feedback. Fast feedback also results in smaller queues, because less work builds up waiting for feedback. Smaller queues result in less work in process, and we have seen that lower work in process leads to shorter lead times. Shorter lead times further generate faster feedback, resulting in a positive reinforcing loop.


In the next part we’ll cover the science of economics.

VN:F [1.9.22_1171]
Rating: 4.9/5 (7 votes cast)

The Science of Kanban – People

This is the second part of a write-up of a talk I gave at a number of conferences last year. The previous post was the Introduction.

Software and systems development is acknowledged to be knowledge work, performed by people with skills and expertise. This is the basis for the Software Craftsmanship movement, who are focussing on improving competence, “raising the bar of software development by practicing it and helping others learn the craft.” A kanban system should, therefore, accept the human condition by recognising sciences such as neuroscience and psychology.


Neuroscience helps us understand the need for strong visualisation in a kanban system. Creating visualisations takes advantage of the way we see with our brains, creating common, shared mental models and increasing the likelihood that the work and its status will be remembered and acted on effectively.

Vision trumps all our other senses because our brains spend 50% of the time processing visual input. Evidence of this can be found in an experiment run on wine-tasting experts in Bordeaux, France. Experienced wine-tasters use a specific vocabulary to describe white wine, and another to describe red wine. A group in Bordeaux were given a selection of wines to taste, where some of the white wines had an odourless and tasteless red dye added. These experts described the tainted white wine using red wine vocabulary because seeing the wine as red significantly influenced their judgement. The same experiment has apparently also been run on novice wine-tasters who were less fooled, showing the danger of how experts becoming too entrained in their thinking.

Visual processing further dominates our perception of the world because of the way our brain takes the different inputs from each eye. For each index card on a board, instead of seeing two, one from each eye, the brain deconstructs and reconstructs the two inputs, synthesising them into a single image by making up and filling the blanks based on our assumptions and experiences. Thus what we end up with is a mental model created by the brain, and the kanban board helps that mental model to be one that is shared between the team.

The more visual input there is, the more likely it is to be remembered, en effect known as the pictorial superiority effect (PSE). Tests have shown that about 65% of pictorial information can be remembered after 72 hours, compared to only 10% of oral information. Visualising work status and other dimensions on a kanban board can, therefore, increase the chances of that information having a positive influence on outcomes.


Neuroscience also explains one of the benefits of limiting WIP; that of reducing multitasking.

Multitasking, when it comes to paying attention, is a myth. The important detail here is that it is when it comes to paying attention. Clearly we can walk and talk at the same time, but if we have to concentrate on climbing over an obstacle we will invariably stop talking. The brain can only actively focus on one thing at a time and studies have shown that being interrupted by multitasking results in work taking 50% longer with 50% more errors. For example, drivers using mobile phone have a higher accident rate than anyone except very drunk drivers. In other words, multitasking in the office can be as bad as being drunk at work!

Other studies have shown that effectiveness drops off with more tasks. In “Managing New Product and Process Development: Text and Cases” by Clark and Wheelwright show that when someone is given a second task, their percentage of time on valuable work rises slightly because they are able to keep themselves busy when they are blocked. However, beyond that, with each additional task the time spent adding value reduces.


Gerald Weinberg suggests similar results in “Quality Software Management: Systems Thinking” when he reports that for each additional project undertaken, 20% of time is lost to context switching.



Recognising the way we deal with challenging situations, and how we can change, enables us to deal with the visibility and transparency that a kanban system creates in order for us to learn and improve.

As humans, we are natural explorers and learners. We evolved as the dominant species on the planet by constantly questioning and exploring our environment and trying out new ideas. However, when faced with difficult situations, we tend to react badly. Chris Argyris coined the term Action Science to describe how we act in these situations. The natural reaction is single loop learning, where we resort to our current strategies and techniques and try to implement them better. A more effective approach can be double loop learning, where we question our assumptions and mind-set in order to discover new strategies and techniques.


Another relevant model is Virginia Satir’s Change Model which describes how our performance dips into the valley of the ‘J-Curve’ while we adjust to a new way of being. Being aware of the dip, its depth, and our response it, can inform an appropriate approach to influencing change.


Next we’ll cover the science of process.

VN:F [1.9.22_1171]
Rating: 4.9/5 (8 votes cast)

The Science of Kanban – Introduction

This is a write-up of a talk I gave at a number of conferences last year. I have split it into 5 parts.


Science is the building and organising of knowledge into testable explanations and predictions about the world. Kanban is an approach which leverages many scientific discoveries to enable improved flow, value and capability. This article will explore some of science behind kanban, focussing on mathematics and brain science in particular, in order to explain the benefits of studying a system, sharing and limiting it, sensing its performance and learning in order to improve it. Readers will gain a deeper understanding of why and how kanban systems work so that they can apply the theory to their own team and organisation’s practices.



When I first started talking and writing about Kanban I was trying to articulate that Kanban is more than just using a card-wall. The kanban board is the visible mechanics of the system, but the goal is achieve a flow of value, and while time-boxes become optional, a cadence is required to understand capability. I referred to this triad of Kanban, Flow and Cadence as KFC (the irony being that fried chicken is not at all lean!) and that blog post from October 2008 remains the most popular I have written. While my language and thinking has evolved since then, I have realised that as I learn more about the science behind Kanban, much of it still maps back to those three core elements.

Kanban Thinking

This article will not describe how to design a Kanban system, but explores some of the science behind Kanban Thinking, an approach to creating a contextually appropriate solution.

Kanban Thinking is a systemic approach which places an overall emphasis on achieving flow, delivering value and building capability. The primary activities are studying, sharing, limiting, sensing and learning, and thus Kanban Thinking is itself a scientific approach.

Scientific Management

Frederick Winslow Taylor is generally credited with the development of Scientific Management in the late 19th Century by applying a scientific approach to improving manufacturing processes and publishing “The Principles of Scientific Management” in 1911. Given that we are now in the 21st Century, how relevant is scientific management to us today for software and systems development? Scientific management is considered to have become obsolete in the 1930s, yet I believe we can still apply science to understanding why and how differences in productivity exist. Scientific theory can be used to inform the practices we use, while our experiential practice can also inform and evolve the scientific theory.


Dave Snowden’s Cynefin model is a good example of balanced theory and practice. Cynefin suggests that there are different domains, and that we should act appropriately for each one. Thus depending on our understanding of the current context, we should apply scientific theory differently, and implement alternative practices appropriately. Thus scientific management can still be relevant for software and systems development if we apply a scientific approach contextually.


The manufacturing context was probably complicated at worst, with elements possible being simple. Thus Taylor’s approach to scientific management, with best and good practice, was appropriate. However, software development and knowledge work is often complex, so the appropriate approach is to allow emergent practice, using what Snowden calls probe-sense-respond.

Making an Impact

In a complex domain, not being able to predict or repeat cause and effect does not mean that a situation cannot be improved. It is still possible to understand the current state, and current performance, and known whether things are improving. Rather than simply reacting to the current state or attempting to predict or plan for a future state, having anticipatory awareness of the current state, with a view to exploring its evolutionary potential, allows the application of continuous experimentation to sense whether we are making an impact by improving outcomes for both the business and for the people.

I’ll cover some of the sciences that can be used to make an impact in the following future posts:

VN:F [1.9.22_1171]
Rating: 5.0/5 (4 votes cast)

Visualising Kanban Dimensions with TIPs

Following on from my post describing a Kanban Visualisation TIP (Token, Inscription, Placement), this post gives some examples of how to visualise the various dimensions of a Kanban Multiverse. The goal is not to define any ‘correct’ ways of visualising information, but to show that there are a variety of useful approaches and hopefully inspire further new creative approaches. As such, I have listed at least 3 techniques for each approach and tried to include some variety.

The dimensions I have used are the usual project management details, but can include the concerns of any member of a team or community. Let me know what other dimensions or data variants could be added, and what interesting techniques have you used to visualise them.


Scope represents the content of the work associated with an element.

  • The size of the token can indicate the amount of work, with larger cards involving more functionality.
  • An inscription can describe the scope, most commonly with a written annotation.
  • A linkage can reference further details about the scope stored elsewhere.


Time represents the when work starts and ends and how long it has been in progress for.

  • Colour can indicate the aging of tokens, where lighter cards are newer, and older cards are darker.
  • Graphics can also be used to represent aging, with a dot or other symbol, being added for each day. Different colour dots can further distinguish between what state the work is in for each day.
  • A simple annotation of aging, or key dates can be written, using formatting to distinguish different information.
  • Where a particular date or service-level is being targeted, an annotation can be added at key points in time, such as 50%, 90% and 100%+.
  • The horizontal placement within a column can indicate time in progress, with the card moving further right each day.


People represent who the work is being done by (as opposed to resources!).

  • Colour can identify the ownership of a token for small teams, or a primary functional or disciple group for larger teams.
  • An avatar can be used as a graphic inscription to identify ownership.
  • Horizontal alignment in swim-lanes can also group tokens and associate them with people or sub groups.


Cost represents the estimated effort required to complete the work.

  • The size of the token can indicate the cost of work, with larger cards involving more effort.
  • Colour can indicate the cost of the work, especially when using relative sizes or buckets, with larger cards representing bigger pieces of work.
  • An annotation could be written on the token to indicate the estimated cost, such as a relative points, or t-shirt size.


Quality represents how well the work is being done.

  • Colour can indicate whether the token represents value demand or failure demand. More failure demand indicates lower quality.
  • An adornment can indicate the grading of a piece of work, where a lower grade (e.g. F) represents lower fidelity work, and a higher grade (e.g. A+) represents higher fidelity work.
  • An annotation of the number of tests and/or defects can indicate the level of testing that has happened for a piece of work.
  • The vertical placement of a token can indicate quality, with higher placement representing higher quality.


Priority represents how important the work is.

  • Colour can indicate priority if using an enumerated scheme such as MoSCoW, where a mix of priorities is used to manage risk.
  • The vertical placement of a token can indicate its priority, with high placement representing higher priority.
  • Horizontal alignment in swim-lanes can also group tokens by Class of Service to indicate prioritization policies.


Status represents what the progress of the work is.

  • Vertical alignment in columns can indicate the current phase of a piece of work.
  • The rotation of a token, such as making it portrait rather than landscape, can indicate that the status of the work has changed significantly, or that it is “done” for its current phase.
  • An adornment can be used to represent key status types such as “blocked” or “done”.


Capability represents the amount of work that can be worked on at any time, managed through work in process limits.

  • Where tokens are grouped through alignment in rows and columns, an adornment of the grouping can indicate the amount of work than can be taken in within the group.
  • Alignment groups can also have a fixed number of “slots” which indicate the amount of work that can be taken on within the group.
  • Graphical adornments such as avatars for team members can be limited and attached to tokens to indicate who is working on what.


Demand represents the amount and type work being requested. Demand could show failure and value demand types such as defects and features, classes of service, such as regular, fixed date or expedite, or investment allocations such as portfolio items.

  • Colour can indicate the different types of demand for a relatively small number of possibilities.
  • Shape or material can also indicate demand, and can be combined with colour to show combinations of work type, class of service and investment allocation.
  • Horizontal alignment in swim-lanes can also group tokens by demand type.


Value represents the benefit of completing the work

  • Colour can indicate the value where a granular enumeration is being used such as High, Medium and Low.
  • Size can also indicate an enumerated value, with larger tokens representing more value.
  • A formatted annotation can be written to indicate the value where a more precise number is being used.
  • The vertical placement of a token can indicate its value, with high placement representing higher value.

Externals: Issues, Risks, Constraints, Dependencies, Assumptions

These are all factors which are external to the represented work, but which impact it in some way. Issues represent things that might impact the progress of the work. Risks represent things that are impacting the progress of the work. Constraints represent things that limit the way in which the work can be completed. Dependencies represent things that must also be done as part of the work. Assumptions represent things that are expected to happen in order to complete the work.

  • Adornments can be used to represent these external factors, with colour being used to distinguish between the different types.
  • A separate token can represent each external factor, with colour being used to distinguish between the different types.
  • The placement of separate tokens relative to the main work item can show the relationship of external factors, either horizontally or vertically as sub-states, or in a more free-form manner such as mind-map.
  • A linkage can reference further details about the external factor stored elsewhere.
  • A annotation can be written to provide more details about external factors. Formatting can help identify the different types.
VN:F [1.9.22_1171]
Rating: 4.3/5 (3 votes cast)

Thoughts on Kanban Thinking

Some thoughts on what I have been referring to as Kanban Thinking

Why create an other brand?

I’m in the camp that believes we need to create more brands, rather than reduce everything down to “common sense” or “good practice”. To paraphrase Alistair Cockburn, every successful team should create its own branded processes to describe the context and the solution.

Why another “Kanban” brand?

By using the name Kanban, I am acknowledging the roots of my current approach in hearing David Anderson talk about Kanban at Agile2007 in Washington DC. I consider that to be as important a turning point in my career as when I first read about Extreme Programming in 1999. Further, my response to calls to provide a single, clearer definition of Kanban for software development, is to encourage more definitions of Kanban. The more definitions there are, the less dogma there will be, and the more people will have to think for themselves about what Kanban means to them.

Why the “Thinking”?

As I mentioned when I blogged about Agile Thinking at the start of the year, thinking should be a core part of what we do. Alongside Lean Thinking, A3 Thinking, Systems Thinking, Complexity Complexity Thinking and Design Thinking, I want to make this explicit. Emphasising the thinking is also intended to make it clear that action is also required to succeed. Kanban Thinking is not a silver bullet as the right action is needed for each context.

What is Kanban Thinking?

Kanban Thinking is systemic. It takes a mindset of optimising the whole system, whatever the boundaries of that system are defined to be. Part of the thinking is deciding what those boundaries are. They do not naturally exist but are created by us to help frame a context.

Kanban Thinking strives to achieve flow, deliver value and build capability.

  • To achieve flow is to have smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste.
  • To deliver value is to focus on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost.
  • To build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.

Kanban Thinking involves studying, sharing, limiting, sensing and learning.

  • Studying the current system helps understanding of the existing context.
  • Sharing the understanding gives everyone knowledge about what is happening.
  • Putting limits in place bounds the system to help stabilise it.
  • Sensing how the system is performing gives an understanding of current capability.
  • Learning from the systems performance allows for capability to be continually improved.
VN:F [1.9.22_1171]
Rating: 4.9/5 (9 votes cast)

The Economics of Raking Leaves

I was out in the garden this weekend raking up leaves. Having read Geoff Watts recent post about using Scrum to clear his leaves – and as someone who can’t do anything without thinking about work (see Kanban and Quad Biking!) – my mind turned to how I would use Kanban Thinking to approach the work at hand. Surely I would advocate single piece flow by clearing up each leaf individually, visualising and measuring my progress?

I hope its clear that doing as such would be insane! But why? Maybe “single leaf flow” would be better? Why did my instincts shout out otherwise? The answer, as I have learned so often recently, comes down to making an economic trade-off. Every decision has a value and a cost, and finding the right balance is key, preferring higher value and lower cost.


Each leaf cleared from my lawn would have value in progressing me towards my goal of a tidy garden. However, the transaction cost of removing each leaf individually would be far too great. Therefore, a more sensible trade-off was to batch the leaves into piles, so that transaction cost was spread over a larger number of leaves.

Further, like Geoff, I also considered the risk of creating multiple piles before bagging them up. I could also run out of bags, or have the piles blown away. However, I knew I had plenty of bags, and it was an unseasonably still day, so I created multiple batches before bagging. I was even able to safely have lunch between batching and bagging without any regret. In other words I made another trade-off between the value (in terms of addressing risk) and cost. The value (or risk) wasn’t great enough to justify the cost.

I may not have designed a Kanban System to rake the leaves, but I did apply some economic thinking to decide what to do. If there’s one main lesson I’ve learned over the last few years, its that there is rarely a ‘right’ answer, but that there are trade-offs, and they are usually economic.

VN:F [1.9.22_1171]
Rating: 1.0/5 (1 vote cast)

Scrum Gathering London – A Blast From the Past

At the Scrum Gathering in London this October, I had a bit of a flash-back to the last time the Gathering was in London. At that event, during the Open Space, I announced a Kanban session with words along the lines of “My team recently stopped using Scrum and our productivity has improved”. As I recall it, there was an audible intake of breath, although I’m sure my memory has exaggerated the effect!

I was reminiscing about this with Rachel Davies, who facilitated the Open Space at both Gatherings, and she shared the photographs she had taken of the output, which she still had. Here they are for posterity. I expected to find much of my thinking had changed since then, but apart from having less focus on waste and inventory now (preferring to know emphasise value and flow) it still seems relevant.

Here are the photos – thanks to Benjamin Mitchell for being the scribe. I’m hoping to add some of the audience which I know are out there somewhere.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

A Kanban Visualisation TIP

In an earlier article I wrote on Visual Management, I described how kanban boards can be viewed as multi-variant displays, visualising multiple possible dimensions of a kanban system. To visualize all these variants we can use a number of techniques to create multi-functioning graphical elements which can achieve a high data density. The techniques, when categorized and combined, create a visualization TIP, such that each element is made up of the following:

  • Token
  • Inscription
  • Placement


The Token is the element which represents some piece of work, with the attributes material, size, colour and shape all able to represent information.


The material is the base composition of a Token. Common materials are index cards and sticky notes, although anything which can be easily inscribed and placed on a kanban board will do.


To add a further dimension, the material can be used in different sizes to show some relative relationship between similar elements. Index cards, sticky notes and other adhesive shapes all come in a variety of sizes.


Similarly, the material that is being used for a visualization element can have different colours to show some enumeration. Again, index cards, sticky notes and other adhesive shapes also come in a variety of colours.


As well as typical rectangular index cards or sticky notes, other shapes, such as stars or circles, can differentiate between various elements. Similarly, a variety of shaped annotations or adornments can convey further information.


The Inscription is any detail added to the token about the work. Common types of inscription are annotations, graphics, linkage and formatting.


Annotations are any written information added to a token to give basic details about what the token represents.


Graphics can also be used to illustrate information related to the work in a more symbolic manner.


Linkage can provide references to further information, or related work items, in order to keep the inscription focused on the most relevant information.


How information is presented on Tokens can help to make them readable. Clear and consistent layout, using a tabular arrangement or zoned areas, ensures that any inscription is easily consumable.


The Placement is how the Token is positioned on the kanban board, with the location, alignment and rotation all being relevant.


Where an element is positioned can convey meaning, with horizontal or vertical placement being significant on a relational board design. The importance of location can also extend to elements such as cards themselves, with the position of annotations proving important.


When location is significant, then alignment can show a relationship between different elements, usually horizontally or vertically. Alignment is often used to create columns or swim-lanes with which to create an association. Other options include zonal alignment in a map-based format, or proximity alignment in a mind-map format.


The rotation of an element can mean different things, particularly with rectangular shapes which can be positioned in either landscape or portrait mode, or at some other angle.

When designing a kanban system’s visualisation, thinking about how the TIPs are used can help come up with solutions which are creative and contextually appropriate, and help avoid falling into the trap of copying known and sometimes simplistic examples, as highlighted by Keith Braithwaite.

In a future blog post, I intend to demonstrate how different dimensions of a kanban system might be visualised with a TIP. In the meantime, I wonder if you think I have missed any other techniques?

Update: I have written a follow up post giving examples of  visualising kanban dimensions with TIPs

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Crystallising Kanban with Properties, Strategies and Techniques

On the flight out to the Kanban Leadership retreat in Iceland last month, Katherine Kirk and I were chatting about Kanban failure modes that we’ve seen out in the field (e.g. quirky command and control interpretations by people who had not had experience in Agile first), and played with the idea of combining Kanban with Crystal (kind of in the same way that ScrumBan combines Kanban with Scrum). We jokingly referred to this as CrystalBan.

The reasoning behind our discussion was that Crystal and Kanban are both adaptable, context driven approaches. Crystal concentrates a lot on working with the ‘human’ side of the methodology equation – highlighting good, tried and tested Agile properties, strategies, and techniques – and Kanban is focussed on incremental improvement at a pace which respects people’s ability to absorb change. We discussed how, as an Agile/Lean community, we sometimes take it as given that Kanban for software and systems was pioneered by people from the Agile world, and therefore we often don’t explicitly state what to use from Agile to get the best out of Kanban. Maybe we should?

It was a fairly light-hearted conversation, so we didn’t pursue it in Reykjavik, but the idea didn’t die either as both of us kept coming back to it. We held an Open Space session at the UK Agile Coaches Gathering a few weeks ago which didn’t produce anything really concrete, but did get some murmurs of interest, so Katherine and I sat down this week to thrash it out.

Why Bother?

Kanban failure modes was a topic twice covered in sessions in the Kanban Leadership Retreat and, interestingly, difficulties with ‘humans interacting with humans’ were pinpointed as one of the common causes of Kanban failure modes. Crystal’s main properties, strategies and techniques deal a lot with the people side of the equation from the Agile perspective…. which opens up the idea that it might be a nice possible blend with Kanban.

So, are they compatible? Can they work together?

In his book Crystal Clear,Alistair Cockburn describes Crystal as “a family of methodologies with a common genetic code, one that emphasises frequent delivery, close communication and reflective improvement…” and he points out that, as it is context driven, that “…there is no one Crystal methodology”. As a result he admits that some groups can “have trouble with Crystal because it is too empty to start with.”

In his book Kanban, David Anderson describe Kanban as “an approach that drives change by optimizing your existing process”.  This makes Kanban relatively easy to start with because the “essence of starting with Kanban is to change as little as possible”.

Given that Crystal gives guidance on what a successful process will look like, based on a strong Agile foundation, and that Kanban gives guidance on how to improve an existing process, drawing from Lean, it seems that they are a natural fit to realise the benefits of both while avoiding the risks. A win-win.

Crystal Properties

Crystal describes seven properties of a successful project, the first three of which are core:

  • Frequent Delivery – e.g. “the single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months”.
  • Reflective Improvement – e.g. “a project can reverse its fortunes from catastrophic failure to success if the team will get together, list what both is and isn’t working, discuss what might work better and make those changes in the next iteration”.
  • Close Communication – e.g. “information flows into the background hearing of member of the team, so that they pick up relevant information as though by osmosis”. (Referring specifically to Osmotic Communication in Crystal Clear)
  • Personal Safety – e.g. “being able to speak when something is bothering you, without fear of reprisal”.
  • Focus – e.g. “first knowing what to work on, and then having time and peace of mind to work on it”.
  • Easy Access to Expert Users – e.g. providing the team with “a place to deploy and test the frequent deliveries”, “rapid feedback on the quality of their finished product”, “rapid feedback on their design decisions”, and “up-to-date requirements”.
  • Technical Environment with Automated Tests, Configuration Management, and Frequent Integration – “such well established core elements that it is embarrassing to have to mention them at all”.

In order to achieve these properties, different strategies and techniques can be employed. This is where we see that Kanban comes into play.

Kanban Strategies and Techniques

One source of Kanban strategies is David Anderson’s Recipe for Success:

  • Focus on Quality
  • Reduce Work In Progress
  • Deliver Often
  • Balance Demand against Throughput
  • Prioritise
  • Attack Sources of Variability to Improve Predictability

What David calls “five core properties to create an emergent set of Lean behaviours” could also be thought of as techniques in Crystal ‘dialect’. David’s five core properties are:

  • Visualise Workflow
  • Limit Work-In-Progress
  • Measure and Manage Flow
  • Make Process Policies Explicit
  • Use Models to Recognise Improvement Opportunities

I have a different model I use which maps onto strategies and techniques. The strategies are:

  • Study the System
  • Envisage the System
  • Limit the System
  • Sense the System
  • Learn about the System

with the associated techniques:

  • Value Stream Mapping
  • Visual Management Board
  • Work In Progress Limits
  • Cadence and Measures
  • Quantitative Experiments

So What?

Katherine and I both observed that the Kanban strategies and techniques do achieve the top three Crystal properties of Frequent Delivery, Reflective Improvement and Close Communication, as well as help towards some of the others. However, because Kanban for software and systems in the most part has its origins in the Agile world, perhaps its time, as a community, to start to examine whether we should be a bit more explicit about all the good Agile resources that already exists – as Kanban starts to expand further into ‘non Agile’ territory.

People new to Kanban, and without Agile experience and knowledge, may easily miss the benefits from some of the other properties, as listed in Crystal Clear, which have been tried and tested by the Agile community for many years. In the same way that Alistair made the Technical Environment property explicit, despite it being so well established, we shouldn’t forget all the existing established strategies and techniques which can enable the other properties.

Further, this approach helps us understand how other strategies and techniques from outside of Agile can help towards successful implementations. For example the work of Chris Argyris, as promoted by Benjamin Mitchell, can help towards Personal Safety.



I’d like to thank Katherine for her time, energy and passion in helping form this and collaborate on writing it up.


VN:F [1.9.22_1171]
Rating: 5.0/5 (6 votes cast)