IN THIS CHAPTER

Taking a ten-step approach to becoming an agile enterprise

Tackling the cultural aspect of a big change

Getting everyone in your organization to start thinking Lean

Selecting an enterprise agile framework

Making lasting changes

Enterprise agile transformations involve numerous variables, including the size of the company, its culture, the framework it chooses, the products it creates, and its existing agile competency, so each organization may approach its transformation in a unique way. However, if you’re not sure how to get started, consider the following ten-step approach:

1. Identify your organization’s culture.
2. List the strengths and challenges with changing your culture.
3. Select the best approach to organizational change management.
4. Train managers on Lean thinking.
5. Start a Lean-Agile Center of Excellence (LACE).
6. Choose a high-level value stream.
7. Assign a budget to the value stream.
8. Select an enterprise agile framework.
9. Shift from detailed plans to epics.
10. Respect and trust your people.

In this chapter, I explain each of these steps in detail.

Think of these steps only as a great way to get started. After you have an enterprise agile framework in place, any additional changes to improve the system will be more targeted to address areas that need improvement.

Step 1: Identifying Your Organization’s Culture

The first step toward transforming your organization into an agile enterprise is to size up its existing culture, so you know what you’re up against. In Chapter 9, I describe the four corporate culture types presented by William Schneider in his book, The Reengineering Alternative — control, competence, collaboration, and cultivation. However, placing your organization into one of those four culture types is challenging for two reasons:

• As an insider, you may not be the best judge. You may see your organization as you want it to be instead of as it really is, or you may be unable to see how your organization differs from others.
• Your organization may have elements of two or more cultures. For example, your organization may have a control culture with pockets of collaboration and cultivation cultures. What’s most common is to have a dominant culture type and then a few characteristics of another type.

Often you can figure out your organizational culture model by touring your organization, observing behaviors, and asking yourself the following questions:

• What’s the office dress code? For example, a formal dress code is more characteristic of a control culture.
• How do people decorate their work area? For example, if people hang copies of their diplomas, certifications, and awards, you’re probably dealing with an organization that has a strong competence culture.
• Where are people sitting? If people are working in cubicles, then you’re likely looking at a competence or control culture. If the cubicle area is surrounded by offices with doors, you’re most likely looking at a control culture. If groups share work areas and can see one another’s screens, you’re probably dealing with a collaboration culture.
• Where are people meeting? If people are meeting in groups in the middle of an open floor plan, the organization probably has some aspects of a collaboration culture.
• Who’s calling the shots? Do employees make decisions or do they receive their marching orders from the top down (as in a control culture)?
• Do people look happy? People are generally happiest when they’re able to contribute to express themselves and when their opinions matter, as in a collaboration culture. In a strictly controlled environment, people show up for work, put in their time, and go home.
• What’s the noise level? A noisy environment is more typical of a collaboration culture, but you can have a very noisy office in which everyone is working independently; for example, an office full of real estate brokers.

As you gather and analyze your evidence, follow these tips and cautions to make a more objective assessment:

• Gather plenty of evidence and look for patterns of behavior. Don’t draw your conclusion based on only one or two pieces of evidence.
• Assemble a group of three or more people to make the assessment, so it’s not based on one person’s opinion. Make sure everyone agrees about the evidence, and then have everyone cast a ballot for the culture type he thinks is predominant in the organization. Approach this vote as you would play a round of planning poker: Vote and then discuss the reasons each person voted the way he did. Continue this cycle of voting and discussing until you reach consensus. Work toward ranking the four culture types from strongest to weakest in the organization.
• Keep in mind that your organization may have one dominant culture with characteristics of other culture types.
• Beware of confirmation bias — interpreting data based on preexisting beliefs. For example, everyone in your group may think your organization has a strong collaboration culture, so it gathers evidence and analyzes it in a way to show that the organization has a collaboration culture, even though the organization actually has a strong control culture. Make a conscious effort to be objective.

Chances are good your organization has a control culture or at least some elements of a control culture, because it’s the most prevalent culture type. In fact, most organizations have to work hard to adopt something other than a control culture. Up until recently most of the largest companies relied on a pretty strict hierarchy, which spawns some habits that are tough to break.

No culture is good or bad, better or worse. Every culture is just an underlying system the organization decided to create and reinforce, and it may have a valuable role to play in the organization’s success. What’s important is that you understand the culture you’re dealing with, so you can implement your agile transformation more effectively and efficiently.

