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:
- Agile ways of working
- Business agility
If you’re concerned that one (or all) of these might just be code for “making people work faster without paying me more,” let me set the record straight.
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.
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 particular 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 enterprise behemoths, agility is 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.
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 a 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. Agile 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. Agile’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. No new ideas, or 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; Agile helps refocus them on delivering value to the people who really matter.
Know Your REAL Why
Whether you see your driver in the list above or not, it’s vital that you, your team, your leaders, and your 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.
So going Agile just so you can say you’re using business agility, or, even worse, going Agile 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.
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:
- 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 impediment removal, and facilitates 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 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 crossfunctional 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 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; 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.
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 14th Annual State of Agile Report are:
- General organizational resistance to change
- Not enough leadership participation
- Inconsistent processes and practices across teams
- Organizational culture at odds with Agile values
- Inadequate management support and sponsorship
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 undermined 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, Agile 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 chances 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 workweek 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 like this one. 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 represent 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 a
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 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.