Kanban flowing according to architecture

Comments (3)

Print This Post Print This Post

Email This Post Email This Post

Permalink

So far, we’ve been discussing kanban systems aligned according to workflow. We’ve found that this scales up to teams of about 50 people, beyond which we worry about team cohesion. For larger problems, we will have to introduce new elements of organizational structure.

It is natural to represent workflows as state machines, and we have already introduced hierarchical state machines in progressively decomposing functional specifications into ‘features’.

kanban_bug_0.jpg

At the next level of scale, imagine an architecture that is partitioned into three components: two lower-level components that are largely independent of one another, and a higher-level component that integrates features from the other two:

components.jpg

Perhaps it is a web application that consumes two web services. Each component has a WIP limit and a completion queue. Each component may internally manage its own WIP using a workflow kanban system, so that the “in process” state for component A explodes into a separate board like the one at the top.

Suppose each of the yellow tickets represents a 20-page functional specification. Each of those specs might be broken into 20 features. Component A has 15 people assigned, B has 20, C has 25, and there are another 20 assigned to the system overall, for a total of 80 people.

The WIP limits of components A and B are proportioned according to the rate of consumption by component C. The relative rate of consumption of A or B may shift over time, and WIP limits can be adjusted up or down in response.

Imagine in this case that C is under its limit in spite of available capacity. They are waiting on an interface from A. A is at its limit, and does not have capacity to spare. This might be an isolated occurrence, but if it happens often, then resources might be allocated to A, or A might work on improving its cycle time. At the same time, B seems to be working ahead a little, so maybe B can reassign some people to A to help them along, Brooks’ Law notwithstanding. Test might be a little backed up, but they are relieved by slack in C.

For a well-factored architecture, this kind of system should scale out to hundreds of people.