Step 2: Listing the Strengths and Challenges with Changing Your Culture

Different elements of your organization’s culture may accelerate or hinder your change initiative, so try to identify these elements early on. One way to identify potential assets and liabilities within your organization is to assess your culture’s strengths, weaknesses, opportunities, and threats (SWOT). You can then take advantage of your strengths and try to minimize the impact of your weaknesses.

Create a SWOT diagram as shown in Figure 11-1. At the top of the diagram, write the dominant culture in your organization followed by the secondary culture type (if any). Create a box for each of the SWOT categories — Strengths, Weaknesses, Opportunities, and Threats.

Collaborate with your group to identify specific strengths, weaknesses, opportunities, and threats inherent in your organization’s culture that are relevant to your enterprise agile transformation. Record the items your group identifies in each of the relevant boxes, as shown in Figure 11-1.

Your SWOT diagram can be a valuable tool in your agile transformation. For example, one of the strengths identified in the SWOT diagram shown in Figure 11-1 is “Strong PMO” (PMO stands for project management office). You can leverage the power of a strong, supportive PMO by using it to drive your enterprise agile transformation.

Keep in mind that one organization’s strengths may be another organization’s weaknesses. If your PMO doesn’t support agile, then “Strong PMO” would go in the Threats box, and you’d have to figure out a way to address this potential source of resistance.

Spend extra time on the Opportunities category, because opportunities often provide the impetus to overcome resistance within the organization. Opportunities give people a good reason to embrace change. Look for opportunities in your agile transformation that failed change initiatives from the past didn’t have. When you present your SWOT analysis to the organization, you can then use these opportunities to answer the question, “Why will this change initiative succeed when so many others have failed?” You may even want to address specific change initiatives from the past to explain why they failed.

Think of your SWOT diagram as an analytical tool for developing your game plan. You’re identifying your team’s strengths and weaknesses, so you can leverage your strengths and minimize the impact of your weaknesses. For example, if you identify strong corporate leadership as a threat and your development teams as a strength, you may decide that a bottom-up approach to your agile transformation would be best, as explained in Chapter 10.

Step 3: Selecting the Best Approach to Organizational Change Management

After you’ve identified your organization’s culture and conducted a SWOT analysis, choose a change management technique, such as one of the two approaches presented in Chapter 10:

• Kotter’s eight-step change model (top down): If your organization has strong leadership that supports the enterprise agile transformation, the eight-step Kotter approach is probably best.
• Fearless Change (bottom up): If you have influential groups within the organization that enthusiastically embrace enterprise agility and resistance or apathy at the top, driving change from the bottom up may be the most effective approach.

For example, if your organization has a strong PMO, the Kotter approach is likely to be best. A strong PMO has the logistics in place to drive a major transformation, including the reporting structure, in-house training, and relationships with key executives. The PMO would be well-positioned to create and maintain a dual operating system (see Chapter 10) that maintains the functional hierarchy while creating a more flexible team-based network.

On the other hand, if your organization has a stronger competence culture, you may be better off trying Fearless Change. Remember that competence cultures value knowledge and skills. A highly competent culture is likely to have more authority to make big changes, so an enterprise agile evangelist can have significant impact. She could become an expert in enterprise agility and convince others to make big changes.

Your decision is not an either/or choice. Although the Kotter approach initiates change from the top, it includes bottom-up support through the use of an “army of volunteers.” Likewise, although Fearless Change drives change from the bottom up, it relies on a change leader with some level of authority. You can certainly mix and match, choosing elements from both approaches. Your decision is whether to initiate change primarily from the top or bottom.

Step 4: Training Managers on Lean Thinking

For any enterprise agile transformation to succeed, top-level managers need to understand that enterprise agility is built on the foundation of Lean thinking — organizing activities in a way that eliminates waste to deliver optimum value. You can use the Simple Lean-Agile Mindset (SLAM), as I explain in Chapter 3, to show the system-level optimizations that are essential to successful enterprise agile transformations.

Discourage your organization’s leadership from thinking of enterprise agility as just a few new process improvements or as a collection of practices, such as small teams and daily stand-up meetings. Enterprise agility is bigger than that. By focusing on Lean thinking, you increase the scope of enterprise agility beyond processes and practices to a mindset. The focus is on delivering value to the customer in the most efficient manner possible.

One fact that top managers often have difficulty accepting is that local optimization differs from system-level optimization. For example, a super-productive employee can actually slow down a system, just as a star player can ruin a team. Instead of hiring and rewarding superstars, organizations need to look for people who have the knowledge, skills, and characteristics to complement the team.

