Leadership in the Agile Organization

Many of my conversations with Agile practitioners took a swift and immediate turn toward the topic of leadership. A 2006 Harvard Business Review article titled “Embracing Agile” speaks to how many Agile initiatives wind up being undermined by the very organizational leaders who often demand them:

When we ask executives what they know about agile, the response is usually an uneasy smile and a quip such as “Just enough to be dangerous.” They may throw around agile-related terms (“sprints,” “time boxes”) and claim that their companies are becoming more and more nimble. But because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them.

For what it’s worth, I believe that training is only part of the solution here. I know many people who have been through hours and hours of Agile training and still have no clear idea of what is expected of them and why. The bigger challenge, as I learned from my first experience with Agile, is that the underlying values of Agile—the substantive ideas lurking behind all that shiny jargon—are often at odds with the behaviors and expectations that organizational leaders have developed through years of successfully navigating “business as usual.” Indeed, each of our three laws of organizational gravity also exerts a force on our organization’s leaders, as shown in Table 6-1.

The Three Laws of Organizational Gravity often create situations in which the people feel that it is against their best interest to bring to the attention of their managers any information about the way they work or the people they serve that might be perceived as “bad news.” This adds up to a situation in which leaders have a very difficult time gaining an accurate understanding of the challenges facing both their colleagues and their customers. And that, in turn, can leave employees feeling misunderstood and powerless—how are their leaders supposed to make things better if they don’t even understand what’s going on?

When organizational leaders have largely been insulated from the on-the-ground challenges facing both their employees and their customers, they are often left with the impression that “business as usual” is working just fine. It is no surprise, then, that their initial interest in Agile often privileges incremental operational improvements over substantive cultural change. This leaves ample room for leaders to misinterpret our guiding principles of Agile, as captured in Table 6-2.

When enlisting team and organizational leaders in support of any Agile initiative, it is important to start from a place of empathy, not accusation. Do not assume that leaders are being willfully dismissive or difficult if they don’t seem to understand what these new ideas mean, or if they seem hung up on superficial improvements. Break the cycle of strategically withholding and sugar-coating information by being open, honest, and candid, and giving the leaders with whom you are speaking a chance to respond in kind.

It is often not until individual leaders become aware of the challenges that have been purposefully withheld from them that their character and competence can be accurately assessed. One of the most interesting conversations I had about this issue was with Jeff Kaas, CEO of Kaas Tailored. Kaas Tailored is a custom upholstery business in Seattle, Washington, that has been able to profitably manufacture textiles within the United States by implementing Kaizen, or Lean Manufacturing principles. As Kaas has expanded his work as a coach and consultant with other organizations, he has come to recognize the importance of leaders being able to reflect on and transform their own behavior:

When I’m working with an organization, I start with the leaders and say, the process is really simple: head, heart, hands. I don’t tell them that it comes from the Bible—I just sound smart. For most leaders, they can understand it intellectually, but the big question is, can they feel it? Can they have that moment of knowing in their hearts that the way they’ve been operating has hurt the people who look to them for respect, for livelihood? When the head understands and the heart says, “OK, I get it, that’s meaningful to me,” then the hands run like crazy. If you do that at the highest level of authority, you can transform an organization.

Most rah-rah organizational transformation ideas last about six months, max. We have to be honest with each other and say this corporate improvement BS has been around and around and around. Why does it not work? Why does it go around and around and around? Because leadership has failed. Because they read books that teach them how to “motivate” in an insincere and manipulative way. These books don’t say, “Learn with your team, admit when you fail, do it together.” It took me years and years of touring and teaching to finally understand, “Oh, yeah, work should feel awesome.” Once I really felt this as a moral problem, the business part became easy. I am unwilling to be the guy who runs a company that in any way hurts you. Leaders need to be bolder in their actions and give every human being the respect that they deserve.

