3-22 Ignoring intentional constraints

Don't be surprised...

What happens when you just ignore how something is designed to work? What happens when you ignore a designed limitation?

Think about systems like your home heating and air conditioning system. They have sensors designed to add a constraint so that the systems know when to turn on or turn off at certain temperatures. Imagine what it would be like if you didn't have that in place.. your furnace might just keep running all the time, which wouldn't be great, especially on a 90 degree day.

Now think about other, larger systems.

What if people just ignored all the red lights and stop signs? We're gonna have a lot more accidents, a lot more injuries, a lot more damage to vehicles, and a lot more delayed traffic.

What if we didn't have pressure gagues and limiters in our water systems, or natural gas systems? Imagine a jet of flame errupting from your stove, or the pressure in hot water tank building up and shooting the tank like a rocket through your roof.

Constraints are designed to help us get to better outcomes by forcing some limitation that prevents unwanted outcomes. That last part is probably the most important aspect to think about. We are intentionally using some constraints to control the outcomes to things we want

Now think about intentional constraints we use in our systems of work:

If we define everything up front before we start to do any work or begin to learn from what we are producing, we know that we are going to have to rewrite or rework so of the outcomes and outputs that we've defined.

If we ignore our wip limits, and just keep on starting up work, eventually we will grind to a halt and not be getting anything done beause we will be trying to do too many things.

If we accept work from anyone rather than just a product owner or service request manager, we may be working on things that aren't providing value.

If we're using a framework like scrum, and we change the size of the sprint, we lose the ability to understand what what we can commit to each sprint because of the variation.

I've seen teams ignore all of these intentional constraints in their ways of working. When they don't get the outcomes they expected, they're confused about why they aren't getting all the great benefits they heard about.

And I just wonder: Like, why are you at all surprised?

When you ignore intentional constraints, the system breaks down in some appreciable way. The reason those constraints are put in place in each of those systems is to help the team get to outcomes in the way they want. The constraints are intentional.

I'm not saying that people should adopt frameworks and treat them as immutable. I think people should change their systems to work in their context. They should seek understanding about constraints they have in their teams and companies, and then adapt to that. Then they should add on constraints to help them get to outcomes in the ways they value.

If you're going to change a system away from it's design, you need to take a look at the impact across the system, across it's whole design to understand the impacts due to the changes. By using system thinking, we can understand the impact of the changes

When a team decides to ignore WIP limits, they should do so intentionally, knowing that they are going to create an unintended outcome they'll have to manage.

When a team decides to define more of their work up front, they need to accept that they may need to rework and redefine. They need to accept that they are introducing potential waste into the system.

When a team chooses to not have everyone on the same team dedicated to that work, they need to accept the fact that they're going to have to do more coordination with the multiple teams that need to be included to deliver the solution, and they're going to have to work with all of the individual schedules for those who need to be involved.

If you are going to break a constraint, do it intentionally and understand the impact of ignoring the constraint and account for it.