Enterprise Agility in 3 Not-So-Easy Steps

Enterprise agility is agile for big products — typically one that requires many different teams throughout the organization that coordinate with many different departments and stakeholders. The best way to implement enterprise agility in your organization is to take the following three steps:

1. Review the top enterprise agile frameworks.
2. Identify your organization’s existing culture.
3. Create a strategy for making big changes.

This three-step process isn’t really unique to enterprise agile transformations; it’s pretty standard for making any large-scale organizational changes. You want to better understand the changes you’re proposing, then understand the environment in which you’re making the changes, and finally figure out how to apply these changes to your environment.

Step 1: Review the top enterprise agile frameworks

The first step toward an enterprise agile transformation is to understand what being agile means and get a sense of what different manifestations of agile look like. The fact is that you can achieve enterprise agility in an infinite number of different ways, just as you can use different health and fitness programs, mix-and-match programs, or develop your own program to become healthy and fit.

A great way to start is to look at the top enterprise agile frameworks: SAFe, LeSS, DAD, the Spotify Engineering Culture, Kanban, and Lean. Collectively, they provide several frameworks and include numerous agile principles and practices. Simply by exploring the different frameworks, you will start to develop a more agile mindset and begin to appreciate the full scope of enterprise agility.

As you explore the enterprise agile frameworks, try to look beyond each framework to understand the rationale behind it. If you can understand what the developers of each framework were thinking and the problems they were trying to solve, you will be well on your way to making the right decisions and choices for your organization. Remember, pulling a framework off the shelf may work fine, but be open to the possibility of tailoring it to your organization. No framework is a one-size-fits-all solution.

Step 2: Identify your organization’s existing culture

One of the biggest reasons organizations fail in their transformation effort is that they don’t take their existing culture into account. The problem is worst when an organization with a firmly embedded traditional management matrix tries to become more agile, because strong management tends to clash with some of agile’s emphasis on self-organizing teams.

Organizations don’t intentionally ignore culture. They’re just so immersed in it that they no longer notice it. Culture is sort of like the air that surrounds us; we don’t notice the air until a cold front sweeps in. We don’t notice culture until it comes in contact with another culture, at which point cultural differences become readily apparent. You may not notice your organization’s culture until you try to change it to something that’s very different.

Don’t make the common mistake of ignoring your existing culture, so size up your culture before attempting to transform it. Following are four common corporate culture types:

• Collaboration culture: Common in schools and professional training organizations, collaboration cultures are run like family businesses, with leaders acting as decision-makers, team builders, and coaches. Managers work closely together like a small group of friends, and the closer you are to the head of the organization, the more authority you have. These organizations are typically more open to change than those with a control or competence culture, so they tend to adopt an enterprise agile mindset more readily. However, in a collaboration culture, leadership may have a difficult time allowing decisions to be made at the team level.
• Competence culture: Those with the highest level of expertise rise to the top, become managers, and create and delegate tasks. A meritocracy. The management style is task-driven; it’s all about who can do the best job at finishing the work. People in competence cultures often become highly specialized in their areas of expertise, because expertise is what is valued and rewarded. If they excel in more than one area, they’re likely to be given too many tasks and become quickly overwhelmed, so they specialize. They also don’t like to share their knowledge, because it places them at risk of losing some of their authority.
• Control culture: This culture is authoritarian with alpha managers setting the direction and beta managers following close behind. Leadership gives orders and demands compliance. Only a few individuals in the organization have decision-making powers; others must seek approval or permission, making the organization slow to respond to change. Such organizations favor order and certainty and rely on large management systems that ensure predictable outcomes.
• Cultivation culture: Employee growth and development form the cornerstone of the organization. Managers seek to bring someone into the organization, hold them up, and then build them up. Charismatic individuals quickly rise to the top, and generalists commonly do well. These organizations tend to be more democratic and transition more easily to an agile mindset, but decision-making can be slow as consensus is sought among large groups of individuals.

Consider choosing a framework that’s a closer match to your current culture than a match to the culture you want for your organization, so the transformation won’t be too much of a stretch. Some frameworks are much more agile than others. For example, Spotify’s approach gives teams a lot of autonomy, and that may strike you as the way you want your organization to be. However, Spotify’s approach works for Spotify, because it’s not a huge organization. Spotify has nurtured a collaborative culture from its inception, and the company redesigned its product’s architecture to make it more modular, so a squad can work on one feature without having to integrate its work with a lot of other squads and tribes. If your organization has a strong control culture, making the leap to Spotify’s approach may be as challenging as trying to jump across the Grand Canyon on a motorcycle.

Instead, SAFe may be the better choice because it has more practices for top-down decision-making. It allows for some agility while giving managers deep insight and control over the organization.

An organization may fit into more than one category; for example, its engineers may be driven more by a competence culture, whereas marketing is run more in line with a cultivation culture.

The famous management consultant Peter Drucker once said that “Culture eats strategy for breakfast.” This holds true for enterprise agility. Whatever strategies you pick for your enterprise agile transformation, they won’t succeed without the support of a culture that values people, respect, trust, and innovation.

Step 3: Create a strategy for making big changes

As you think about your strategy for making big changes, look for the sweet spot between your organization’s acceptable and unacceptable change, as shown. Finding that sweet spot is more art than science. Identify areas you want to change and areas where you’re likely to encounter resistance. Try to understand why you may encounter resistance in certain areas. Your organization probably has gravitated toward a particular culture for good reasons, so you can decide whether and how an area needs to be changed. If a certain area is less agile for good reason, you may want to let it be.