Executives and directors are accustomed to thinking of the organization as broken into different functional areas with each functional area broken down into teams. They may have a difficult time imagining a team of superstars being slower than several teams of average performers. One team turning out too much work too fast can actually create a bottleneck that slows the entire process. Having a balanced system with everyone working at the same pace is most efficient.

Many of the organizational improvements behind your enterprise agile transformation include system-level optimization, so managers need to grasp the concept and appreciate the value of system-level improvements. Be prepared to spend plenty of time training managers, so they understand the benefits and are ready to make big changes.

Step 5: Starting a Lean-Agile Center of Excellence (LACE)

Whether you initiate change at the top or bottom, create a Lean-Agile Center of Excellence (LACE) to transition the entire organization to a Lean-Agile Mindset (see Chapter 10). A Center of Excellence (CoE) is a group of enthusiastic and knowledgeable people who promote change throughout the organization.

To create your LACE, recruit an individual within the organization who has the knowledge, enthusiasm, and charisma to bring others on board. (This may be you.) Provide this individual with the resources she needs, including a meeting room, a budget, and, most important, the authority to make changes.

As you form your LACE and run your meetings and events, follow these guidelines:

• Create a fun group that’s passionate about improving the organization. Recruit the type of people who are always looking for new ways to shorten their commute to work and to manage their email more efficiently.
• Recruit doers, not just talkers. Look for people who persevere in the face of adversity. Impatience is okay, but they need to be in it for the long haul.
• Develop a LACE mission statement, goal, and objectives. Formulate a vision of what the organization will look like after it becomes an agile enterprise, and develop a plan for how your LACE will help the organization achieve that vision.
• Charter the group with authority from the top to spearhead change. Your LACE will disintegrate quickly if all its efforts are shut down by middle managers. The LACE should realize that it will encounter some resistance, but its members shouldn’t begin to feel that their endeavors are fruitless.
• Maintain a meeting and event calendar with a cadence of regularly scheduled meetings and events. Without a schedule, people are likely to lose interest and stop attending meetings. A predictable cadence helps people plan other commitments around these events, reducing potential conflicts.
• End every event with consensus and an action plan. Never “agree to disagree.” Instead, give all participants the opportunity to argue their ideas, but at the end of the event, the group should have consensus and an action plan. Feel free to have a show of hands if you can’t reach consensus.

Find the sweet spot between fun and effective. Remember that most of the people in your LACE are volunteers. They could be working on other projects, and they have a life outside of work. They usually join the LACE out of an interest in improving the organization. Make events festive and productive, so your volunteers look forward to meetings and feel as though the LACE is making a positive impact on the organization. If you give a one-hour PowerPoint presentation about the benefits of the Lean-Agile Mindset, you’ll quickly find yourself with many empty seats.

If your CoE is staffed with volunteers, know that getting real work done with a volunteer army is always a challenge, especially when you’re working on an initiative that’s likely to encounter resistance. By finding the sweet spot between fun and effective, you can draw the crowds while making a rewarding impact.

Step 6: Choosing a High-Level Value Stream

Your LACE should collaborate with upper management to identify value streams, as I explain in Chapters 4 and 8. (A value stream is a series of steps for building solutions that deliver value to a customer continuously.) Value streams come in two types:

• Operational value streams: Steps to provide goods or services to customers internally or externally to generate revenue for the organization. For example, an organization may have a value stream for selling and delivering a product to a customer.
• Development value streams: Steps to design and build new products, systems, and services capabilities, such as a software application, a driverless car, or an internal process. For example, the process used to create a product sold to a customer would be a development value stream.

To make your organization Lean, you eventually want to optimize both operational and development value streams, but I recommend starting your agile transformation with a development value stream for two reasons:

• Optimizing a development value stream is easier, because you can focus on a system for developing a single product.
• Your work will be more interesting and rewarding, providing greater motivation for everyone involved in your enterprise agile transformation.

Focus on a development value stream that’s a key part of the business. Look for a value stream that meets the following four overlapping criteria:

