Visual Management – Creating A Kanban Multiverse

This is an article I originally wrote for the Management 3.0 site in 2010. As it is no longer available there, I am republishing it here in its original form other than a few minor edits.

At the Lean and Kanban Exchange in London in 2009, I was chatting with David Anderson and David Laribee about the possibilities for Kanban software tooling, and how a great piece for software could enable the visualisation of multiple dimensions within a two dimensional space. The right application could allow easy shifting between multiple perspectives to give different views on the various dimensions. This got me thinking, and led me to the concept a multiverse. This post is a write-up of the presentation I was due to give at the Lean Software and Systems Conference in Atlanta, before Eyjafjallajokull intervened. The associated Prezi can also be found on my blog.

Wikipedia defines as multiverse as “the hypothetical set of multiple possible universes that together comprise everything that physically exists: the entirety of space and time, all forms of matter, energy and momentum, and the physical laws and constants that govern them”. How does that map onto the concept of a kanban board? A kanban multiverse could be “the hypothetical set of multiple possible kanban boards that together comprise everything that physically could be visualised: the entirety of scope and time, all forms of work type, status and flow, and the organisational laws and constants that govern them”.

What would make a great kanban board to create this kanban multiverse? That led me to look into ideas around visual management and data visualisation, and think about what the data variants might be that could be visualised.

Visual Management

In a TED Talk Tom Wujec talks about 3 ways that the brain creates meaning. Firstly, visualisation creates a mental model because of the way that different areas of the brain process different visual inputs such as shape, size, and location. The greater the readability of a kanban board, the greater the impact of this visual processing. Secondly, interaction enriches the mental model further through engagement. The greater the usability of a kanban board, the more it will be interacted with. Finally, persistence allows the mental model to be part of an augmented memory which can evolve over time. The greater the visibility of a kanban board, the more accessible it will be as augmented memory. Thus kanban boards become such powerful tools when they create mental models through being visual, interactive and persistent.

This leads to the idea of boundary objects. Brian Marick wrote an introductory paper in which he talks about communities and practice and interest. A community of practice is formed around a work discipline, while a community of interest is formed around a common problem or concern. Communities of interest are made up of members of different communities of practice. A boundary object provides a means for communities of interest to communicate across their different practices, and a kanban board, through creating a shared mental model, can be a boundary object. This is because the mental model is created collectively and collaboratively, and helps clarify the meaning of what the board is representing.

Brian lists several properties of a boundary object which can be useful to bear in mind when building a kanban board; it should be a common point of reference for the community of interest, represent different meaning to different members of the community and help translation between the meanings, support coordination and alignment of the work within the community, be a plastic working agreement which evolves with the communities practices, and address different concerns of the community members simultaneously.

Another relevant set of ideas to visual management are those raised by Dan Pink when he talks about the surprising science of motivation. In his book Drive he says that rather than the carrot and stick approach of extrinsic motivation, a better approach is intrinsic motivation, which consists of three elements; autonomy, mastery and purpose. Autonomy, or the “desire to direct our own lives”, is achieved when team members can see what needs doing, understand the working agreements, and choose what they should do. Mastery or “the urge to get better and better at something that matters” is achieved through being able to interact with the kanban board to evolve and improve it. Purpose, or “the yearning to do what we do in the service of something larger than ourselves”, is achieved when the persistence of the kanban board makes it clear what the value of the work is and why it is being done.


In his classic book “The Visual Display of Quantitative Information”, Edward Tufte introduces a set of principles for the effective display of data. Given that a kanban board can visualise multiple pieces of data, it is useful to review some of these ideas.

Tufte talks about a number of different types of graphical designs. Time series is probably the most common, where time is along the horizontal axis, and another data type along the vertical. This is probably the least relevant design, because a kanban board is typically a snapshot of the current status. Similarly, a space time narrative, which tells a story in a spatial dimension over time, may not be the most obvious choice. It does raise the question of visualising the narrative of the work over time though, which could be interesting. Maps also introduce some different ideas. What would a kanban board look like it showed the terrain of a project, and where each piece of work was on that terrain? The most common form kanban board is probably a relational one, where the two axes show different types of information, such as scope and status. Tufte refers to relational graphics as being more sophisticated and interestingly, from a Lean and Toyota perspective claims that Japanese publications tend to have more sophisticated graphics.

