Evan's Theory of Agile Constraints

When it comes to conveying why business agility is important, and with apologies to Eliyahu Goldratt, I often talk about "Evan's Theory of Agile Constraints".

"An organisation can only be as agile as its least agile division!"

Very basically, the Theory of Constraints is that there is a constraining factor in any process. More importantly, that there will *always* be a constraining factor. The Theory of Agile Constraints is that, in an organisation, there will *always* be a constraint to business agility. 20 years ago, that was IT. That was your software team. And that's why it was logical for Agile, capital "A" Agile, to emerge in that domain. Today the constraint to agility isn't IT, but rather it's the PMO, HR, finance, or legal department.

It can help to think of work in an organisation as a flow. Let's take a software organisation. We have user or business demand on one side and the production environment on the other. Somewhere along this flow is the limiting constraint. Maybe it's taking too long for our developers to deliver products. So we introduce Scrum.

That opens up the flow in our development teams. Great. Except that Agile hasn't been as effective as we hoped. It's still taking too long. The sad fact is that many organisations stop here and say "well Agile didn't work", but fail to look at the next constraint in the system. Maybe now it's deployment. So let's bring in DevOps. Great - that opens up the flow further.

But now there's a new constraint. We need a wider view. We need to bring in business agility. Where's the next constraint? Maybe it's Finance, our budgeting process. We have an 18 month budgeting process limiting a development cycle that can deploy every day. Fix that. Then it's HR or the PMO.

In today's economy, these are the areas that are constraining the agility of an organisation. In many ways, this is the definition of business agility. Taking the mindset of agility, and the practice of Agile, and applying it across the organisation. But it goes beyond that as well. It goes into the very culture and structure of the organisation. Is the organisation designed in such a way to be competitive in an ambiguous and unpredictable market?

These are not easy problems to solve. It's not just a matter of asking Finance and HR to adopt Scrum or Kanban (I don't think that's ever worked, even for software teams). These teams can introduce significant cultural and experience barriers. These are teams who look at their current ways of working and say; "we have always worked this way". And in many cases quite successfully. Therefore, if we want to introduce agility to these divisions, we need to communicate that this isn't about fixing a problem. We're fundamentally changing the way the organisation operates in the market. To put another way, we are improving the outcomes for the entire organisation, not just a single division.

The point is that there is always a constraint to your organisational agility which, in turn, limits your ability to adapt to an unpredictable and ambiguous market.

So, if there's always a limitation to how agile you can be, where is it in your organisations? Is it IT or software? You may not be doing capital "A" Agile perfectly, but is that really your constraining factor to agility?