Domains of Business Agility

Article by Evan Leybourn on 25 May 2017      21 minutes read

A pragmatic model for the next generation of market-leading organisations

The text and images in this models are licensed under a Creative Commons Attribution ShareAlike license. You are free to share the material in any medium or format and adapt / build upo n the material for any purpose, even commercially.

The world is changing more rapidly than ever before and organisations of every size are struggling to remain relevant in the eyes of their customers. The simple fact that the average lifespan of a company has decreased by more than 50 years in the last century demonstrates that not all organisations are prepared for this new reality. It is only high-performing, adaptable and agile organisations that will leverage, lead and thrive in this ambiguous and unpredictable market. We call this business agility.

The problem with a statement like that is that there is no common definition of what business agility means. And that’s actually a good thing. In a dynamic and changing market trying to lock it down will defeat the very advantage it brings. Instead, I want you to start thinking of business agility as the common thread. An adaptable and sustainable narrative that binds & guides, rather than directs, us into the uncertain future.

Therefore, to understand business agility is to understand the Domains of Business Agility. A simple model consisting of 9 interacting domains across 3 dimensions and centered around the customer. Not a pyramid or matrix, but rather a model of agility where each of the domains in each of the dimensions are equal, necessary, interrelated, and dependent on each other. No single domain is “above” or more important than any of the others. Business agility only emerges when your organisation can “be” agile across all the domains across all facets of your organisation.

Business agility creates purpose-driven organisations. For most companies their Customer is their purpose, however in public sector or social-good organisations the definition of the Customer is much broader. Regardless of how it is defined, your Customer is at the heart of the model and shapes your organisation. Surrounding the Customer are the three dimensions: Work, Connections and Mindset:

1. The three domains under the Work Dimension govern how an agile organisation operates. From Technical Agility at the individual activity level, to Process Agility at the value stream level, and scaling to Enterprise Agility at the organisational level.
2. The Connections Dimension governs the relationships that form within and outside the organisation. Structural Agility that defines the relationships between individuals, teams & divisions, Leadership Agility that defines the relationship with authority and Market Agility that defines the relationship with our users and the wider market.
3. Finally, the Mindset Dimension is concerned with governing the key characteristics of an agile organisation; a Learning Mindset, a Collaboration Mindset and an Ownership Mindset.

Successful business agility requires all of the domains in this model to work in concert with each other. Organisations that are seeing diminishing returns from their current agile adoption, need to start looking at agility as a continuous and systemic evolution of culture, people and skills rather than specifically focusing on transforming one or two domains.

What you won’t see in this model is a method or framework like Scrum, Kanban, or Beyond Budgeting - though you will see where they fit and how they work in conjunction to build a high performing organisation. The purpose of this model is to show you what to strive for, rather than what to do.

So, let’s take a look at the domains and dimensions in more detail.

THE CUSTOMER

The heart of business agility is no less than the very reason we exist - our Customer.

Customer is a very broad term. Depending on the organisational context it could mean; a paying client for a private organisation, a citizen for a public sector organisation, or an abstraction (like “the environment” or “the community”) for a NPO (NonProfit Organization). In some contexts, your customer may be a separate division within your organisation. Although in this case you should always consider the total value stream and end customer, instead of just delivering to a division because of the way the reporting lines currently work. Regardless of who your customer is they all have one thing in common.They provide us with our purpose.

Too many organisations have forgotten that we aren’t in business to make money - we make a profit to continue to achieve our true purpose - to serve our customer. Think of your local doctor - most people don’t become doctors to make money. They become doctors to save lives. They make money in order to continue saving lives.

“Profit is like the air we breathe. We need air to live, but we don't live to breathe.” - Frederic Laloux

We have placed the Customer at the center of the model, not only because they are the reason we do what we do, but also because they have been invisible for so long. Look at your current org-chart. Where is the customer? Organisations have said for years that customer is their most important asset and yet they are nowhere to be seen.

Having the Customer at the center doesn’t mean that the customer is always right or that employees or shareholders aren’t important. And it’s always remains important that we make a profit. It means that almost everything that we do revolves around them. It means that they are the top of our organisation charts. It means that the work that we do, and the way that we work, is primarily for them.