Most of the book is spent discussing ways of improving the way that data is presented; specifically, maximising data ink, reducing chart junk, and improving data density. Data ink is the ink that actually represents data. While kanban boards generally use more than just ink, the principle holds true for making sure that as far as possible, anything on the board should hold information. The corollary to this is that anything which isn’t data ink is chart junk. Grids, redundant data, or decorations and embellishments for aesthetics may create noise which masks the real story. Finally, data density is the amount of data within the given space. The eye can take in a high precision of detail, so by maximising the data ink and being clever with multi-functioning graphical elements, it is possible to visualise many dimensions in a small space.


This leads us to the decision of how we can represent a kanban multiverse. Each dimension that can be visualised is what Edward Tufte calls a variant, and a kanban board is a multi-variant display. What are the variants, and how can they be displayed, using maximum data ink, minimum chart junk, and at a greatest density? This post will not provide the answers, but will I hope provide some ideas for thinking about some alternatives and creating innovative solutions.

The variants will typically be the usual project management interest, but can include the concerns of any member of the community of interest. As a starter, there are the popular “iron triangle” variants of scope, time, resource and quality. Other common variants are things like priority, status, issues, risks, constraints, dependencies and assumptions. More recently, teams have been talking in terms of variants such as capacity and demand, not to mention value and other economic points.

To visualise all these variants we can use a number of techniques. Properties such as size, colour, format, location and alignment can all create multi-functioning graphical elements to achieve a high data density. For a physical board, material and texture can add further depth. What would the implications be of showing quality with colour, or dependencies with material?


A kanban board is more than simply a task board, or a story board, or even a team board. It’s a visual management tool to create a shared mental model amongst a community of interest. As such, sophisticated display techniques should be used to create meaning and motivation through collaboration and communication.

Thanks to Xavier Quesada Allue who has written much more about techniques for creating kanban boards on his Visual Management Blog, and who I have had many interesting conversations about ideas for creating kanban boards.

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

Agile Toolkit Podcast on Visual Management

Last June I spent the week in Las Vegas at the Agile Development Practices and ended up hanging out with Bob Payne and doing a podcast with him where we talked about visual management techniques, including Visualisation TIPs.

Bob has just published that podcast. Enjoy!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 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)

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)

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)

Kanban and Tragedy of the Commons

After Limits to Success and Shifting the Burden, we now come to Tragedy of the Commons.

I live in the seaside town of Brighton in the UK. On the rare weekends when we have hot weather it is popular to go down to the beach. Everyone gets in their cars and drives into Brighton expecting a quiet, relaxing day on the coast. What they actually get is a noisy, crowded area full of lots of other people who have had the same idea. This is an example of the “Tragedy of the Commons” archetype. The beach (and the roads to it), are the commons – a shared resource. Individually, each person expects to gain some pleasure from the beach. However, when too many people visit, nobody gets any pleasure from the beach, because it has limited capacity and quickly becomes over-crowded.


Individually, A and B’s activity give themselves separate net gains so that they each benefit through a reinforcing loop. However, their activities combine to create a total activity which, after some delay, eventually consumes a common resource beyond its limit. At that point, A and B’s activity begins to reduce those separate net gains through a balancing loop.

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

Often, a Tragedy of the Commons occurs as a result of Shifting the Burden to the commons. By setting up the system to deal with the Shifting of the Burden, the likelihood of the Tragedy of the Commons can be reduced.

Similarly, the commons becoming overloaded is a specific case of Limits to Success, and setting explicit limits for the commons will avoid this. Further, creating a buffer before the commons will ensure that there is always work when the capacity is available. In Theory of Constraints terms, this is exploiting the constraint.


A kanban system also helps with a Tragedy of the Commons by helping visualize the total activity, so that everyone is aware of the demand on the limited resource. Further, each party can limit their own activity to avoid the total activity becoming too great. Swim-lanes are one approach to visualising this.


Finally, Classes of Service can then ensure that the limited resource is being used effectively for the most appropriate work. Swim-lanes, or colour-coding, can create clarity of which work is more important, based on its Cost of Delay. This clarity can also help keep an appropriate balance of different types of work in order to manage the risk of the commons unnecessarily delaying urgent work.


What other examples of Tragedy of the Commons have you experienced, and what other techniques have you used to visualise them?

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

Kanban and Shifting the Burden

Following on from a look at the Limits to Success system archetype, lets now look at the Shifting the Burden archetype.