We’re trying to help people really understand this, on both a personal and a corporate level. It doesn’t really matter what tools you use—Agile, Scrum, whatever. The thing we all have in common is either we’re adding value as defined by the marketplace or we’re adding waste. And, in order to continue adding value and eliminating waste, we need to be constantly improving. What a lot of leaders don’t anticipate is that “continuous improvement” means continuously admitting to and addressing your own mistakes.

Indeed, while “continuous improvement” is an easy enough concept to agree to in theory, organizational leaders are often ill-prepared for the emotional labor that goes into admitting that their best efforts may still have fallen short, or that the needs of their organization may have outpaced their own vision or experience.

This is particularly important when we are working with the people who often feel like they have the most to lose in a transition toward Agile practices: middle managers. Many of these middle managers have spent their entire careers carefully managing the flow of information upward and downward—something that actually runs quite counter to the mandates for transparency and collaboration that come with Agile. As IBM CMO Michelle Peluso pointed out, implementing the practices and principles of Agile often means reshaping the role of middle management:

In huge companies, there are often a lot of people who sit at the middle management layer and spend all day moving information up and down. They gather information from their direct reports, they send it up the ranks, they get information from farther up the ranks, and they break it down and share it with their direct reports. If you are truly Agile, you don’t need this kind of hub-and-spoke model. The teams have to solve things themselves. If you’re going on an Agile journey, you need to embrace the idea that you’re going to get rid of some middle management.

The good news is, a lot of great middle managers can be repurposed to do more impactful things. While there is less need for shuttling information up and down, there is a much greater need for things like Agile coaching and cross-functional guild leadership. That can open up exciting new career paths for people. But it can be very hard for people who are used to measuring their success by the number of direct reports they have, and suddenly find themselves in this cross-functional world. There’s a real sense of, “We earned our way here, we spent years getting to this point.” It’s very frustrating and very emotionally difficult for people, for very real reasons. You need to approach it with empathy, and tackle it head-on.

I do think that oftentimes when you think about describing Agile to a team, it is framed up in terms of why it’s good for the organization at large. But it’s also important to ask, “Why are YOU going to be a better leader if you go Agile?” For starters, having a successful Agile transformation on your résumé can make you a hot commodity. But beyond that, embracing Agile means that you get to work side by side with data scientists, creatives, engineers—you get to really see and understand how they do their work. It creates an extraordinary learning environment. It’s important to be very clear about what people can expect individually; there are some really personal things about the journey to Agile that I think need to be understood and reinforced.

Respecting this personal dimension gives us a way to approach Agile that holds true to its founding values. It gives us a chance to build stronger and more transparent relationships between and among organizational leaders. And it gives us a chance to approach colleagues who may be fearful or resistant to change with openness, empathy, and curiosity that will ultimately help us implement Agile principles and practices in a more impactful and inclusive way.

Scaling Agile Across Teams and Functions

As more teams within an organization become interested in Agile, the question often arises of how to keep these teams synchronized with one another while still giving them the autonomy and empowerment they need to do their best work. The question of how to scale Agile across teams and functions is an enormous and challenging one. Some of the more recently developed Agile frameworks and methodologies, such as SAFe and LeSS, were designed to answer this very question. But as with any Agile frameworks or methodologies, they can become traps if they are implemented without a clear sense of their goals and success criteria beyond “everybody is adhering to the rules of the framework.”

Among the Agile practitioners I spoke with, there was a broad consensus that setting a compelling and accessible high-level vision of how the entire organization might work together in an Agile way is an important first step toward scaling Agile practices. IBM CMO Michelle Peluso described a powerful visual metaphor for creating alignment across teams by identifying the “gears” in these teams’ respective rhythms as potential points of alignment and coordination:

We think of marketing as a gear that needs to fit in with other gears. We need to connect with the product team, with the sales team, with management. This analogy has proven very valuable for us, and has helped us have open, important conversations about how we can connect with other teams. If we’ve committed to a set of business objectives, what other teams do we need to interact with? And what management disciplines and processes do we need to align with? Some of our teams may need to be very aligned with compliance, with legal. Some may need to be very aligned with a sales cadence. You try to keep your teams as small as possible, and then you think about how those teams can gear in with those other pieces and their rhythms and cadences.

