Lean Software Engineering

Part 2 of Patterns of Software Engineering Workflow

The simplest kind of kanban system is the CONWIP system, for CONstant Work In Process.  The simplest kind of CONWIP system is no more than our fundamental kanban element:

The simplest CONWIP cardwall is a classic Agile cardwall with a limit on work-in-process:

An equally intuitive interpretation of CONWIP defines capacity simply as the number of people available to work, so that each person is the kanban:

CONWIP is a rule about work items, not a rule about workflow.  We are free to define any workflow we like as long as we observe the global limit.  This can be a helpful approach when we want to observe the flow of work, but expect a lot cycling between states, perhaps in an exploratory design mode:

The earliest Scrumban design was just such a CONWIP workflow, which we can represent directly in a simple cardwall.  Here we have no limits on any specific column, but the total number of work items is limited by the yellow kanban cards, which are returned to the “Free” box when the task they contained is complete:

Breaking out a workflow implies a sense of sequence.  If there is no real sequence, we could define a global “busy” state and reduce specific activities to a checklist.  Exposing the workflow to visual control might suggest a need to level resource utilization or that we value reducing backflows as an improvement goal.  Pooling the WIP limit suggests that the visual control is enough feedback to help the team achieve leveling.  My personal preference is to work in this way where possible.

If a person can be the kanban, then how about a pair? If we combine pairing and kanban with a workflow or checklist, then we get something like Arlo Belshee’s Naked Planning:

I think the most interesting kind of CONWIP system is the Bucket Brigade. Everybody is allowed one card at a time, which can either be moving upstream or downstream. People can either pair (at the cost of some queueing) or work solo as much as they prefer. Constant WIP, zero queueing, full utilization, soft specialization, balanced workflow…what’s not to love?

The model can be edited and simulated in PIPE2.

If we can assign tasks and limit work by pairs, then why not do this with whole teams? That is essentially the approach of Microsoft’s Feature Crews with their quality gates.

Some value streams are too long or too complex to effectively manage with a single WIP limit.  Many development teams exist within some larger organization that requires coordination between teams and competition for resources.

Where do features come from?  Smaller shops may interact directly with the customer, but larger shops may have a more complex process for dealing with a large number of customers or with highly sensitive customers. If we peer inside the black box of the Product Owner, we might discover a whole team of people working to understand customers and define requirements: business analysts, product managers, usability researchers, product designers. Work-in-process on the business analysis side can just as easily go off the rails as development work.  Have you ever seen an epic requirements specification or a bottomless product backlog and wondered where it came from?  Your product owner might represent another group of people who feel pressure to produce and look busy.  Value stream thinking encourages us to take an interest in what those people are up to and why.

Where do features go after we’ve built them? A large enterprise may have complex deployment requirements that involve integrating code into a manufacturing process or provisioning a datacenter. This work probably involves a different team than the development team, but they are still part of the value stream and their throughput affects everybody.  Operations teams often have to deal with long lead times and different natural batch sizes than the development teams that feed them.  Each group can benefit from understanding the status and availability of the other.

A small team may be able to self-regulate with visual control, but a long value stream may need more explicit control. Kanban gives us an easy solution by chaining together pooled segments. Within each segment, we manage by visual control, but between segments, we manage by kanban:

CONWIP systems allow us to regulate team workflow with a lighter touch.  Pooling kanban across closely related functions and zooming out by one level of scale makes it easier to think about using kanban to manage large systems.