• It has leadership’s support. You’re more likely to rally leadership support for your enterprise agile transformation by improving development of a product that leadership values.
• It is clearly high level. Choose a value stream that everyone in the organization understands and appreciates. If people know the product and appreciate its value to the organization, explaining the benefits of enterprise agility will be easier, and your wins will be more visible.
• It crosses functional areas. Choose a product that requires collaboration across functional areas, such as business analysis, design, programming, and testing, so you’ll need to create one or more small, cross-functional teams.
• It poses a real challenge or opportunity. Choose a value stream that has an opportunity for significant improvement, so that your success delivers real value to the organization. A big win will rally the entire organization around future extension of enterprise agility to other areas of the organization.

Step 7: Assigning a Budget to the Value Stream

With enterprise agility, you need to stop budgeting for projects and start budgeting for value streams. Instead of carefully defining the scope of a project, as is common with project budgeting, the scope remains flexible, and the development team integrates functionality into the product incrementally according to an ever-evolving product backlog (a prioritized list of work items).

Value stream budgeting moves away from focusing on what the project will do and instead puts all the emphasis on what value the product provides.

Think of it this way. Sometimes you walk into a restaurant and you have a complete notion of what you want to order. Maybe you have a favorite sandwich or a dish you’ve ordered in the past. Other times you walk into the restaurant with a set budget in mind (maybe you don’t want to spend more than $30) and a general notion that you just want to get something delicious to eat. In the first example you’re funding a project. You know exactly what you want to buy and you know how much it will cost. In the second example you’re funding your value stream. It’s valuable to you to have something delicious to eat. When you went to the restaurant you don’t really know the final product, you just want it to be delicious.

The advantage of value stream budgeting is that it more closely aligns with the enterprise agile mindset. You’re giving the teams flexibility to narrow down the highest-value features and work to deliver a high-quality product. You don’t have a complete picture of what their product will be when it’s finished. Instead, your teams work closely with the customers to zero-in on what they want. Your aligning your organization and agreeing on the highest-value parts of your product.

Step 8: Selecting an Enterprise Agile Framework

Prior to initiating your enterprise agile transformation, choose one of the agile frameworks presented in Part 2, or mix and match elements from various frameworks to tailor your own solution. Refer to Figure 11-2 for guidance:

• Along the horizontal x-axis: From left to right, frameworks range from highly prescriptive to more empirical. A highly prescriptive approach, such as the Scaled Agile Framework^® (SAFe^®), has more roles, practices, and guidance. More empirical frameworks, such as Large-Scale Scrum (LeSS) and the Spotify Engineering Culture, encourage experimentation, measurement, and learning.
• Along the vertical y-axis: From bottom to top, frameworks differ depending on the change management strategy — whether change is initiated at the bottom (team) level or is driven from the top (enterprise) level down. Note that SAFe, Disciplined Agile Delivery (DAD), and LeSS all tend to be frameworks that require a top-down change management style to implement.

Use Figure 11-2 to match your organization’s existing culture to a suitable framework. For example, if you have a strong control culture, consider a prescriptive framework that you can use to drive change from the top down, such as SAFe. On the other hand, if you have a strong competence culture, you may be better off using a more empirical framework with a greater emphasis on teams, such as LeSS, which gives teams more flexibility in how they do their work and enables you to leverage their expertise in improving the process.

Choosing an enterprise agile framework that clashes with your organization’s culture can lead to disaster. For example, trying to force the Spotify Engineering Culture on an organization with a strong hierarchy would be very disruptive. A company with a deeply ingrained hierarchy is likely to resist a system that reorganizes everyone into squads, tribes, chapters, and guilds. Such a change would also push a lot of responsibility for process improvement down to small squads of employees, which would introduce far too much uncertainty for high-level management to accept.

Don’t choose a framework just because it worked well for an organization you admire, because that framework may not be the right match for your organization. For example, many organizations choose a framework merely because it worked for Google, Facebook, Apple, or Microsoft, but when they try the same approach, they fail miserably, because the framework clashes with their organization’s existing culture. To make it even more tempting, many consulting firms that promote a given framework try to sell it on the basis that it worked for a few top-performing and well-known companies. Avoid the temptation. Think instead about how suitable the framework is for your organization.

Also remember to choose a framework based on the type of organization you are, not the organization you want to be. Compare your transformation to performance training. If you’re terribly out of shape, you don’t adopt a training program designed for world-class, long-distance runners. Instead, you choose a training program that’s better suited to your existing physical condition. After you achieve a certain fitness level, you can step up to a more aggressive program.

Step 9: Shifting from Detailed Plans to Epics