After you’ve found your sweet (and not so sweet) spots, you’re ready to start adopting the agile frameworks, processes, and principles you choose.

Choosing a top-down or bottom-up strategy

When you’re ready to start your enterprise agility adoption journey, you basically have two big-change strategies from which to choose:

• Fearless Change: A bottom-up approach, which can be driven by a few employees. Fearless Change tends to work better in competence, cultivation, and collaboration cultures. Fearless Change may also be effective in smaller, newer organizations that don’t yet have a deeply entrenched hierarchy.
• Kotter approach: An eight-step, top-down process driven by a change leader, who can be a manager or an outside consultant. The Kotter approach tends to work better in control cultures — the most common culture in large organizations, which typically have a well-defined hierarchy.

Whichever strategy you choose, look for opportunities to make smaller, realistic changes. Instead of trying to force change on your organization all at once, win the war gradually, battle by battle. Pick the low-hanging fruit. Giving teams shared workspaces and providing agile training can get the culture ball rolling. Then, build on the momentum of your success.

Mapping out your plan

After you’ve thought about which approach is likely to work best, map out your plan. As you develop your change management plan, you’re likely to end up with an odd combination of general and specific. You’ll have specific deadlines of when to expect real improvement. Maybe you’ll have a concrete objective to have all your business analysts sit with your team in a shared workspace. But then you’ll have general guidelines on how to reach that objective. You may decide to have everyone in that shared workspace receive coaching on the benefits of sitting together. You could also just make it a simple matter of rearranging desks.

This combination of specific and general guidance gives your plan enough structure to be useful, but enough flexibility to allow teams to adapt. No change management plan will survive implementation; that is, your plan will change as you implement it, and that’s okay. The trick is to spend just enough time planning to make your organization more agile, but not so much that you steal away time from the implementation or make your plan so restrictive that it undermines the agile mindset.

Setting the stage for business agility

A growing movement among businesses is to extend enterprise agility from product delivery to the entire organization in order to achieve business agility. This movement is really about “agile management” — taking agile ideas that have worked well for product development and using them to run an entire organization. Business agility is about “agilizing” every part of your organization.

The best way to think about the relationship among agile, business agility, and enterprise agility is to look at them as three levels of agile implementation:

• Agile (at the team level): You have one-or-two agile teams working on a part of a larger product.
• Business agility: The entire organization adopts an agile mindset and a set of agile principles that guide the way everyone works independently and together.
• Enterprise agility: You have dozens or hundreds of agile teams working in concert on a single large product — an enterprise-level product. Some enterprise agile frameworks are simply expansions of team agile approaches; for example, SAFe is Scrum only with more Scrum teams and additional roles and structure to coordinate their work.

In general, business agility deals with all domains, including those outside of product development, such as adaptive leadership, organizational design, and budgeting. While the more robust frameworks, including SAFe, touch on these domains, they offer little guidance to help you extend agile into these domains. It’s a little like old maps that put dragons in place of uncharted territory with the caption “there be dragons here.” They suggest that agility involves changes in other domains, but they don’t explicitly describe the changes or offer guidance on how to make those changes.

Resist the urge to tackle all three circles at once. Start with a few agile teams. After finding success with those teams, try enterprise agility with a larger product. As you gain success with several teams working together to deliver a whole enterprise solution, you can begin to start thinking about using agile methodologies to rework your entire organization. Don’t try to rework your whole organization until you have a proven strategy for delivering enterprise-level products.

Enterprise agility is not business agility. Enterprise agility is about delivering product. All the changes that you make to your organization in terms of frameworks, roles, processes, and practices should sit neatly within the realm of product development. Any changes you make to the overall organization or to organizational leadership will be in the realm of culture and mindset — to make management more receptive to an agile mindset and supportive of the big changes you’re introducing to product delivery. Stay focused on delivering better products and not on creating a better organization. Certainly, success in product delivery may lead to an expansion of agile to the entire organization, but start with product delivery and work your way up.

You may find it strange to use practices that were designed for software development to run domains such as human resources, sales, marketing, or legal, but advocates of business agility argue that the accelerating pace of change demands that the entire organization become agile.

Practicing shuhari

Many of the agile and enterprise agile frameworks are influenced by Japanese manufacturing models developed to minimize waste and optimize workflow. Another common agile practice that comes from the Japanese is shuhari, a martial arts model of learning and honing one’s skills:

• Shu: Follow the rules and learn the basics.
• Ha: Start to break the rules and put your own learning in context.
• Ri: Create your own rules and find your own way.

As you transition your organization’s product delivery to enterprise agility, follow the shuhari approach. Here’s how:

• Shu: Explore the top enterprise agility frameworks, principles, and practices to gain knowledge and wisdom of the commonly accepted approaches to enterprise agility. In other words, learn from the masters.
• Ha: Start thinking about how these approaches to enterprise agility would look in your organization. Think about them in the context of what’s already in place and in the context of your organization’s existing culture. What ideas make sense to you? Where do you think the developers may be wrong? Which ideas are likely to work well (and not so well) in your organization?
• Ri: Using all the knowledge and wisdom you’ve acquired, create your own custom framework tailored to your organization. Adopt the principles and practices that work best for your organization, mix and match, modify, and create your own.

No two organizations are identical, and none of the enterprise agile frameworks is a one-size-fits-all solution. Use what works, toss what doesn’t, and keep your eye on the prize — delivering value to your customers while achieving your business goals. That’s what agile is all about.