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.


About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

5 responses to “Constraints that Enable

  • Marc

    I’m giving it a go at giving “feedback from experts on where the above is wrong”, although I am not sure what qualifies oneself as an expert in this matter. 😉

    In my understanding, constraints are not in themselves governing or enabling, it is the context in which they appear that determines that.

    For a person who uses a simple camera with a Black & White picture setting, that cannot be changed, it’s a governing constraint. Ansel Adams however experimented a lot with using different exposure times for various parts of an image when developing his BW photos, sometimes covering areas with cutouts to learn how material (film, paper, etc.) and exposure times impact the final colour, allowing him to find the exact balance he was after. So for Adams, using BW was an enabling constraint as he was acting on the feedback to modulate the impact of the constraint contextually, based on the elements of the picture.

    Context is important whether a constraint is enabling or governing. I.e. what interactions between a system and the constraint take place and can the interaction change the constraint as well as the system, by which the constraint and the system it acts on become together a higher order system.

    Therefore a “method” is dependant on how it can be exercised in context to become enabling or governing. We can observe Scrum as a socially-enforcing top down constraint. When the team is unable to change its Scrum process, it’s governing. E.g. they’re not allowed to change articulation of artefacts, like all teams have to use Jira with the same template and their backlog items have to be all expressed in time estimates, so that management can produce portfolio level Gantt charts.

    That Scrum can be abused in this way is not a design flaw in Scrum, but due to the very nature of its openness to change, to its adaptability, which is necessary for it to be an enabling constraint. Sutherland himself says somewhere that if you still do Scrum exactly as described in the guide months after you start using Scrum, you’re not doing Scrum. Inspection and adaptation are not limited to the work we facilitate with Scrum, but are to be applied also to how we exercise Scrum itself.

    • emilesilvis

      I think this hits the nail on the head: the constraint in its context determines whether it’s enabling or constraining.

      Haiku can be an enabling constraint (in fact, that’s exactly what’s makes haiku so awesome).

  • Daniel Doiron

    Sometimes a constraint can be both. At beginning, column WIP limits are enabling constraints for the while they reduce Lead Time. As these benefits dampen they are no longer enabling unless you use Kanban boards in a DBR mode @tendon and let go of Work State WIP limits.

  • olaviggo

    Great post! But I think you are wrong on the “separate technical backlog in SAFe”-bit. The idea in the SAFe backlog is to show “enablers” (technical changes that enables user facing stuff) along with the user facing stuff that they enable. So that those in charge of ordering the backlog are forced to look at the whole.

  • Five Blogs – 18 December 2018 – 5blogs

    […] Constraints that Enable Written by: Chris Matts […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: