Skip to main content

The Magic Power of Enabling Constraints

February 26, 2024

Looking at complexity theory as described by David Snowden, we have various decision-making contexts called domains. These domains describe different ways of how we solve given problems. They are Simple (Clear), Complicated, Complex, and Chaos.

With simple problems, we have all the facts; we work with the known knowns. Given the right set of instructions, anyone can solve the problem. We have best practices with tight constraints. A tight constraint means variation is neither wanted nor needed.

With complicated problems, we know what we don't know, the known unknowns. People with the right educational background can analyze the unknown problems and come up with an answer. We have good practices based on governing constraints. A governing constraint means to ensure that the decision-making process has been following certain rules or policies.

Both simple and complicated are ordered domains with a clear cause-and-effect relationship. The whole process is controlled, and for this reason, they are repeatable.

With complex problems, which product development is, we work with the unknown unknowns. We don’t know what types of problems will strike when, making them unplannable. How can we cope with those?

Road with a guard rail

Enabling constraints to the rescue. Enabling constraints guide and enhance creativity and innovation by establishing a chance to compare what we have with what we wanted. This understanding helps to inform our next decisions. Through this approach, the right solution will emerge, and for that reason, we have context-dependent emergent practices. This feedback-driven approach is referred to as empirical process control.

I like to think about enabling constraints as guardrails. They don't prevent accidents, but if an accident happens, they prevent the worst.

Enabling constraints can be manifold.

What enabling constraints are part of Scrum?

Sprint Length - you can do whatever you want but only for so long. In the Sprint Review, you have to show what you have created. This provides transparency with the chance to inspect and adapt.

Definition of Done - you can do whatever you want, but this is the quality standard you have to follow, no excuses. This allows the product to remain extendable and maintainable while also being releasable.

Sprint Goal - provides focus and flexibility in reasoning in how to adjust; the developers plan the Sprint Backlog.

WIP limits referred to as the forecast - this provides focus and enforces collaboration between the Developers, especially in the Daily Scrum.

Cross-functional Team - different backgrounds and past experiences preload conflict into the discovery and development phase. This allows a more creative thinking and problem-solving approach. The resulting conflict-resolution drives out a higher quality product for both aspects: Validation and Verification.

Vertical slicing - Instead of breaking down a problem into disjoint components which need assembling at a later point, a vertical slice assembles continuously by developing a slice and integrating all components. This requires a cross-functional team, which requires a specific organizational structure based on sound engineering practices.

Don't be confused by enabling constraints; use them, identify enabling constraints in your given context, and leverage these guardrails for your competitive advantage.

PS: I've also created a video about Complexity which you can watch here.

What did you think about this post?