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:
- Agility
- Agile ways of working
- Business agility
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.
What Is Business Agility?
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.
Business Agility vs Agile
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.
Important Business Agility Statistics
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.
Why Businesses Are Racing to Adopt Agile Ways of Working
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 Migrates Outside of Software
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.
5 Common Drivers to Business Agility
While there are always nuances to the reasons behind a change, here are some of the most common things that drive business agility adoption:
- Work takes too long: Customers and audiences have become accustomed to instant gratification. If you’re measuring your delivery times in months, quarters, or years, you’ll become irrelevant to those customers and audiences very soon. Root causes for slow delivery times can almost always be traced back to inefficient processes in multiple parts of the business. Even if each function is only a little slow, maybe missing their deadline by a couple of weeks, by the time a major initiative has made its way across the entire business those couple of weeks have added months, quarters, or years from the customers’ perspective. Business agility increases speed and reduces inefficiencies, so it’s the perfect solution for this challenge.
- Silos are everywhere. Rework abounds, revision cycles are rampant, and everybody points fingers at everybody else when there are issues. If this sounds familiar, chances are silos are to blame. Silos are invisible walls within an organization that keep people from working together effectively. They might be invisible, but they’re still very real, and create very serious problems. Silos negatively impact work quality, process efficiency, innovation, collaboration, and employee engagement. Business agility’s focus on cross-functional teams with end-to-end responsibility for value delivery is the antidote, and may be driving adoption.
- Same work, different day. This might mean there are no new ideas, or that new ideas are routinely squashed, because “it won’t work here”. With an iron grip on traditional approaches, there’s a growing sense of danger of disruption in the industry.
- Churn, churn, churn. People across the organization are leaving because they’re burned out and/or frustrated that their hard work gets lost in bureaucratic red tape. With top-quality talent an increasing differentiator for organizations of all shapes and sizes, keeping the best people around is crucial to getting ahead.
- Customers come first. Customer experience must be at the heart of every organization, or they risk sliding into irrelevance. Not coincidentally, the first value articulated in the Agile manifesto calls out that all Agile ways of working are adopted to deliver more value to customers. Organizations that have fallen into counter-productive habits get fixated on their own issues, needs, and ideas; business agility helps refocus them on delivering value to the people who really matter.
Getting to Business Agility Begins with Knowing Your REAL Why
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.
Key Business Agility Terms
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:
- Daily standup or daily scrum:
- Kanban board:
- Retro, or retrospective:
- Backlog:
- Scrum:
- Ticket, user story, or work item:
(You can check out this glossary for some of the most commonly used within Agile marketing for a more extensive list.)
Business Agility Roles and Responsibilities
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.
- Scrum Master, also known as Agile Lead: Supports process improvement and obstacle removal while facilitating Agile meetings at a team level. Many organizations move away from the Scrum Master name because outside of software development many teams choose a hybrid approach rather than Scrum (more on this later). Referring to the person in charge of supporting teams in achieving agility, rather than just adopting Scrum, helps everyone feel comfortable choosing the flavor of Agile that’s right for them.
- Product Owner, also known as Business Owner: This role’s name also comes from Scrum and its emphasis on building software projects. So you can decide whether to keep the Product Owner label, or adjust it. Either way, this role is vital. This person owns the backlog for an Agile team. They must combine a strategic business perspective with a strong understanding of the team and its capabilities so they can set priorities, accept (or reject) incoming work requests, and generally ensure the team is doing the right work at the right time.
- Business Agility Transformation Office (BATO): A cross-functional leadership group that’s responsible for moving strategy, structure, processes, people, and technology towards the business agility operating model. They define why Agile is crucial for the organization, articulate the goals of a transformation, and help create the processes and structures needed to reach those goals. Members of the BATO are internal, but should be supported by external experts with transformation experience to ensure the smoothest possible adoption of Agile across the organization.
- Agile Coach: Some members of the BATO may be Agile coaches. They have experience working across multiple Agile teams, and are responsible for creating and improving Agile processes. Coaches support people all across the org chart, from individuals to teams to leaders to executives, in adopting the Agile mindset and executing the practices well.
- Agile Team, or Agile Execution Team: These are the people who actually sit down and get work done in an Agile system. Some organizations refer to them as squads to help differentiate them from previous notions of what a team means, but the name is less important than how they work. There’s no hierarchy within the team, which is ideally very cross-functional, meaning it contains the skills needed to complete the work it commits to without being dependent on other teams. Agile teams stay together for long periods of time, and work 100% of their time together using Agile practices and frameworks.
How Teams Change Within Business Agility
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.
The Role of Managers in Business Agility
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.
Alternative Team Structures to Support Agile Ways of Working
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.
Business Agility Through Value Stream Teams
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.
Multiple Cross-Functional Teams
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.
Including Shared Services
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.
Keeping Functional Teams Alive
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!
Agile Frameworks Across the Organization
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.
Common Barriers to Agile Adoption
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:
- General organizational resistance to change
- Not enough leadership participation
- Inadequate management support and sponsorship
- Business teams not understanding what Agile does and/or can do
- Insufficient training and/or education
Overcoming Common Barriers to Business Agility
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.
- Agree on and reinforce your why(s). Don’t let ambiguity about why Agile transformation is underway undermine consensus. Identify the goals, set up KPIs that will tell you if you’re on track, and make sure all teams and departments are driving in these directions. Remember, business agility for its own sake shouldn’t be the reason for these fundamental changes. Agile transformation should solve big problems, otherwise it’s not worth the effort.
- Establish a BATO (Business Agility Transformation Office) to own the transformation. When a core group of senior leaders has responsibility and accountability for executing an Agile transformation, it exponentially increases the changes of a successful shift. Few things endanger change more than having a few people try to manage in a couple of spare hours every week. Get together a group that has enough experience and initiative to drive the transformation to completion, and dedicate a big chunk of their work week to that effort.
- Assess current culture and identify areas for improvement. There are lots of ways to pinpoint the type of culture your organization currently has; maybe you have existing data, or maybe you need a formal assessment. Either way, make sure you have a data-driven understanding of where you’re starting so you can effectively track your progress to moving into a more Agile-friendly cultural mode if needed. The trouble with culture is that many of us assume it’s a nebulous, immeasurable quality. That makes it hard to track, and that gap will become dangerous if culture is undermining successful Agile adoption. Measure where you are, map where you want to go, and systematically track your progress from point A to point B.
- Create reference models to clarify acceptable levels of variance for processes and practices. While not every Agile team across the organization will look and act the same, it can be useful to set up a reference model, or blueprint, for must-haves for Agile teams at your organization. Everyone needs to check a few boxes to establish some team-to-team and department-to-department consistency, without forcing unique teams to conform to arbitrary standards of agility. This can be particularly important if software and/or IT are already Agile. Non-technical teams will use Agile quite differently, and that difference should be embraced and acknowledged from the start, without allowing those differences to decrease the effectiveness of business agility overall.
How to Embrace Business Agility in Your Own Daily Work
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.
Build a Queue
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.
Visualize the Work
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.
Limit Work in Progress
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.
Business Agility FAQs
In case you still have some unanswered questions about business agility, here are a few of the most common questions we hear.
Is Business Agility the Same as IT Agility?
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.
What’s the Best Way to Get Started in Business Agility?
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.
How Do I Know We’ve Successfully Achieved Business Agility?
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.
Business Agility is the Future of Business
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.
Topics discussed
Improve your Marketing Ops every week
Subscribe to our blog to get insights sent directly to your inbox.
