Kanban System Design

which may then each expand into Tasks. The Tasks subsequently collapse back together to realise the User Stories, which realise the Features, which ultimately realise the Benefit.

Understanding the workflow thus consists of knowing what we consider to be of value and what expand and collapse points there are to create feedback and deliver that value through the system. It can be thought of as understanding the system structure, which may be a network rather than linear, and making our model of this system structure explicit helps us to deliver the value more effectively through the network.

Another way of thinking about discovering a workflow is to view it as process archaeology. A process often has many layers, and by digging through those layers we can surface what is really going on. This will typically involve talking to the team members about how they really work, and it will often result in something other than what was expected, as problems that were previously hidden are surfaced.

Common items to look for in a workflow include queues and batches, and failure demand. Queues and batches are points in the workflow where the work is being processed. Queues are where work is building up because there is not enough capacity to process it and batches are where work is being held to be handed over and processed in a large volume. Failure demand is where work is the result of not doing some, or not doing something right. Rather than optimising a value system for failure demand, the failure demand itself should be avoided.

Visualisation
Visualisation is the means by which we can understand the work and the workflow by creating a powerful visual management tool that shares a mental model of the system structure which is visual, interactive and persistent.

In a recent TED Talk [iii], Tom Wujec explains how this works when he talks about three 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. Secondly, interaction enriches the mental model further through engagement. Finally, persistence allows the mental model to be part of an augmented memory which can evolve over time.

This leads to the idea of boundary objects. Brian Marick wrote an introductory paper [iv] 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 visualisation, 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 visualisation is representing.

Marick lists several properties of a boundary object which can be useful to bear in mind when building a visualisation; 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 as the community learns, 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"[v] he says that rather than the carrot

Tags: 

About the author

Karl Scotland's picture
Karl Scotland

Certified ScrumMaster, Agile Coach, Kanban Coaching Professional, Accredited Kanban Trainer

Karl Scotland is a versatile software practitioner with over 15 years of experience covering development, project management, team leadership, coaching and training.  For the last 10 years he has been successfully applying Agile methods, and most recently has been a pioneer and advocate of using Kanban Systems for software development.

Currently an Agile Coach with Rally Software in the UK, Karl is a founding member of the Lean Software and Systems Consortium and the Limited WIP Society, and has previously championed Agile and Lean Thinking with the BBC, Yahoo! and EMC Consulting. Karl writes about his latest ideas on his blog at http://availagility.co.uk/