In my work with software teams, I often use traffic flow as an analogy. It is an extremely accessible way to describe the concepts of capacity, flow, and utilization. We all seem to have experienced traffic in one form or another and even the smallest localities have their share of traffic jams. Most people appreciate the value of the analogy immediately, which makes it easy to relate the use of metered on-ramps to work in progress (WIP) limits in a software system, an approach I like to take.
This familiar analogy can be extended. Recently, I’ve started realizing how constraints in traffic systems influence self-organization and flow. Some traffic constraints are obvious and common across geographies. We’ve all experienced lights at intersections, roundabouts (or traffic circles), stop signs, and yield signs. Some less obvious constraints, such as curbs, medians, and lane markers define the roadway. All of these together help to control the flow of traffic and make it easier for us to navigate to our destination.
Alicia Juarrero and others have broadened our understanding of complexity by emphasizing the impact constraints have on self-organization. She divides constraints into two major categories. Context-free constraints limit options, but lack contextual significance. It is often useful to think of these constraints as being imposed from above, or from another level of the system. Context-sensitive constraints, on the other hand, arise from within the system itself.
Within a traffic system or a software development process, both types of constraint can have an impact on flow. A stop sign is a good example of a context-free constraint. It controls flow by forcing vehicles to stop when they reach it. If the way is clear, then they can proceed; otherwise they wait. But the sign has no knowledge of the state of the system. You’re required to stop regardless of whether cars are approaching on the cross street.
A parallel in a software process might be a WIP limit on the “Development” column within a team’s Kanban. Although the choice of the particular value for the WIP limit is very sensitive to context, once it is chosen it acts like the stop sign, forcing work to wait until capacity is available regardless of the broader context.
Both the stop sign and the WIP limit can help improve overall flow. The stop sign exists to allow improved traffic flow along another axis, or to control flow through the intersection. The WIP limit prevents work from building up in Development, allowing more rapid feedback to that activity from downstream processes. These smooth out the flow in both systems.
Context-sensitive constraints also exist in traffic systems and software systems. These tend to be less obvious unless you’ve had a chance to immerse yourself in them. But even as a passenger, it quickly becomes apparent that the unwritten “rules of the road” are very different between India and Germany, or Italy and England. There are even subtle differences between Maryland and Virginia, where I tend to spend most of my time driving. This is because drivers in each of those locations have a specific set of expectations for how they believe they should behave in traffic. These expectations constrain their behavior, and they differ from place to place. Software teams have similar unwritten “rules” of behavior that influence their flow.
Together these context-free and context-sensitive constraints largely determine the overall flow of the system. Interesting relationships between the types of constraints can be seen. The German traffic system, for example, is relatively highly constrained by the “rules of the road.” German drivers go through an extensive certification process, giving them a strong common sense of how to behave on the roads. One result is that they tend to stay out of the passing lane unless they are passing. This context-sensitive constraint improves the flow of traffic on two-lane roads.
Contrast this with Virginia, where the use of the passing lane is far less disciplined. Drivers sit in it, inhibiting flow and triggering backups. To improve flow, traffic engineers end up adding new lanes. In effect, they’re substituting a context-free constraint (another lane) for a context-sensitive constraint (limited use of the passing lane) to achieve the same end (improved flow).
India is another good example. In Indian cities like Chennai, the “rules of the road” lead to the utilization of the entire expanse of the roadway. Lane markers are ignored and all spare capacity is utilized. This works well to fit lots of traffic into a confined space, but it can have a crippling impact on overall flow. Driving becomes a series of negotiations as each vehicle jockeys for just enough space to move forward.
To compensate for this, the city of Chennai has begun to introduce context-free constraints: large barriers have been installed along the sides and down the center of major roads. These limit the ability of traffic to enter and exit the roadway. They also prevent traffic travelling in one direction from flowing over into the oncoming lanes. Although some of my friends there might argue the point, I think they’ve improved flow.
Similar relationships between context-free and context-sensitive constraints exist in software systems. Some teams have developed a common understanding—a sense of how much work they can handle—and can do without WIP limits within their system. They maintain flow through their “rules of the road.” Other teams lack this capability and have sought to achieve the same end through WIP limits, a disciplined understanding of their velocity, or other means.
Neither of these approaches is inherently more valuable. The key is understanding how the team is behaving today and determining how best to maintain an effective flow. If you regularly bog down and have variable flow, context-free constraints may be the best way to start. In other circumstances, working on team cohesion may be more effective. There are many approaches to that; I’ve found Lean Coffee to be an effective one. Informal conversations over coffee breaks are good too.