Unless you’re living under a rock, not reading your email, and not using the internet, you’ve no doubt encountered one or more of the following phrases:
Without more context, it’s easy for all these phrases to sound like buzzwords for some fads. You might just assume that all this is code for “making people work faster without paying them more.” The reality is that business agility isn’t about doing more or faster work, it’s about doing the right work. Done well, it brings a huge range of benefits from lower costs and higher productivity to better mental health for employees.
Business agility is an alternative approach to managing organizations, the teams within them, and the people who make up those teams. It emphasizes frequent delivery of value to customers and stakeholders through the use of iterative workflows, visualization techniques, and more rapid planning cycles.
Agile businesses are centered around adapting and solving problems instead of accepting and optimizing the stable, rigid hierarchies of the last century. They understand that no process or solution will produce stable returns indefinitely, so continuous improvement is always going to be essential.
The only true constant is change, so businesses need to optimize how they change. This is why business agility is not just another management fad but a reimagining of how organizations function.
Agility and Agile ways of working are often used interchangeably with business agility, and sometimes the terms are synonymous. Other times “agile” and “agility” are used to simply mean fast or adaptive. To avoid any confusion, we’ll be using the phrase “business agility” in the rest of this article.
Clarity of definition is nice, but being able to answer what business agility means is only one tiny step on a much larger learning journey. Agile is showing up everywhere because it’s rapidly becoming the must-have operating model for any and all successful businesses.
From scrappy startups to huge enterprises in highly regulated industries, agility is proving itself to be the only way to handle growing levels of complexity in the world around us while also innovating at the speed of customer expectations.
As the famous Agile thinker Steve Denning has said, Agile is eating the world.
It’s vital for anyone who wants to live in that world to understand what business agility means in both theory and practice, and how its feeding frenzy is going to affect their professional journey. Read on to learn how you can parse this unstoppable evolution, as well as start integrating it into your working life and get ahead of the curve.
One thing about Agile is that it pushes us to rely more on data to determine what works. So it’s only natural to do the same when looking at business agility as a whole.
The Business Agility Institute’s 2023 report found that many metrics around business Agility declined slightly for the first time in 5 years, likely reflecting both the growing maturity of the space and increasing conservatism after the dynamism which followed the Covid-19 pandemic.
But the overall benefits of properly executed business agility remain strong. A survey by McKinsey found that organizations usually experienced 30% gains in efficiency after a successful Agile transformation. That same report found staggering improvements in performance across a wide range of metrics.
While I could probably get away with just writing “COVID-19” here and moving on, giving sole credit to the pandemic for growing Agile adoption glosses over the years, actually decades, of agility making its way into businesses everywhere.
Agile got its start in software development, where new efforts to build products that were 100% digital, massively complicated, and had never been created before were wreaking havoc on traditional project management. Software releases were years late, millions of dollars over budget, and leaving a trail of exhausted developers and unhappy customers in their wake.
Clearly, a change was needed.
A handful of people got together and identified the shared characteristics across the few software development projects that had worked. They codified those commonalities into the original Agile manifesto, and set about evangelizing these new ways of working to their colleagues.
Agile percolated happily in software development and IT for a number of years. But eventually, other parts of the business started experiencing the same problems that developers had.
Marketing in particular began to struggle with traditional project management as it rapidly adopted digital channels and tools to reach more digitally savvy customers. This function was one of the first to wholeheartedly embrace Agile, as we’ve chronicled on this blog for years.
Now other functions, sales, human resources, and finance chief among them, are following suit.
As more and more pieces of the business are driven to adopt Agile, it only makes sense for more holistic, overarching approaches to step in and provide an operating model that will work for everyone. And so, business agility has started to emerge.
But within that larger arc, there are common pain points that trigger adoption in specific functions and/or across the organization.
While there are always nuances to the reasons behind a change, here are some of the most common things that drive business agility adoption:
Whether you see your business agility driver in the list above or not, it’s vital that you, your team, leaders, and entire organization understand the core “why” behind any business agility transformation.
If you ask people the reason they’re going Agile, and they use some variation of the word “agile” in their reply, you might have a problem.
Business agility represents a systematic change in how people work, and it’s not an easy change to make.
In other words, it’s not implemented just for fun and the transformation process itself shouldn’t be taken lightly.
So going Agile just to say you’re using business agility, or, even worse, because the CEO said you have to, is not a great place to start. Make sure everyone can articulate the real why behind an Agile transformation so they’re all excited about the journey to business agility, and the route they’ll be taking to get there. For example, by tying your transition to one of the drivers mentioned above.
While identifying your real why, you can check out our Agile Business Quick Start Guide.
As business agility makes its way into your part of the organization, you’ll likely start to hear new and unfamiliar words. Here are a few that you’ll need to get comfortable using right away:
(You can check out this glossary for some of the most commonly used within Agile marketing for a more extensive list.)
While some of the terminology above will be consistent across the entire organization, there are a few that will need to evolve to make them more applicable. Many Agile terms got their start within Agile software teams, and therefore need some adjusting. Nowhere is that more true than when it comes to the roles that make up Agile teams.
Here are some roles that you’re likely to encounter within business agility, including both their original names, and how you might want to adapt them for more universal applications.
The concept of teams in an Agile environment is different from how we typically think of that kind of a group. Agile teams stay together for long periods of time (ideally more than a year, but at least six months), and join forces to deliver against shared goals and objectives.
While many organizations bring teams together around projects and then disband them when that project is over, business agility calls for different ways of structuring teams.
We’ll get into those alternative models in the next section, but first let’s make sure we’re on the same page about how an Agile team is defined:
Self-organizing: Business owners define what’s important, but the team then organizes itself to find the most effective way to get top priority work done. Agile team members need to be able to effectively collaborate to be effective.
Proactive: Nobody should be sitting around waiting to be told what to do. An Agile team has a clearly prioritized backlog that shows them their priorities. A good Agile teammate seeks out their next high-value piece of work.
Team-oriented: An Agile team succeeds or fails as a unit. Its members can’t sit back and watch their teammates struggle just because they’re done with their part of the work. Even if it’s “not their job” or outside their comfort zone, team members need to work toward group success.
Empowered decision makers: Leaders need to remove themselves from being decision-making bottlenecks by pushing decision making to the teams whenever it’s safe and feasible. Some people who have worked in a traditional command and control culture can struggle to make decisions on their own; so leaders may need to coach them along, and praise them when they succeed.
Cross-functional: Teams should, whenever possible, contain all the skills needed to execute the work in their backlog without relying on another team. Also in an ideal world the team members themselves would feel comfortable stepping in to help a teammate with their work. These are two different versions of cross-functionality, but having both of them on a team is like rocket fuel. Because hand-offs and blockages that tend to waste time are eliminated.
One of the most common questions I hear about business agility is about what managers are supposed to do in these flatter structures. While at first glance you might assume that managers are obsolete when flat cross-functional teams are out there organizing themselves, but the reality is far from that.
Instead, Agile management is about acting as key bridges between high-level strategy and low-level execution. They often also take on several of the Agile roles mentioned above, acting as Agile leads or product owners. In other cases, they may get training and experience to become Agile champions within the organization.
Instead, managers in Agile businesses act as key bridges between high-level strategy and low-level execution. They often also take on several of the Agile roles mentioned above, acting as Agile leads or product owners. In other cases, they may get training and experience to become Agile champions within the organization.
There’s no single right answer, but Agile has plenty of vital roles for managers.
Now that we’re clear on what an Agile team really is, let’s consider some ways we might recombine people to meet this definition.
Remember, the goal of all the changes we adopt during a business agility transformation is to deliver more value to customers faster, so keep that in mind as you evaluate these options. Try not to pick the one that seems easiest, or the one that makes the most sense based on your current org structure, but rather the one that is likely to get more value out the door sooner.
You can think of a value stream as the path that something valuable needs to take through your organization to reach an end customer. Value streams cross many different departments and functions, and require lots of disparate areas of expertise to keep moving.
When business agility is adopted holistically across an organization, there’s the chance to align teams around these various value streams.
For instance, a bank might have a value stream focused on B2B banking clients. The needs of this customer base – the products they’re interested in, the legal and administrative support required, channels used to market to them, sales process, etc. – are unique.
The flow of value to a B2B client is very different from the flow of value to a small business, or to an individual consumer.
All three groups – B2B, small business, and consumer – might then have multiple Agile teams who come together to support their own value stream.
As you can imagine, this organizational principle requires bringing together a huge variety of skills, which can make it challenging to get right. It also requires clarity about what the different value streams are, and what parts of the organization they flow through.
For all these reasons, achieving business agility through value stream alignment from day one is unusual. Most transformations begin within functional departments using other organizational principles at the team level.
The first, and most effective, means of creating individual business agility teams is by adhering to the concept of cross-functionality. Not unlike the value stream approach, cross-functional teams bring together all of the necessary functions needed to deliver value of some kind.
The cross-department value stream just described would also be considered cross-functional, because it pulls people from multiple functional departments. At the team level, however, these functions are typically confined to a single department, such as marketing, software, or finance.
Cross-functional teams reduce reliance on other groups, cutting down on the silos, handoffs, and delays that plague many non-Agile organizations.
Keep in mind that not all cross-functional teams will be identical, and that not every team member will have identical skills. Since we want to bring teams together around shared goals and value delivery, we’ll be looking at what those goals and values are first, and then grouping together people who can meet those objectives by combining their skill sets.
Each department can create cross-functional teams first, and then move into a value stream model later on during the business agility journey.
Of course, there will inevitably be some functions that don’t fit nicely into a cross-functional model. Typically these are shared services teams, so called because their services are shared across multiple Agile execution teams.
Oftentimes these are groups whose members wouldn’t be able to spend 100% of their time working on a single cross-functional team. They might also be made up specialists whose skills aren’t widely distributed.
A sales department, for example, might only have two or three Salesforce administrators, not enough to put one on every single cross-functional Agile team. So the Salesforce team would be separate, and their backlog would be made up of incoming requests from the other teams.
Shared services teams are often a practical necessity during a move to business agility, but they should be approached with caution. Having too many of them, or relying too heavily on them without giving them adequate staffing, can recreate silos and not achieve any of the benefits you’d expect from Agile ways of working.
In rare cases, some functional departments within an Agile organization will need to maintain their traditional functional structure. There may not be enough people to build real Agile teams, the appetite for a reorg may not be there, or their leaders may believe they can maintain their structure while still adopting Agile processes.
Whatever the reason, don’t consider functional teams completely antithetical to business agility.
While unusual, it’s not impossible for functional teams to achieve real agility, and enjoy all the same benefits that a cross-functional Agile team would produce.
But, as with shared services, proceed carefully.
It’s easy to lean toward functional teams because they’re easy; that doesn’t mean they’re the right choice!
As business agility takes hold, there will inevitably be discussion about how much consistency is needed from team to team and department to department.
Does every Agile team need to look, act, and feel the same? How much leeway do different parts of the organization need to effectively adapt agility? How much customization is too much?
As with many choices that will be made on an Agile transformation journey, the answers to these questions will vary widely from one group to the next. Some general guidelines, however, are that all teams, functions, and individuals need to align around key components of agility.
Typically that means agreeing on the Agile values and principles that are most meaningful to your organization, and establishing a shared understanding of the core reasons for going Agile in the first place.
If we hold the same values and end goals for changing how we work, we should be able to make customized changes in service of those objectives.
And, whatever those core drivers are, chances are you’ll see some variability across the organization.
Teams that are service-oriented, meaning they provide support to lots of different parts of the organization, will implement Agile far differently than those who are more in control of their workstreams. In Agile speak, services teams will likely be more Kanban-style, while teams that are more self-contained can be more Scrum-like.
As long as all teams are aligned to the same set of core goals, embodying essential Agile values and principles, and consistently optimizing their processes via retros, don’t sweat it if their day-to-day versions of Agile aren’t identical.
Over multiple decades of striving towards greater agility, software developers and the coaches that support them have identified some common issues that derail business agility transformations. The top five barriers cited in the 17th Annual State of Agile Report are:
It can be easy to see the business-wide, systemic nature of these barriers and despair. How could we ever hope to overcome these massive challenges? Fortunately, there are a few key best practices that can help with many of these issues.
An organization-wide shift to business agility won’t happen overnight, but the writing is on the wall. No matter where you work or what you do, Agile will become a bigger part of what you do in the near future. So, to get you prepared, here are three things you can personally do now to start embedding the Agile mindset into your brain, while increasing your readiness to dive into your first Agile team when the time is right.
Your queue is a strictly prioritized list of all the work that you or your team plan to do within the next three months (you may have also heard it called a “backlog”). You get one top priority, and that’s it. The queue is there to force you to have difficult conversations when new work requests come in.
Is this new project really more important than the work we already have planned? If so, great. It will go at (or near) the top of the queue. If not, we put it lower down the list.
This system allows teams and individuals to take on new requests without needing to start
working on them instantly.
Regardless of the framework, they subscribe to or the tool they use to create it, nearly all Agile teams use a Kanban board to visualize what they’re doing.
By getting things out in the open this way, teams will be able to gain insight into how they’re really spending their time, reveal the bottlenecks in their process, and limit the amount of work being done.
Limiting work in progress (or WIP) is one of the most challenging things about being modern marketer.
The idea behind WIP limits is that they are clear rules that force us to stop starting and start finishing. Marketers are horribly prone to saying "yes" to everything, leading to dozens of projects in progress at the same time. But when we succumb to this temptation everything that we’re working on ends up taking longer.
In case you still have some unanswered questions about business agility, here are a few of the most common questions we hear.
While Agile did get its start in IT, it has since expanded to marketing, sales, procurement, and business as a whole. Each of these functions has its own take on Agility, but what ties them together is the fundamental principles they all derive from.
So even though the approach to Agile might change, Agile teams should still be able to understand each other and work together across functions because they are using the same mindset and principles to guide their work.
We just mentioned how the thing that ties together all forms of Agility is the principles and mindset behind them. It should come as no surprise that this means the best way to start your journey into business agility is by understanding those principles and cultivating that mindset.
That usually means starting with coaching and training courses. If you’re in a larger organization, it’s usually a good idea to start with a pilot program instead of trying to roll out Agile to everyone all at once. This enables you to make mistakes, experiment, and quantify results on a small scale before using those hard-learned lessons to lead a larger transformation.
The first thing to point out here is that you’re never fully “done” with Agility. At its core, Agile is about continuous improvement, learning, and adaptation. Because the environment in which your business operates is never going to stop changing, you can’t either.
That said, you can and should track your progress with metrics, KPIs, and strategic goals. You can also use tools like the Business Agility Survey to see how you compare to standard benchmarks. So while your journey towards business agility should absolutely have goals in mind, avoid setting a firm end date that may lead to complacency and backsliding. True business agility is for life.
Regardless of what you sell, how you sell it, or who you sell it to, Agile ways of working are the best (and potentially only) way of remaining effective in the face of constant change and disruption.
In other words, business agility is the future of all ways of working, regardless of where you sit in an org chart today.
Taking the time to understand what Agile really means, and, even better, starting to bring into your own personal daily routine, will ensure that you’re ready when Agile transformation inevitably finds its way to your role.
To become even more prepared, we invite you to check out our online Business Agility Fundamentals course and obtain the necessary know-how to bring agility within reach across your organization.
Before you move on, don't forget to get your copy of the Agile Business Quick Start Guide.