Kanban System Design


For example, a specific benefit to a customer may expand into a number of features, which may expand into various user stories, which may then each expand into tasks. The tasks subsequently collapse back together to realize the user stories, which realize the features, which ultimately realize 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 something, or not doing something right. Rather than optimizing a value system for failure demand, the failure demand itself should be avoided.

Visualization 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 that is visual, interactive, and persistent.

In a recent TED Talk [3], Tom Wujec explains how this works when he talks about three ways that the brain creates meaning. First, visualization creates a mental model because of the way different areas of the brain process different visual inputs such as shape, size, and location. Second, interaction enriches the mental model further through engagement. Finally, persistence allows the mental model to be part of an augmented memory that can evolve over time.

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

Marick lists several properties of a boundary object that can be useful to bear in mind when building a visualization. It should be a common point of reference for the community of interest; represent different meaning to different members of the community; help translation between the meanings, support coordination, and alignment of the work within the community; be a plastic working agreement that evolves as the community learns; and address different concerns of the community members simultaneously.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.