This often means being very deliberate about who is gearing in with which other teams. For example, a product marketer usually needs to be closest to the engineering team, as they are translating between the engineers and the market at large. A campaign leader is usually the one who has to be very connected with a sales team—and these sales teams usually follow a specific weekly cadence. So it’s really a matter of being very, very thoughtful about both the teams and the routines you need to stay connected with, and then embracing the true Agile spirit of empowering teams to be accountable for that.

Sometimes, teams will come back and say, “Well, they don’t work the same way that I do!” And I remind them that they have a lot more control over their destiny than they may think. If you just attack it from a really practical perspective—How do they work, how do we work, where do we really have to be connected, and where do we not need to be connected?—there’s always a way. We don’t all need to have regular one-on-one meetings, we don’t all need to have 100 people on a phone call.

Another good question to ask is, “Where can we invite people into the Agile practices that we’re adopting?” I’ve found there are plenty of non-Agile teams that are willing to join Agile processes, and some that are not. And that’s fine. Different teams need different things, and there are ways to build that into the way you work with them. You don’t write it off and say, “The way we’re working is the only way to work.” You need to recognize that, in the spirit of Agile, we may come up with a better approach a month from now.

As this example illustrates, the most important steps toward connecting and aligning teams in an Agile organization are often about asking questions, not demanding immediate and definitive answers. Inviting individuals from other parts of the organization to participate in your team’s Agile practices is one way to create a “pull” that allows Agile to scale organically to the parts of the organization where it is most needed, rather than trying to “push” Agile to teams that might not immediately see its value.

Another powerful way to generate this “pull” across teams with diverging skills, goals, and needs is to stay focused on the common goal of serving our customers. Kelly Watkins, VP of global marketing at Slack, described to me how she was able to bring together product teams with product marketers to create a shared sense of customer obsession:

When you think about product development and marketing, there’s a lot of ways you can make them really complementary. But the way that a lot of organizations work, there’s just a hand-off from product to marketing when something is finished, and that seems very broken to me. Rather than the teams working in parallel and jointly working through a deadline, you have a marketing team trying to catch up. And that puts them in that unfortunate gatekeeper role: they’re necessary for that feature to go out into the world, but they need to create the story, create the assets, and do so without having been through the process of creating the product, articulating the vision, testing the hypothesis. It creates animosity between product teams and marketing teams. It also creates bad marketing. When a marketing team is that far out of sync with a product team, how are they supposed to come up with a story of what the product does that feels even remotely authentic? So you wind up with marketing that reads like, “We don’t really understand what this is, and we don’t really understand the user, so we’re going to use some marketing speak about how this is better, faster, and stronger.” When you, as a marketer, live through the process in which the feature is developed, you have a depth of understanding about the “why” that makes the marketing much more authentic.

When we started looking for opportunities to better align our product and product marketing teams at Slack, we started with a set of things we really wanted to solve for. First, we wanted to enable our product and product marketing teams to have alignment and a shared sense of purpose. And to accomplish this, we started aligning marketers against specific products and product teams for the long haul, from that initial development idea through launch. This way, marketing is actively participating throughout the entire process, not just slapping on words at the end. So, for example, that blog post you’re writing at the end of launch—you can write that at the beginning, and then track how that changes as the product evolves.

Second, we really wanted to enable opportunities for product marketing to be the point of induction into the product team for a lot of great insights. So we set up this process where product marketing, every quarter, puts together a robust feedback session prior to roadmapping, where they’re bringing insights from sales and customer relations and all the customer-facing teams. That enables both the product and the product marketing team to really know the customer, to be jointly customer obsessed.

For us, the question has been, “How do you create the right intersections and points of alignment without pushing it too hard?” I think part of it is expectation setting, getting across the idea and the spirit of co-participation. Part of it is clearly defining what the roles will be in that co-participation. And part of it is having some flexibility for “how” so that each team can optimize for their own specific needs.

