A typical Kanban board usually shows a series of steps or activities that work passes through. In software development, this may take the form of work items passing through some sort of discovery step when analysis or design happens, to a building or development activity, before it passes through a validation or testing stage. Such a visualisation often shows that work items move from the left hand side of the board to the right.
Kanban has its origins in manufacturing, most famously as part of the Toyota Production System (TPS). In manufacturing plants, it is possible to see a product being built in a linear manner as it passes through the various work stations where specialist activity takes place. We saw this for ourselves when we visited one of the Toyota plants while we were in Japan. The shell of the body of the car passes various assembly points. The engine is added at one, the gearbox at another, at others the clutch, doors, tyres etc. Each incremental addition contributes to the car emerging as a completed product as it passes along the assembly line.
Modelling product development for physical products in a manufacturing line in a left to right fashion is one thing, but does it really make sense to do the same for an intangible product where product development is complex, as is the case with software? Scrum is a proven strategy for addressing complex adaptive problems, a domain where any sense of ‘linearity’ is misguided, and progress is instead made through disciplined inspection and adaptation loops. Yet many Scrum teams – indeed all Scrum teams that I have been involved with – whether with a physical board or an electronic tool, use some form of visualisation that represents work passing along stages in this “left to right” way. Such a technique is a complementary practice in Scrum, one that is essentially taken from the Kanban practice of “visualisation of the workflow”.
Scrum teams often see this concept of linearity breaking down. For example, an item reaches a validation stage, only for a defect to be discovered. Some teams will send the item “backwards”, back to a development step to be fixed, or even further back for analysis work. Very soon, items on the board are seen to be jumping around in different directions, maybe even skipping over steps in the workflow on the way. While not a prescribed rule in Kanban, many would forbid this from happening, with a policy stating something like “work only goes in one direction, from left to right.” How can that be practical? The order of activities on the work would appear to be non-linear. Does that mean that a visualisation of a linear set of steps of work is unsuitable for complex product development? And by implication, is Kanban a far from perfect approach to take in the complex domain?
Kanban, as applied to the complex domain, is much more than visualisation and work in progress (WIP) limits. There are a number of characteristics that one would expect as a minimum to meet the definition of a Kanban system. One such requirement when applying Kanban practices to Scrum for example is having a clear definition of the work items. The key here is that this work item definition must be in units of value, whether this is customer value, business value, knowledge acquisition value or some other measure of value. Granular tasks are great for development teams to self-organise and manage their work, but what we are interested in for a true Kanban system is the visualisation of the flow of these units of value, not granular tasks that do not deliver meaningful value by themselves. With Scrum teams, these are typically expressed as Product Backlog Items.
Why is this important in this discussion? When we model the flow of work items as units of value, activity on the item may well be non-linear. However, while the dominant activity on a piece of work in the complex domain is non-linear, the value being added is linear. Put another way, the act of working on an item, by whatever function, should be an act of adding value. At times, progress may seem to be halted or even go backwards, however, this is all part of the discovery and knowledge acquisition process – value adding concepts in their own right in any empirical process. Modeling the flow of value adding activities is a core concept that Kanban can bring to Scrum to enable greater transparency, and inspection and adaptation opportunities.
We can therefore think of each step in the workflow as steps in the knowledge acquisition and feedback process instead of hand off between functions. Let’s return to our earlier example of an item that has progressed to a testing phase and a defect has been found. In this case, we are discovering new knowledge about the main work item through the act of validation. A useful and common practice to give visibility of what is happening, is to leave the original item where it is, and create a new item that represents the defect to be worked across the board until it catches up with its parent.
This article was triggered by a discussion in one of our recent Professional Scrum with Kanban (PSK) classes, where we look at how adding Kanban practices can be a powerful strategy for enhancing Scrum. Visualising work as units of value and the value adding activity this work goes through, along with the other Kanban practices such as limiting work in progress and active management of work items in progress has radical effects on what it means for collaboration, self-organisation and empiricism. You can learn more about the PSK on the course description page.
Feature photo by Jon Tyson on Unsplash