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 organization can only be as Agile as it's 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 organization, 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 organization as a flow. Let’s take a software organization. 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 organizations 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 organization. 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 organization. But it goes beyond that as well. It goes into the very culture and structure of the organization. Is the organization 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 organization operates in the market. To put it another way, we are improving the outcomes for the entire organization, not just a single division.

The point is that there is always a constraint to your organizational 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 organization? Is it IT or software? You may not be doing capital “A” Agile perfectly, but is that really your constraining factor to agility? Let me know below.

-Evan (Singapore)

As always I speak only for myself and not my employer or clients. ‘Directing the Agile Organisation’ is published by IT Governance Publishing available on Amazon, at Book Depository, and all good bookshops. You can read more at my blog: http://theagiledirector.com