The key takeaway from this story is not that all organizations must embed product marketers in their product teams, but rather that intractable-seeming organizational silos can be substantially eroded without every team having to work the exact same way. If we begin with a clear understanding of the goals we are working toward and the challenges we are trying to solve, we are free to give individual teams the operational leeway they need to meet their own specific tactical needs.

As shown in Figure 6-1, this allows us to scale our self-reinforcing loop of “Why,” “How,” and “What” to multiple teams within an organization while still respecting each individual team’s working style.

Figure 6-1. Scaling Agile to multiple teams within an organization by uniting around a shared set of Agile principles and values, and aligning team-level objectives under overall company goals.

As we discussed in Chapter 4, working to ensure that each individual team’s objectives are aligned harmoniously under overall company goals is one important step towards helping different parts of an organization effectively “gear in” with each other. Here are a few other steps you can take to implement Agile in a scalable manner:

Find a team that is already embodying Agile values, and start with them

Often, the best way to scale Agile across an organization is to find a team that is already behaving in an Agile way—even if it is not labeling it as such—and working with that team to document and share the practices that it has been using. This is well in keeping with the scout-and-scale approach described by former United States CTO Megan Smith in Chapter 4, and it provides an excellent opportunity to model a principles-first approach to Agile.

Acknowledge the reality of your organization, and move forward from there

Alistair Cockburn, one of the signers of the Agile Manifesto and a huge inspiration for this book, is responsible for my very favorite prompt for scaling Agile in an organization. This prompt consists of four interrelated questions:

• Independent of anything else going on, how will you increase collaboration?

• Accounting for everything else going on, how will you increase trial and actual deliveries to consumers?

• How will you get people to pause and reflect on what’s happening to and around them?

• What experiments will your people do at different levels in the organization to make a small improvement?

These questions, particularly the preambles to the first two, send a clear and powerful message: “I know that our organization is hierarchical and siloed and blah blah blah, but holding constant for that, what can we do?” Simply framing questions through this lens of possibility always leaves you with a move to make, an improvement to suggest, or at least a conversation to have.

Don’t get hung up on tools and technologies

Different teams do different work and are often inclined to use different tools. It is not uncommon, for example, for engineering teams to use tools like Jira that might appear confusing and unwieldy to their less technical counterparts. But this should in no way limit the ability of teams to connect and align with one another. Look for opportunities to connect different teams’ toolsets to one another or to re-create the necessary information in a broadly accessible and technology-agnostic format such as Post-it notes or whiteboards.

Get leadership to model the behaviors you want to scale

As our First Law of Organizational Gravity suggests, people in an organization are much more likely to emulate what they see their leaders doing than they are to follow what they hear their leaders saying. Make a point of working with senior leaders to help them embody the Agile values that you want to see scale across the organization.

In many cases, simply reaching out to members of another team and asking to learn more about the way they work and the goals they are working toward is a valuable first step. An open line of communication can allow different teams to stay synchronized around their common goals even as they pursue different tools and tactics.

A Story to Bring It All Together: Enterprise Design Thinking at IBM

Sometimes, the organizational initiatives that most closely follow our guiding principles of Agile are not called “Agile” at all. When I asked Bill Higgins, distinguished engineer at IBM, about successful Agile initiatives he has experienced, one of his answers surprised me: it was a set of practices called Enterprise Design Thinking. I spoke with IBM Fellow and VP of Platform Experience Charlie Hill to better understand how IBM had combined elements of Agile and Design Thinking to bring to life the values of customer centricity, collaboration, and curiosity:

When we think about “velocity,” it is critical that we think about velocity in the market. The most important question for you to ask is, can you accomplish an outcome that a user would recognize as better than the other options available? And can you get it to that user before your competition does? Because if you can’t, it’s going to be a struggle. If you spend too much time measuring internal velocity, you risk falling in love with a very efficient process but losing sight of the market.