WORK

The first three domains of business agility are part of the Work Dimension. These three domains operate in concert to define how an agile organisation works. From Technical Agility at the individual activity level, to Process Agility at the value stream level, and scaling to Enterprise Agility at the organisational level.

Technical Agility

The techniques for delivering work, regardless of function or subject matter, in an agile way.

For decades, agile teams have promoted strong Technical Agility as the keystone for “being” agile. The purpose being to increase quality & throughput and at the same time embracing uncertainty & change. Many of the agile methods developed over the last 20 years, such as Extreme Programming (XP), Behaviour Driven Development, Test-Driven Development, and DevOps, are almost entirely devoted to Technical Agility. And Technical Agility isn’t limited to just software either. Any domain of work can be technically agile - for example, we’re starting to see agility emerge in marketing and finance work with their own agile practices (e.g. Agile Marketing or Beyond Budgeting).

To be technically agile, any work practice or technique needs to be designed for ambiguity, be customer centric, seamlessly respond to change, and promote collaboration. To benefit from Technical Agility, your organisation requires the other 8 domains, but these techniques & practices are generally a good place to start.

Process Agility

The form of agility that encompases an individual value stream - the combination of discrete activities that are undertaken by teams and projects.

This is the form of agility that most people think of when they hear the term. Agile frameworks and methods to encompass multi-step, and potentially multi-team, value streams; from traditionally agile processes like software delivery or project management to business processes such as marketing campaigns, annual budgets or home loan processing. Methods such as Scrum, Kanban Method, SAFe, LeSS, Disciplined Agile, or Lean Six Sigma are all, in large part, operating at this level (although it’s true to say that many of the more complex methods operate in the Enterprise Agility domain as well).

One key element of Process Agility is the focus on outcomes and products over outputs and projects. The governance of all decisions, processes and work, is directed towards ensuring the continuous delivery of value and business outcomes. This relationship could be described thus: work needs to be justified based on the value it could deliver to the organisation in the context of a business outcome. In many cases, this enables the accountability for all decisions relating to the work to be entirely owned by the team.

Enterprise Agility

Scaling agility across divisions, departments, the organisation and ultimately between organisations.

We are only now starting to think about Enterprise Agility as a discrete domain. Over the last 20 years, as individual teams became agile, the constraining factor for agility to scale was the other teams within the division. Now, as entire divisions and departments scale to become agile, the constraining factor for agility is the rest of the organisation.

"An organisation can only be as agile as it's least agile division!" - Evan Leybourn, Evan’s Theory of Agile Constraints

Enterprise Agility emerges when there is an agile way of working across multiple teams and divisions. From a systems perspective, it can help to think of work in your organisation as a flow. We have a pipeline of demand on one side and delivery to our users on the other. Somewhere along this flow is the next limiting constraint to business agility. 20 years ago, that was IT and the software teams. Which is why it was logical for Agile to emerge in that domain. But now there are new constraints that require a wider view. It differs across organisations but I have generally found that the PMO, HR, sales or finance departments are the next teams that need to be agile. In most organisations, we have an 18 month budgeting process limiting a development cycle that can deploy every day.

These are not easy problems to solve. You need to help these divisions internalise an agile mindset and culture as well as providing appropriate Technical Agility practices aligned to their work context. This is key to achieving Enterprise Agility and ultimately true business agility.

CONNECTIONS

The next three domains of business agility are part of the Connections Dimension and govern the relationships that form both within and outside the organisation. From Structural Agility that defines the relationships between individuals, teams & divisions, to Leadership Agility that defines the relationship with authority and Market Agility that defines the relationship with the users and the wider market.

These three domains cut across the previous dimension and so, to be successful, you require elements of Structural, Market and Leadership Agility inside each of Technical, Process and the Enterprise Agility.

Structural Agility

The relationships between individuals, teams & divisions to create an agile organisation.

The simple pyramid hierarchy no longer serves us. Laloux’s Teal Organisation and Steve Denning’s three laws (law of the small team, network and customer) come into play across this domain. Practices such as Systems Thinking and the Theory of Constraints (including Evan’s Theory of Agile Constraints) are necessary here. At the lowest level of the organisation you might call these teams, squads or cells. A traditional agilist might call these cross-functional and multidisciplinary teams.

Regardless of what they are called, agile teams have certain common characteristics. In general, they are small, cross-functional, and formed around business outcomes rather than traditional, skill-based, functions. To be successful, team members need to have the “four A’s”: Alignment, Autonomy, Authority, and Accountability. Agile teams in mature organisations are self-organising and have total authority to identify their own membership and decide on the work to be done to achieve the given outcome. This demands a high-level of collaboration within the team and, where appropriate, ultimately develops strong multidisciplinary members.

The connection between teams is the fundamental expression of the organisations’ structure and an indicator of business agility fluency. These connections may form a hierarchical model (sometimes called tribes) or a flatter, network, model where connections form dynamically to align along the value stream. In either case, these connections group teams to business outcomes rather than functions. Mature agile organisations break down the divisional walls even further. For example, by bringing sales & marketing, finance or operations into the relevant cross-functional teams when needed. Guilds or centers of excellence are formed around uncommon skills (such as architects, infrastructure or coaches) to share this expertise where and when needed.

Leadership Agility

The relationship with between individuals and authority within an agile organisation.

Start thinking of everyone in the organisation as a leader. Whether they have institutional authority or not. Leadership models such as Servant Leadership or “leading from the middle” are part of this. While there are similarities, there is a substantial difference from traditional management as we expect the team (including the Product Owner if applicable) to decide and self-correct their own “what”. Agile leaders require the ability to inspire purpose, set direction, align teams to business outcomes, remove impediments, and coach & mentor teams.

At the pioneering end of business agility and, in particular, Leadership Agility, there is the concept of self-organisation - teams or divisions with no managers. Though this requires a significant level of fluency across all business agility domains, self-organisation take the position that, as Drucker puts it: “every man sees himself as a ‘manager’ and accepts for himself the full burden of what is basically managerial responsibility: responsibility for his own job and work group, for his contribution to the performance and results of the entire organization, and for the social tasks of the work community.” Without managers, self-organising teams remain aligned to company strategy and expectations by being accountable for specific, and measurable, business outcomes.

Finally, don’t forget that it is agile leaders (who may not be managers) who orchestrate and guide the organisation towards business agility. Leaders who help align the organisation to a single purpose, enabling individuals and teams and taking corrective action where needed.

Market Agility

The relationship between the organisation and the marketplace.

Organisations have always needed to earn the right to exist in the market. However, as both market predictability and the barrier to entry is decreasing, we are now seeing that incumbents no longer enjoy the same commercial advantage as they used to. It is agile organisations, those that frequently inspect, adapt and pivot to meet opportunities, that are more likely to flourish in this ambiguous and uncertain market. Speed and effectiveness of this adaption to competitors, disruptors and new customer demands are key measures of Market Agility.

Once we include the connection to the market in the wider systemic perspective of business agility, our view of the product lifecycle extends to include the entire value chain - from your suppliers upstream to your distributors downstream. The partnerships that this systemic perspective grants enables the creation of superior offerings that delight your customers. Methods and frameworks like Lean Startup, Lean Enterprise, and Design Thinking as well as many of the traditional agile practices fall under this domain.

MINDSET

The third and final dimension is concerned with addressing the cultural domains. These are the key characteristics of an agile organisation; a Learning Mindset, a Collaboration Mindset and an Ownership Mindset.

Learning Mindset

Organisations that experiment, learn faster than others are those that succeed.

Agile organisations are fundamentally learning organisations at all levels; whether small & specific (e.g. this feature didn’t sell well, so let’s change it) or large & systemic (we need to change our governance model based on this new information). Learning is more than just observing. It’s taking the observations, determining its worth, then internalising & making it the new reality for the organisation.

The application of a Learning Mindset results in continuous improvement. Feedback loops, such as “inspect and adapt”, and practices, such as the retrospective, enable teams, divisions and organisations to improve both what they do and (more importantly) how they do it. Like the woodcutter who refuses to sharpen his axe because he has too many trees to cut down, organisations that do not improve both the way they work and their products themselves will ultimately be out-competed in the market.

Central to the Learning Mindset is the ability to experiment, fail fast (with a small “blast radius”) and recover faster. Failure should not be seen as making a mistake, but rather as an opportunity to learn. Organisations can make is “safe to fail” by recognising that failure is part of daily work and not something you blame or judge people for. Some organisations go further by introducing formal or informal support mechanisms like Failure KPI’s, parallel experiments (and selecting the highest performing option) or simply providing an environment where failure is easily identified, recognised and rewarded.

Collaboration Mindset

A culture of collaboration underpinned by communication and transparency across individuals, teams, divisions and organisations.

An agile organisation is one that is designed to collaborate. The very construct of the organisation - from the organisational structure, to the work processes and even the way the market is engaged - promotes collaboration and cooperation.

The complexity of collaboration is one of the fundamental reasons teams in an agile organisation are kept small. O(n2) [read: order n squared] to be precise. 7±2 is a commonly accepted size. Decision making is localised to reduce the lines of communication and subsequent delays incurred. However, don’t let the goal of collaboration impact your ability to be productive. Sitting in meetings and talking is not collaboration whereas sitting quietly in a room by yourself can be.

Critical to effective collaboration is transparency of information, decisions, and relationships by default to provide a solid grounding for trust & respect between customers, peers and leaders. All individuals have the ability to know what is going on so that they can make appropriate decisions. This doesn’t mean that everyone knows everything but that individuals have the choice of knowing anything. And, of course, the ability to be opaque to the competition while being transparent internally is the real art of a Collaboration Mindset.

There are many tools and practices that you can adopt to improve how your teams collaborate. For example, social contracts, pair programming (or pair work outside IT), and visualisation tools (like Kanban Boards, Burndown Charts or Cumulative Flow Diagrams).

Ownership Mindset

Individuals and teams taking pride and accountability in their work.

An Ownership Mindset means, as an individual or team, taking accountability for the quality and success of both the output and outcomes of your work. Both of these are important as ownership doesn’t mean perfection. It means knowing why you are doing the work (the outcome) and making sure that what you produce (the output) is fit-for-purpose. It means understanding, learning, and challenging rather than following instructions.

Teams who own their work generally take pride in what they produce. However, being agile means to take pride without arrogance. Ownership means being willing to collaborate with other; to learn from them, ask for help, even potentially reverse engineering their work, to achieve the outcome.

An Ownership Mindset isn’t unidirectional. Individuals and teams need to be given the authority, as well as the accountability, for an outcome. Organisations and leaders need to be transparent about the strategic decisions that are being made. For an individual or team to be held accountable for their decisions they need to have the appropriate information so as to not make a predictably incorrect decision. This has specific implications in publicly traded organisations relating to insider trading regulations (e.g. knowledge of share price triggers) but many organisation have solved this conundrum.

The Agile Manifesto

If, and until such time as, there is a Business Agility manifesto, the values and principles of the Agile Manifesto apply across all areas of the organisation with one minor modification.

We are uncovering better ways of delivering value by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
[Value creation] over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Practices, Methods and Frameworks

Across all domains of business agility, “doing” agile (using the practices and methods) and “being” agile (the expression of an agile mindset) are intertwined. You need both to be successful and either on their own will lead to failure. So we’ll take a moment to look at “doing” agile in a business agility context. Luckily agile has been around for quite a while so there are hundreds of practices, methods and frameworks for you to choose from.

While developing this model, I ran an open survey to determine the focus of many of the popular agile frameworks, methods, techniques and systems. While this is by no means a complete or comprehensive list, based on the results, I’ve mapped some of these against the domains as either a major or minor focus.

Frameworks

Scrum: Major: Process & Learning Minor: Leadership & Ownership

SAFe & LeSS: Major: Process Minor: Enterprise, Structural, Learning, Collaboration & Ownership

Disciplined Agile: Minor: Enterprise, Process, Technical & Learning

Cynefin: Minor: Leadership & Learning

Methods

Kanban Method: Major: Process & Collaboration Minor: Enterprise, Structural, Market & Learning

Theory of Constraints: Major: Process Minor: Enterprise & Learning

Lean Six Sigma: Minor: Process & Learning

Extreme Programming: Major: Technical Minor: Process, Learning & Collaboration

