Understanding agile product delivery

According to the Agile Alliance, agile is “the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.” Instead of relying on extensive up-front planning, “solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.” (Self-organizing means the teams manage themselves. Cross-functional means each team has all the expertise and skills required to complete its work.)

Small teams (typically fewer than nine people) are empowered to collaborate and make decisions as opposed to being subject to intensive planning, rigid processes, and consulting management for direction and approval. The goal is to remove the management obstacles that commonly get in the way of competent people doing their jobs.

Agile frameworks originated in the context of software development, an area subject to rapid change — changes in end-user needs, technologies, and even the tools and processes used to develop software. To be effective, developers needed to be agile. They had to be able to make decisions locally instead of having to wade through the bureaucracy of traditional management matrixes.

Defining “enterprise agility”

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.

While agile involves one or two teams working on a part of a product, enterprise agility may involve dozens or even hundreds of teams working on a whole enterprise solution. When you have that many teams working on a single enterprise solution, you start running into alignment issues and creating a lot of dependencies. Although you may want to remain agile, you need to start with at least a unified vision and have a system in place that enables the teams to communicate, coordinate, and collaborate efficiently and effectively to bring the vision to fruition and improve on the vision through innovation.

While agile team frameworks, including Scrum and Extreme Programming, work well on a small scale, they can lead to chaos when you attempt to scale up. To resolve this issue, the agile community has developed a number of enterprise agile frameworks — systems to help align the efforts of teams working together on a big product and reduce the number of dependencies.

Don’t confuse enterprise agility with business agility. Business agility applies the agile mindset to the entire organization, which is sometimes referred to as “diffusion of IT-based innovations.” Business agility deals with all domains, including those outside of product development, such as adaptive leadership, organizational design, human resources (HR) or personnel, and budgeting. This book’s focus is on enterprise agility, not business agility (but I do include a brief section on business agility near the end of this chapter).

However, for enterprise agility to work in your organization, everyone in the organization must adopt an agile mindset. Otherwise, the traditional management practices that are common in a culture that values predictability and failure avoidance will clash with the agile values of experimentation and innovation. You won’t get the full benefit of agile if agile teams are merely doing what they’re told.

Few organizations that consider themselves agile enterprises have the culture and mindset to make that claim. What typically happens is that an organization will have five or six agile teams that practice Scrum, Extreme Programming, Kanban, or Lean Startup. The teams may achieve some degree of success — the organization may produce higher-quality software and the developers may be happier — but until the agile mindset permeates the entire organization, it’s not an agile enterprise and will not reap the full benefits of enterprise agility.

Checking out popular enterprise agile frameworks

Just as agile has several different frameworks for structuring the way teams function, enterprise agility has a selection of frameworks that provide direction for how teams work together on enterprise solutions. Currently, about a dozen well-established frameworks are available, and each one takes a different approach. Collectively, these methodologies form a cafeteria of ideas from which organizations can choose based on the organization’s existing culture and the culture it wants to establish moving forward.

Following are five of the most popular frameworks:

• Disciplined Agile Delivery (DAD): A process decision framework, DAD encourages you to make certain choices at different points in product delivery, but doesn’t prescribe any specific process to follow to make your organization agile. Instead of prescribing a process, it offers general guidance such as, “Here are the goals, and here are a few approaches for meeting each of those goals, and here’s some guidance to help you choose the best approach.” You’re free to choose any framework and practices to mix and match, or create your own. (See Chapter 6 for details.)
• Large-Scale Scrum (LeSS): A framework that contains many of the elements familiar in Scrum at the team level, including sprint planning, backlogs (prioritized lists of work items), sprints (the basic unit of development that results in an iteration of the product), daily sprint meetings, and a sprint retrospective (a sort of post-mortem meeting). The primary distinction between LeSS and Scrum is that with LeSS, you have several teams working in different “lanes” on different sprints, sometimes coordinating and collaborating between lanes. (See Chapter 5 for details.)
• Lean Product Delivery: A system for reducing waste in products and processes by eliminating anything that’s unnecessary, including excessive steps (in a process) and functionality (in a product) that don’t bring value to a customer. The focus is on minimizing waste and maximizing value. (See Chapter 8 for details.)
• Kanban: A system in which team members pull work items from a list of prioritized items on a Kanban board to work on them as their capacity allows. Kanban (signal) cards are used to indicate when a work item is ready for the next stage in the process. A buildup of Kanban cards in any stage of the process signals a bottleneck that must be addressed. The emphasis is on maintaining a smooth and continuous workflow. (See Chapter 8 for details.)
• Scaled Agile Framework (SAFe): A collection of frameworks, principles, and practices that attempts to combine the best of top-down management with the best of agile. Teams work together as teams of teams (called “agile release trains,” or ARTs) and as teams of teams of teams (called “solution trains”) to achieve the enterprise’s vision. SAFe is one of the more complex frameworks, adding numerous processes, layers, roles, and tools to solution delivery. (See Chapter 4 for details.)
• Spotify Engineering Culture: A mashup or composite of agile frameworks and practices that’s anchored by a strong culture of mutual respect, trust, and innovation. Teams (called “squads”) and teams of teams (called “tribes”) are encouraged to experiment freely, release products frequently, and tweak their products and processes for continuous improvement. Failure is not punished, and learning from failure is revered to encourage squads to experiment. (See Chapter 7 for details.)

Practicing as much agile as your organization can tolerate

The downside of some of these enterprise agile frameworks, with the exception perhaps of DAD and the Spotify Engineering Culture, is that they try to “productize” your transformation. (To productize is to take a concept like agile and turn it into a pre-packaged solution.) It’s like getting a suit off the rack when you really need something that’s tailored to your organization.

The suit off the rack isn’t really how most enterprise agile transformations are done. There won’t be a day when you cross the agile finish line. Your organization will never reach an agile end state. Instead, much like a fitness program, you try to integrate these new ideas into the way you already work. It is a long process of small adjustments and continuous improvement, which is why you should think of your enterprise agile transformation as your organization accepting as much agile as it can tolerate. It’s about how well your organization accommodates change.

Before you even think about where you want to be on the agile scale, look at where you are. How much change can your organization tolerate? Think of it almost like a room in which you can only put so much furniture. If your organization can tolerate only small changes, then think of the highest priority agile practices that you can try to implement.

Don’t try to go too big too soon. Many enterprise agile frameworks require that you make several big changes simultaneously. The hope is that if your organization can tolerate big changes, you can quickly reap the benefits of your transformation. However, your organization will likely snap back if you try to make too many big changes too quickly, especially if your organization has a low change tolerance. Consider a more gradual approach — starting with a few teams, reviewing the results, and then building on your success. Build the desired culture in one small corner of your organization and, if successful, it will spread, as long as you remove any obstacles.

Large organizations usually have a change tolerance — how much change they can stomach without too much grumbling. If you exhaust everybody’s ability to change, transformation is likely to grind to a halt. Everyone will go on working, but don’t expect any more progress in the change department.

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 I describe in Part 2: 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 in Part 2, 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.

I don’t want you to make the common mistake of ignoring your existing culture, so I encourage you to 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 in Figure 1-1. 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.

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 (see Figure 1-2):

• Agile (at the team level): You have one-or-two agile teams working on a part of a larger product. In Chapter 2, I introduce you to the various frameworks, principles, and practices that drive agility at the team level, such as Scrum and Extreme Programming.
• 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.