At IBM, we decided not to standardize on a specific Agile practice like Scrum, though Agile is widely used at IBM. And when we started to introduce designers to our product development teams, we decided that we would overlay onto whatever Agile practice a team had adopted a set of team practices that help us scale the user-centric ideas we learned from Design Thinking, not only at the individual Scrum-sized team level, but also at the larger, “team of teams” level. When you think about scaling any practices to that large “team of teams” level, you need to have a shared mental model of what you want to accomplish.

To provide this mental model, we created Enterprise Design Thinking. And to operationalize that model, we introduced what we call the Keys. The Keys are three core practices that we want every team to adopt: Hills, Playbacks, and Sponsor Users.

Hills are about setting a bold but achievable target outcome for a target audience of users and placing a bet on accomplishing that outcome for those users within a target timeframe. Note that the timeframe we set is always based on our understanding of the market, not about how fast we want to get things done for our own sake. So, we might say, for example, “Three months from now, we want the ability of our users to do X, Y, and Z in a 100% self-service way, with zero external support, in three minutes.” Something clear and finite, with testable success conditions where you can know for sure whether or not you accomplished it. It is then up to the team to self-organize and figure out how to do it.

Playbacks are a little like end-of-iteration demos, but encompassing the entire user experience. In a typical iteration demo, you demo the features you’ve built. A Playback is a level above that. It’s a walkthrough of the entire experience that a user has in accomplishing a goal, not just a walkthrough of whatever user interface happened to be built in the last sprint. So if the user has to drop out of the product you are building and use Excel to get something done, you need to show that, too. Everybody does playbacks now. It orients everyone on the entire team around what the user actually experiences or will experience. So whether you’re an engineer or an ops person or a marketing person, you’ll have a point of view on how effective the experience is and what it will take to deliver it.

Finally, with our Sponsor Users, we recruit prospective users who care enough that they’re willing to come to Playbacks and bring their expertise as a user into the conversation. So even though we’re also doing user research, testing, and so on, we’re also having a more organic interaction with users. It encourages a culture where we take the “voice of the user” literally because there is an actual user in the room.

We have applied these “Keys” to projects in a holistic way, and they work well together. For example, we might have a Hill that says, “An offering provider can onboard a new SaaS service onto our platform in a single day.” Now imagine having a Playback to walk through that experience—and having a business partner actually present in the Playbacks saying, “I wouldn’t really do it like that,” or, “that’s perfect.” That sort of interaction gives us clearer line of sight into our user needs, and these practices have brought operational clarity to the way we apply Agile and Design Thinking in a unified way.

This story is a fantastic example of how our three guiding principles of Agile can come together to have a major impact on a large organization. Here are a few things about this story that I find particularly inspiring and instructive:

It started with an explicit understanding that internal velocity was not the goal

Although many Agile initiatives begin with a desire to increase the speed of production, Enterprise Design Thinking began with an understanding that speed must be seen from the customer’s perspective.

It utilized the language that resonated best with the company

As we discussed in Chapter 1, the lens of Design Thinking is often most compelling to organizations looking to increase customer focus and usability. Instead of getting hung up on the formal differences between Agile and Design Thinking, IBM used the term that made the most sense for that particular organization.

It united people from different teams and functions around the customer experience

It’s difficult to imagine a practice that more explicitly ties together all three of our guiding Agile principles than the Playback. It encourages cross-functional collaboration, provides a planned opportunity to adjust course, and focuses both of these things around the customer experience.

It scaled through a “pull,” not just a “push”

Note the phrasing, “Everybody does Playbacks now,” as opposed to, say, “We made Playbacks a mandatory part of every team’s iteration process.” When a practice or set of practices is a good fit for an organization—and when it has the support of that organization’s leadership—it will naturally begin to scale and spread across teams.

The story of Enterprise Design Thinking is a great example of how an organization can pull from multiple movements and toolsets to develop a set of practices that meets its specific needs and goals. It is also a powerful reminder that the terminology we use to describe a set of practices is ultimately much less important than the impact those practices have on our colleagues and our customers.