Techniques

Lean Startup: Major: Market & Learning Minor: Enterprise, Collaboration & Ownership

Pair Programming: Major: Technical Minor: Learning & Collaboration

Retrospectives: Major: Learning Minor: Process & Collaboration

Servant Leadership: Major: Leadership & Ownership Minor:Learning

Systems

Beyond Budgeting: Major: Enterprise Minor: Process & Technical

Holacracy: Major: Leadership & Structural Minor: Enterprise, Learning, Collaboration & Ownership

Laloux's Teal Organisations: Major: Structural Minor: Enterprise, Leadership, Learning, Collaboration & Ownership

Learning Organisations & Double Loop Learning: Major: Learning Minor: Collaboration

When selecting complementary frameworks and practices, try to avoid those that major in the same domain. With the exception of those in Technical Agility, overlapping frameworks tend to conflict rather than compliment.

Business agility remains an emerging model, so there isn’t the same level of formal practices and frameworks that you find in other domains. Beyond Budgeting, Holacracy, and Servant Leadership are probably three of the most recognisable concepts. It is my belief that over the next 5-10 years we’ll see an explosion, then consolidation, of business agility frameworks and methods addressing these domains.

The Journey

Keep in mind the purpose of this model - to guide you along your business agility journey without being prescriptive as to “how”. This means that your business strategy needs to align to all nine domains and that the practices, frameworks and values of your organisation must address the systemic nature of agility.

While the journey never ends, the first step is to understand “why”. What defines your company and it’s purpose? In many ways, this will define the way you work together, cooperate and create value for your customers. At every point along this journey, each domain will have a different level of fluency. Focus on those which are currently the most constraining or disruptive to your overall business agility.

And it’s not an easy journey. The systemic nature of transitioning to business agility can have a profound impact on individuals. Across the entire organisation there must be inspiring leadership, clear communication and a common purpose to create champions out of everyone. And there will be people in your organisation who do not wish to work in this way and will leave. There’s no value judgement in this, simply needing a different way to work. Respect and understanding must be shown to everyone, even those leaving.

However, despite the complexity of the transition, the benefits to business agility are manifest. Starting with the ability to rapidly respond to competitive challenges, disruption and changes in demand. In fact, an agile organisation can do more than just respond, you can be the challenger and disrupter in an uncertain and unpredictable market. Staff satisfaction and retention is higher and, with a general reduction in management overheads, operating costs are lower. Finally, because agile organisations are purpose driven, you are able to be more responsive to your customers or wider purpose.

Final Thoughts

These nine domains and their common characteristics are the key to business agility. None of these are more important than another. Rather they are complementary and mutually necessary in order to achieve agility. There is a natural progression over time - as organisations move from less agile to more agile - where focus will be on specific domains to address specific demands or issues. However, mature agile organisations are ones where all nine domains are present.

Acknowledgements

This has been a joint effort by numerous Business Agility practitioners and experts around the world. I’d like to take the time to thank AfriKA M. Ndoto, Andrew Boyd, Asshok Singh, Ben Hogan, Boryana Manolova, Chris Chan, Chris Edwards, Dan Chesterman, David Luke, Dawna Jones, Derek Winter, Diego Espejo, Drew P., Ewan O’Leary, Frederic Ducros, Gopal Katragadda, Hamish Taylor, Harry Nieboer‏, Henrico Dolfing, Jeff Kosciejew‏, Jeremy Pullen, Johan Tuulse, Kashif Heyat, Krishna Kumar, Larry Cooper, Malcolm Anderson‏, Marc-Andre Langlais, Marcelo Espejo, Mia Horrigan, Mitul Ghosh, Nat Tanner, Nick Argall, Peta Guy, Pete Morris, Scott Ambler, Sebastian Voss, Sergey Rogachev, Shane Hastie, ShriKant Vashishtha, Sofia Woloschin, Stelio Verzera, Steve Pruneau, Steve Tendon, Steven Mak, Sunish Chabba, Tahlia Oliver, and Thomas Walenta.

I’d like to especially thank Bret Nelson, Helen Snitkovsky and Renee Troughton for taking my calls at odd hours of the night and Yura Malishenko for his amazing visual design.