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 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 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 unpredicatable 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 sofware 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.
Hi Evan,
Like George Box said: “All models are wrong, but some are useful”. IMHO your models are useful but an over simplification of reality in a large organization. As I remember TOC is about adding capacity to a constraint (in your case above, adding extra teams), but often it’s not all about capacity. One other thing that certainly applies is capability, sometimes maybe just within a single team. That’s why I am such a fan of feature teams (in a IT-oriented organization) rather than component teams. Component teams are dependant on each other, feature teams can deliver (if done right) from cradle-to-the-grave. Also what’s missing in the model above is all layers of management in the org chart who steer with KPI’s top-down instead of getting out of the way and optimize the flow from left to right. Last but not least, the flow can differ for each value stream in an organization. Otherwise very useful models 🙂 Cheers Tom.
ToC isn’t just about adding capacity. It’s about removing or optimising the constraint. In some cases thats capacity, but you don’t make finance more agile by adding more accountants. You do that by enabling agility in the budgeting process.
I’m with Evan on this – I’ve explicitly applied the five focusing steps to organizational agility a number of times. I’ve found it comes into its own in two areas especially:
1) Identifying the impact of cross-value-stream friction-reducing activities, such as updating job architectures, clarifying portfolio models, or cleaning up compensation models. Here, we use the exploit and subordinate steps to create the safety for the groups to elevate their own capabilities, either by adding capacity or improving how they work.
2) Addressing up-stream and down-stream constraints outside of what agile/devops generally address, such as funding/portfolio decisions, business implementation post-deployment (not everybody’s a SaaS platform!), etc. These areas generally benefit quite effectively from a lean lens (or a more pure Kanban Method application).
Evan, thanks for posting this (2 months later), I’ll definitely be pointing people at it.
That’s where we agree (it’s not all about capacity), but you don’t adress the role of management in your response and the differences between value streams 🙂
See also http://theagiledirector.com/article/2017/04/27/evans-theory-of-agile-constraints/ for some interesting comments