I like my coffee in the morning. In fact I usually need a good cup of coffee before I start to feel human. Some days I like a coffee to start the afternoon as well, and occasionally I’ll have a few more in-between to keep me going. This is an example of ‘Shifting the Burden’ archetype. I feel low, so drink coffee to pick me up. However this is just a short term fix and I eventually need more caffeine to maintain my energy. The real problem is why I have low energy; late nights, a poor diet and little exercise. Rather than getting more sleep, eating a healthier diet, and exercising, I am shifting the burden to the caffeine. If I were to shift the burden to a stronger (and less legal) drug, then it is likely that my need for the drug itself would become the problem, rather than my lack of energy. At this point, the archetype has moved from Shifting the Burden to Addiction.


Shifting The Burden begins with a Problem Symptom. The quick or easy answer to this problem is the Symptomatic Solution which creates a balancing loop. However, there is also another answer – the Fundamental Solution – which can create an alternative balancing loop. The Symptomatic Solution only eases the symptom though, and doesn’t resolve the underlying problem, so the symptom consistently returns. The Fundamental Solution does address the root cause, but has a delay though, which means that it is more of a long term answer than a quick fix. The more the Symptomatic Solution is applied, the more a Side Effect takes place, which over time with delays reinforces the need for the Fundamental Solution, while at the same time making it less feasible. When the Side Effect becomes more of a problem than the initial Problem Symptom, is when the Shifting the Burden archetype becomes one of Addiction.


Recognizing the archetype leads us to examine our solutions to problems and to question whether they are Symptomatic or Fundamental. When problems re-occur over time, then using Root Cause Analysis techniques may lead to finding alternative Fundamental Solutions. Continually depending on technical specialists or coaches may be a Symptomatic Solution, whereas investing in training on knowledge sharing may be a better Fundamental Solution. As the well-known Chines proverb says, “give a man a fish and he will eat for a day, teach him how to fish and he will eat for a lifetime”

A Kanban System can help cope with Shifting the Burden, once a problem symptom has been identified, in the following ways:

  • Signalling occurrences of the identified problem symptoms so that they are transparent and appropriate focus can be made on the fundamental rather than symptomatic solution. A brightly coloured tag or shape can achieve this.


  • Visualizing what problems symptoms are being addressed by various symptomatic or fundamental solutions. The Concern, Containment, Countermeasure pattern can be useful here where problem symptom is defined and stated as a Concern. The Containment action is the symptomatic solution taken to resolve the problem quickly. Then, after root cause analysis, the Countermeasure action is the fundamental solution to prevent repeated recurrence. (Thanks to Jason Yip for pointing me to this pattern)


  • Allocating capacity and limiting work in process for work related to fundamental solutions using a dedicated swim-lane and WIP limits. This treats the improvement efforts as first class work types, with equal visibility to the rest of the work.


What other examples of Shifting the Burden have you experienced, and what other techniques have you used to visualise them?

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

A Model for Creating a Kanban System

This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

  • Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
  • Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
  • Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

  • Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
  • Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
  • Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
  • Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
  • Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.

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

Exploring the Kanban Multiverse at Agile2010

I ran a workshop on “Exploring the Kanban Universe” at Agile2010 with Xavier Quesada Allue. The premise was to setup an example case study and lead participants through visualising different aspects of a project – the different multiverses – over a number of iterations.  Below are pictures of the final boards from the different teams. We encouraged people to think ‘outside the box’ and try and move away from traditional rows and columns approaches.

The highlight for me was the circular design that one of the teams came up with. I thought it was a great solution to the challenge of avoiding kanban boards appearing to show a linear process. With a circular design, a work item can loop round the circle multiple times, with the distance from the centre indicating closeness to completion, and different quadrants indicating the primary focus of work such as analysis, dev, test etc. This was the nicest example of a board as a ‘map’ as opposed to a ‘relational’ representation.

One thing that was reinforced for me was that a Kanban Board should not try to visualise absolutely everything. Its should have just enough information to signal where the issues are, and where the team should look to find out more. In other words it should be able to “point to the gemba”. Thanks to Harada Kiro to reminding me of this after the session. In future runs of the workshop we’d like to try starting with a blank canvas each iteration to avoid teams feeling constrained by trying to show too much and having to build upon previous designs.

I also gave a talk on the subject at the Lean & Kanban Conference in Belgium last week after which Mary Poppendieck pointed out that I’d slipped into referring to some visual management designs as kanban boards when they strictly weren’t because they didn’t limit WIP. Visual Management is a large part of a Kanban System, but not every Visual Management board is a Kanban board.

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