Large enterprises favor predictability, so before developing a product, they insist on having a detailed plan. Enterprise agility runs counter to this traditional approach. Instead, agile teams work with the customer to identify what the customer needs, and then they innovate, experiment, and adjust to develop a solution. Many organizations have difficulty transitioning from detailed planning to a more creative agile approach, because they’re afraid of the potential for negative outcomes. However, to become more innovative, organizations must reduce their aversion to risk and place greater trust in their product developers.

If people in your organization apply pressure to produce a detailed plan, push back. Encourage them to focus on the value stream and give the agile teams creative license to innovate solutions. For example, suppose your organization manufactures breakfast cereals. Your customer wants a tasty low-carb alternative. Leadership demands research and planning. They want a complete list of ingredients, nutritional values, and even the name of the new cereal before even one flake is toasted. But that’s not agile. In such a case, you need to push back and have the organization turn the project over to the team in the form of an epic — a lightweight business case for creating the product.

Instead of handing the team a detailed list of product requirements, you give the team an epic, such as “Create a nutritious and delicious low-carbohydrate breakfast cereal that will blow the competition off the shelves.” The team can then start experimenting with different recipes to lower the carbohydrate content while improving the cereal’s flavor and texture. The customer would taste each product increment and provide feedback about how to improve it. The team may even send samples out to some of the customer’s more influential social media fans to obtain additional feedback. Over the course of several product iterations, the team would eventually arrive at the winning recipe, and the customer could deliver the product to its market.

The whole point to having agile teams is to optimize value by allowing teams to innovate. Giving teams detailed product requirements undermines the purpose of enterprise agility — to improve value through innovation.

Step 10: Respecting and Trusting Your People

As organizations strive to become more agile enterprises, they often focus on frameworks, roles, and practices and lose sight of the more important aspects of enterprise agile transformations — principles and people. Innovation is a product of the mind. It’s the ideas people come up with when they have the knowledge, skills, and resources to do their jobs and the respect and trust to think independently. Otherwise, people simply do what they’re told, which stifles innovation.

As your organization embarks on its agile transformation, remind everyone of the Agile Manifesto (see Chapter 1). Highlight the first value: “Individuals and interactions over processes and tools.” Reinforce that value among executives and all levels of management, so they know that the source of innovation is found in the organization’s employees and their interactions with one another and with the organization’s leaders and its customers.

Respect for people is more than just an organizational optimization. It’s a wholesale rewrite of how many executives view their workforce. In his book Drive, Daniel Pink highlights the three elements that motivate people at work:

• Autonomy: Most employees have an inherent desire to do quality work and have a positive impact on the organization’s success. They need to feel that they’re trusted to do a good job without a great deal of oversight and management intrusion. Unfortunately, many organizations value predictability over autonomy, and they end up stifling innovation and discouraging employees from taking initiative.

• Mastery: People like to feel as though they’re great at their jobs, and most are willing to spend time outside of work and even invest in their own professional development to achieve mastery. Your organization’s leadership would be wise to feed this desire for mastery by supporting personal and professional development.

  Your organization can encourage mastery by supporting communities of practice (see Chapter 5), a center of excellence (see Chapter 10), and guilds (see Chapter 7). For an additional investment, your organization may consider paying for employees to attend seminars or conferences, and it may provide tuition reimbursement for certain classes. The return on investment in terms of increased employee retention and improved knowledge and skills is well worth it.

• Sense of purpose: Employees want to feel as though they’re having a significant positive impact on the organization’s success. Seeing an idea come to life and significantly improve the end user’s experience is a huge reward. It’s what makes people want to jump out of bed in the morning eager to get to work.

Enterprise agility requires a culture of mutual respect and trust, and it nurtures such a culture. As soon as you transition to small, self-organized, cross-functional teams and stop providing teams with detailed product requirements or specifying how to build the product, employees naturally begin to look for ways to improve the product and the process for creating it. Management can help in two ways:

• Get out of the way. Although management traditionally assigns and supervises work, in an agile enterprise, it needs to get out of the way. The product owner maintains a product backlog (a prioritized list of work items), and the team draws from this list to determine what must be done. How it gets the work done is up to the team.
• Serve the teams. Management should regard themselves as enablers. They should provide the teams with whatever they need to excel, whether it’s hardware and software, training, agile coaching, specialized tools, or something else entirely. That kind of support will maximize the potential value created by the team.

Look for ways to continuously improve your organization’s workforce and the systems it uses to deliver value to the customer. These two Lean-Agile practices will drive much of your organization’s continuous improvement.