Agile Practice Deep Dive: WHPI (Why, How, Prototype, Iterate)

When I was working as a product manager, there was no shortage of off-the-shelf Agile practices and frameworks I could bring to my team. These frameworks and practices spoke specifically to the needs of teams building software and had been road-tested by thousands of practitioners, many of whom were generous enough to share their experiences in readily accessible books and blog posts.

When my work shifted to focus primarily on consulting, however, it was not immediately clear to me how I could take these practices and apply them to very different deliverables made by a very different team. The kinds of deliverables we were producing—such as executive summaries of months-long embedded consulting engagements, or workshops to rapidly generate customer insights—were very different from software products insofar as there was no clear and objective way to test whether or not they were working. Additionally, our roles were far less clear-cut than those of a software development team, as we were all contributing in multiple ways without instructive titles such as “visual designer” or “frontend engineer.”

In the midst of this procedural ambiguity, we were struggling with a pretty common set of challenges for teams producing nontechnical deliverables. The scope of these deliverables seemed to be invisibly and inevitably expanding as we worked on them, especially as we moved from intermediate states like outlines to fully fleshed-out documents and presentations. The client-facing purpose of each deliverable was sometimes not entirely clear to us, which often resulted in us expanding scope even further just to make sure we “didn’t miss anything.” And, even though we all loved working together, it was not entirely clear who should be doing what, when, and why.

Although by-the-book Agile practices did not map perfectly to our team structure or deliverables, it was clear that the guiding principles of Agile could help steer us in the right direction. So, we began asking ourselves some of the very prompts that laid the groundwork for this book: are we starting with a clear sense of the customer (or in this case, client) need? Are we collaborating early enough to get out ahead of executional misalignments? And are we making sure that we have ample opportunity to incorporate new information in a way that does not feel like rework?

We began asking these questions regularly during our planning and retrospective meetings, and changing our practices accordingly. After a year or so of experimentation, we formalized our approach into a practice called WHPI (pronounced “whoopee!”), or “Why, How, Prototype, Iterate.” WHPI consists of four steps, summarized in Table 6-3. First, you collaboratively decide why you are creating a deliverable in the first place; what is the effect you are hoping this will have, and what value will it add for your client? Then, you collaboratively decide how you are going to deliver that value; what form will the actual deliverable take? Finally, you task a team member with creating a time-boxed prototype that replicates the experience you are seeking to create for your client and then iterate on that prototype based on how well it aligns with the goals you set during the first step.

We have found WHPI to be a powerful Agile tool that can be practiced by any team, regardless of the kind of deliverable they are tasked with producing. The sections that follow provide a brief walkthrough of how we approach each step as well as some notes about applying and adapting this practice to meet the needs of your own team.

Quick Wins to Put These Principles into Practice

Here are some steps that different teams can take to begin putting all three of our Agile guiding principles into practice:

For marketing teams, you could try…

…offering to write press releases or blog posts for products before they are actually finished to connect more closely with product and engineering teams.

For sales teams, you could try…

…inviting people from other teams to attend sales team meetings to create a better understanding of the sales team’s goals and operating procedures (whether or not they outwardly have anything to do with “Agile”).

For executives, you could try…

…asking your direct reports whether they feel that their rewards and incentive structures are aligned with Agile values.

For product and engineering teams, you could try…

…inviting your colleagues from sales, marketing, and customer support to share customer insights with you throughout the product development progress.

For an entire Agile organization, you could try…

…creating opportunities for representatives from different teams to share not just the work they are doing, but the way they are working as well.

Summary: Bringing It All Together

Taken together, our three guiding principles of Agile present a clear and strong mandate: work together to meet the fast-changing needs of your customers. This is, for reasons we have discussed throughout this book, easier said than done. But when we approach Agile with a sense of openness and possibility, we can always find new opportunities to change the way that we work for the better. And when we make the principles and values of Agile accessible to everybody, we are able to unite our entire organization around a shared vision of customer centricity, collaboration, and openness to change.