Agility And Business Agility Are The Same
An opinion piece on how the distinction between Agility and Business Agility only distracts leaders from what they should actually be doing
You can also listen to this post in this episode of our podcast.
There is a growing trend in our industry to distinguish between “Agility” and “Business Agility”, or even “Enterprise Business Agility”. As one site puts it, “Business Agility is a much bigger conversation and looks at making the entire enterprise flexible & nimble, not simply implementing new processes into teams”. A look at Business Agility models yields a similar conclusion; in the frame of these models, Agile is something that is constrained to individual teams and isn’t complete enough. Many consultancy firms are now jumping into that gap with additional frameworks and models.
This makes no sense to me. I’d like to use this post to argue that this notion of “Business Agility on top of Agility” reveals a glaring misunderstanding of what it is we’re going for with Agile. More importantly, I think that the distinction between Agility and Business Agility only muddies the waters and distracts leaders away from what it is they should be doing.
“This notion of “Business Agility on top of Agility” reveals a glaring misunderstanding of what it is we’re going for with agile.”
A definition of Business Agility
Business Agility is generally defined as the capacity of an organization to rapidly respond to changes in the market, external and internal policies, and societal changes. It is effectively a survival strategy that allows organizations to survive in an ever-changing environment, and even thrive on that. And that’s great! It is also very much the same as how we would describe an organization that fully lives the principles of Agile. Another way to understand this is to place Agile in its historical context.
Rational and Organic Strategies
If you would remove all the business lingo for a moment, the purpose of Agile is to encourage organizations to become more flexible by loosening the many constraints of planning, centralization, and standardization that work so well in environments where little ever changes. As a concept, Agile takes its place in a long line of similar management concepts that started emerging since the Second World War (e.g. Lean, Socio-Technical Systems) and is a direct response to the rational strategies that emerged during the Industrial Revolution.
Rational strategies are rational in the (economic) sense that they are based on creating stability through planning, objective reasoning, objective measurements, and predictable, causal models. At its core, planning, centralization, and standardization aim to stabilize how work happens in an organization. The purpose is to remove potential variations wherever possible because they can throw sand in the gears of the machine and harm quality, productivity, and efficiency. Rational strategies make sense in environments that are generally stable in terms of what is needed, or where flexibility is not an immediate asset. The metaphor that drives rational strategies is that of a machine. The ideal organization is one where the same process always happens the same way and produces the same outcomes given a certain set of inputs.
But since environments are increasingly more volatile, and because flexibility is therefore increasingly an asset over competitors, there has been a growing trend in management literature since the 1950s to use a more dynamic metaphor; the organization as an organism that constantly interacts with its environment and is continuously changed by it.
Where rational strategies turn attention inward to the processes and structures of the organization itself, organic strategies draw attention to what is happening in the environment and how organizations can benefit from that. In a very real sense, this outward focus is a survival strategy. If organizations don’t develop the skills to constantly change their structure and processes in response to changing environments, they will perish in the face of larger shifts in the markets, societies, and technologies. In the ecosystem of a globalized economy, organic strategies encourage organizations to adapt more quickly and therefore increase their chance of survival.
“In the ecosystem of a globalized economy, organic strategies encourage organizations to adapt more quickly and therefore increase their chance of survival.”
As a concept, Agile fits very well into this family of organic theories. Its four core principles emphasize what we just wrote: individuals and interactions over processes and tools (or: interaction over standardization), working software over comprehensive documentation (or: small steps over large plans), customer collaboration over contract negotiation (or: work closely with your environment over getting stuck in contracts) and responding to change over following a plan (or: change over stability).
So if the principles of Agile are very much intended to make organizations more responsive to their environments, where did this notion of “Business Agility” as the missing piece come from?
Agile is only about software?
It is true that Agile — at least as formalized in the Agile manifesto — started in the software industry. This is immediately apparent in the wording of its second principle (“working software”), its title (“Manifesto for Agile Software Development”), and its introduction (“We are uncovering better ways of developing software by doing it …”). But we don’t think it takes a giant stretch of the imagination to understand that “working software” is merely the vehicle by which organizations should discover and learn about their environment and what is relevant and what needs exist there. If you apply the Agile principles in other domains, you simply have to find what vehicle makes the most sense there.
At the same time, this focus on software does make sense when you consider that most modern organizations either deliver software products or rely on software products to drive their primary processes. It makes sense that information technology is one of the first domains where we discovered the consequences of complexity, and how no amount of planning, standardization, and centralization could reduce the risks stemming from that complexity. More importantly, by framing Agile as something that is intrinsically limited to software, “Business Agility” perpetuates the harmful myth that “business” and “IT” are somehow separate things. Isn’t it ironic that proponents of the notion of “Business Agility over Agility” are themselves guilty of perpetuating exactly what makes so many Agile adoptions fail?
“Isn’t it ironic that proponents of the notion of “Business Agility over Agility” are themselves guilty of perpetuating exactly what makes so many Agile adoptions fail?”
Agile is only about teams?
It is true that the Agile manifesto doesn’t mention organizations. But it doesn’t mention teams either. It merely sets out a number of principles that allow organizations (of any size) to respond more dynamically and organically to our environment. It is also true that many Agile frameworks seem to be primarily concerned with teams.
Proponents of “Business Agility over Agility” often argue that Agile is so preoccupied with teams that it leads to blindness to the larger system. This leads to quotes like: “We’ve implemented Agile for the teams. But now we’re working at an unsustainable pace. We’ve become feature factories with constantly shifting priorities and no clarity to the business value we produce”. While we recognize this observation and see it too, we also think that this is clearly not what Agile aims for.
There is an important reason why many Agile methodologies are so focused on teams. Since teams are creating the valuable products (or services) that are intended to serve relevant needs in the organization’s environment, they are bound to run into all the organizational impediments that make it hard to actually deliver that. For example, there may be a lack of clear goals to guide decision-making, rampant dependencies that make it hard to get anything done, the great distance between teams and their actual customers, or an organizational culture that isn’t conducive to empiricism. So yes, the system will get in the way and it will need to be changed.
What is important to take from this is that this means that teams provide transparency into what is keeping them back. This transparency is a great way to develop the organizational skills that allow organizations to adapt more quickly to their environment. If leaders take note of what is impeding teams — their “engines” of value creation — and give their unequivocal support to break through bureaucracy, hierarchy, and rigidity, their organizations will become increasingly adaptable and responsive.
“If leaders take note of what is impeding teams […] and give their unequivocal support to breakthrough bureaucracy, hierarchy, and rigidity, their organizations will become increasingly adaptable and responsive.”
Business Agility
And that brings us to the essence. I believe that many leaders and top managers have no idea what is going on in their teams. They either don’t support them or their support is merely lip service. From scientific research, we know that management support is critical to the success of Scrum Teams and Agile transformations, though often sorely lacking in practice. And that leaves many Agile teams stranded in the wasteland that “Business Agility” has capitalized on as a business opportunity for consultancy solutions.
But is the best solution to introduce new business lingo? Is it helpful to claim Agile transformations only change the teams into feature factories, but everything else remains the same, and to then conclude that something else — like Business Agility — is needed to fill that gap? Isn’t the whole distinction between Agility and Business Agility entirely semantical?
Why can’t it be as simple as: “Leaders: listen to your teams and actually help them overcome the impediments they run into creating value for your businesses?”. Anything else feels like consultant junk food to me. It looks tasty, but it distracts from what they should have been doing in the first place: listen to your teams and support them.
We created 5 do-it-yourself workshops and exercises to bring leaders and teams together to analyze and overcome shared impediments. You can get the facilitation guides in our webshop.
