Constraints that Enable

Enabling constraints are a key concept for understanding and managing the Complex domain described by Cynefin. Unfortunately the concept of enabling constraints is poorly understood. Many attempts to provide examples of enabling constraints tend to assign some form of “goodness” to the concept.

What are Enabling Constraints

An excellent distillation of the literature on enabling constraints can be found here.

At the 2017 Cynefin Retreat in Snowdonia (In the shadow of Cynefin), Alicia Juarrero introduced the following properties of enabling constraints:

1. Enabling constraints are context sensitive.
2. Enabling constraints force alignment of the agents which leads to resonance and this creates a higher order system.
3. The higher order system provides feedback to the agents which constrains their behaviour and stablises the higher order system.

This philosophical description of enabling constraints based on biological systems is too abstract for many to grasp so Alicia gave Barnard Cells as a simpler “mechanical” example.

The challenge has been to find examples that relate to Agile Software Development.

The first example

Study of approaches to portfolio prioritisation approaches led to an understanding that Cost of Delay is a governing constraint. It is effective providing the portfolio only contains items whose value is in the obvious and complicated domains. Given that technical debt always needs to be included in a portfolio, SAFE manages this by creating a separate technical backlog. The problem is that the portfolio never aligns. Responsibility for technical debt is delegated to technologists, and responsibility for business prioritisation sits with the business. True alignment within the portfolio never occurs and the decision making is always sub-optimal as an unnecessary division exists within the portfolio.. Technology and Business do not align where the entire investment can be focused on either Business or Technology as required by the context. Investment decisions are focused around the process which is always subject of failure rather than a team that is resilient and able to adapt. By definition, Cost of Delay cannot evolve because it is the end point.

Capacity Planning has a different approach to portfolio prioritisation. In capacity planning, the constraint is much simpler.

All decision makers (key stakeholders) need to come together on a regular basis to strictly order the portfolio backlog based on the (team level) constraints.

This constraint causes alignment. The decision makers need to create an optimal portfolio. Initially they may try to create a portfolio that optimises their own outcome. The constraint of having to do this regularly (typically a quarter) means that they move from a two person single iteration of the prisoner’s dilemma to a multiple person multi-iteration version of the prisoner’s dilemma. The emergent behaviour of the prisoners dilemma is collaboration, which occurs faster if its a multi agent version. It is normal for the system to fail as part of the emergence of collaboration (Storming to norming transition in the Truckman model). In the capacity planning constraint, the failure normally occurs with the prioritisation method which changes from iteration to iteration, allowing the constraint to remain. (From my experience, even detractors of the constraint will defend it as it provides stability to the organisation). If governing constraints are used, when they fail, the entire constraint can fail and the process can fall apart (Chaos).

The higher order system that emerges from the capacity planning constraint is the team of decision makers that focus on the optimal outcome for the portfolio rather than their individual outcomes. This team is resilient to changes in process.

The General Rule

Understanding that capacity planning is an enabling constraint, and cost of delay is a governing constraint, quickly helped me see other examples of enabling constraints.

Scrum done properly is an enabling constraint. The rules of Scrum, especially swarming, create high performing, high trust teams as a higher order system.

Extreme programming done properly is an enabling constraint. The rules of XP, especially pairing, create high socio-technical system as a higher order system. The socio-technical system is a technology system and a team that maintains and develops the system.

Kanban done properly is an enabling constraint with a high trust team as a higher order system.

The Cynefin framework when used for sensemaking (Four corners contextualisation) is an enabling constraint where the higher order system is a distributed cognition system with a shared understanding of the contexy.

The Cynefin Framework when used for categorisation (Butterfly Stamping) is a governing constraint.

In Safe, bringing the whole team together at the PI planning is an enabling constraint.

In Safe, constraining the approach to planning (everyone in the room), and prioritisation (Hippo enabled WSJF) are governing constraints.

Enabling constraints are contextual. Governing constraints are not contextual, they are fixed in nature. Therefore the following are governing constraints:

1. Cost of Delay
2. Black and White Photography
3. A safety harness
4. Haiku

As a practitioner, I look forward to feedback from experts on where the above is wrong.

Governing Constraints

Where there is no uncertainty, governing constraints are the most effective approach. Where there is no uncertainty, use of enabling constraints is at best inefficient and at worst destabilising, and destructive.

If you are operating in a constrained organisation where every investment must be supported by a business case articulated in economic terms, and where the investments need to be approved by a finance function, then cost of delay is the ideal prioritisation process. Getting stakeholders to form a team to cooperate on prioritising the portfolio is unnecessary and inefficient.

We value Enabling Constraints OVER Governing Constraints

Assigning goodness or preference to enabling or governing constraints is missing the point.

Enabling constraints are better for complex domains.

Governing constraints are better for complicated domains.

Saying enabling constraints are better than governing constraints is like saying fish are better than bicycles. Its all about context.

Thank you to…

For the past year, a small group have been discussing enabling constraints with the intention of better understanding them, and better communicating the concept. I would like to thank Marc Burgauer, Trent Hone, Alicia Juarrero and Jabe Bloom for including me in some of their discussions. Most of my understanding of the subject comes from these discussions and the patient socratic questioning of Marc Burgauer.

I would also like to thank Paul Ader and Andrew Webster, fellow authorised Cynefin trainers, who are working with me to create training material for the Cynefin Wiki.