Constraints to Improve Flow

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.


An officer acting as a constraint to improve overall flow. He was only moderately successful.

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.

Unconferencing #NoEstimates

A little over a week ago, Paul Boos hosted the first Agile Dialogs Unconference. Our subject was inspired by the debate surrounding #NoEstimates. We hoped to get beyond some of the rhetoric and grapple with perspectives from both sides. I was hopeful that we would increase our overall understanding and generate some ideas for real improvements we could use with our teams. I think we achieved that goal.


A number of good ideas came out, and Paul has generated an accurate list. For me, there were three main lessons. The first is that when we debate #NoEstimates or #YesEstimates, we’re often talking about very different things. We paused several times in our discussions to ask ourselves what we really mean by “estimates.” There were some very diverse perspectives and we often needed to recalibrate. Differences in the definition of “estimates” influence how we approach the idea of #NoEstimates and what we think it means. Many of the arguments on Twitter seem to have their origin in these kinds of misunderstandings.

We were able to get past that in our dialog and draw out some valuable perspectives from both sides. From the #NoEstimates side, I think one of the most important lessons is that when we make an estimate—regardless of whether or not that is a traditional time estimate or one involving something more abstract like story points—we risk anchoring ourselves to a particular implementation approach. This may be fine.

But there are cases where it will lead us down an undesirable path and trigger rework or introduce technical debt. It can be difficult to avoid, as we often don’t realize the impacts of our assumptions until we have a chance to test them. Usually, that comes long after an estimate has been made. Teams that make estimates might want to keep this in mind.

Critics of #NoEstimates point out that estimates are often blamed for broader organizational dysfunctions. We discussed this at length and cited a number of examples from our own experience. Although estimates are a visible aspect of dysfunction (like when they’re used to transfer risk), that does not mean they are the cause. They may only be a surface symptom; discarding estimates may have no effect on these deeper issues and may only further complicate the problem. If you’re looking to discard estimates, you may want to investigate whether or not this applies to your environment.

As with many things, the benefit or harm of estimates appears to be very much dependent on context. By getting together and sharing our experiences, we helped broaden our perspectives and gain more understanding. I’m looking forward to more Agile Dialogs.