Escaping the Third Law of Organizational Gravity

Flexibility is one of the most obvious and well-understood reasons why organizations are drawn to Agile in the first place.  However, most organizations still struggle to actually change course in substantial ways, even when numerous people within an organization—including senior leaders—agree that adaptability is critical for that organization’s success.

The reason for this can largely be attributed to what I call the Third Law of Organizational Gravity: a project in motion will stay in motion unless acted upon by the senior-most person who approved it (Figure 5-1). In other words,  if a particular project, initiative, or product idea has the sign-off of a VP or C-level executive, it is likely to continue apace even if it is clearly not going to meet the desired customer need or company goal. After all, what’s the point of bringing bad news to your superiors when they will likely be held accountable for a project’s perhaps-inevitable failure?

Figure 5-1. The Third Law of Organizational Gravity: A project in motion will stay in motion unless acted upon by the senior-most person who approved it. Note all the lines of attention focused squarely on the highest point of the org chart.

Returning to our First Law of Organizational Gravity, the senior leaders who would need to intervene are often the farthest removed from direct interaction with customers. This creates a self-perpetuating system in which it is all but impossible for organizations to adjust course based on new learnings from their customers. By the time senior leaders get the feedback that should result in a course change, it has usually been scrubbed and sanitized to the point where it reads more like, “Great job, boss!”

This dynamic explains why people in organizations often continue to work on projects that they know are not going to succeed. It also helps to explain why embarrassingly bad marketing campaigns and #socialmediafails persist in this era of rapid customer feedback. In the calculus of organizational politics, public embarrassment can often seem less risky than telling your boss that something they signed off on is a bad idea.

Personal courage is certainly one way that individuals can work against this law of organizational gravity—but it is not enough. The only way to ensure that change will happen is to make change part of your process. In other words, those executives signing off on projects need to understand that making room for change is an inextricable part of the projects themselves. In doing so, adjusting course feels more like a commendable example of foresight, and less like a regrettable instance of failure.

Kathryn Kuhn, an experienced Agile practitioner and advocate who has worked with organizations like Teradata, Oracle, and Hewlett-Packard, described to me how a large financial services organization was able to better plan for uncertainty by adding shorter, quarterly cycles to their existing years-long planning cycles, and framing up this shorter cadence in a language that resonated with the organization itself:

We can’t always get an organization to stop doing years-long planning cycles. But we can get them to add a quarterly business review. It’s pretty simple—you start reflecting on how you did last quarter; then you bring in additional information that you want people to know. Maybe there’s a new Gartner study about how the market is changing, new regulatory requirements, new initiatives from company leaders, or new information about our customers. Bring that information into the room, describe what you’ve learned since the last time you discussed your plans, and then look ahead. Can you look at some of your initiatives and, based on what you now know, declare them “done enough”? If you’re 85% of the way toward achieving your goal with one initiative, can you strategically shift your resources to another initiative where you’re only 20% done?

With this approach, we were able to get the whole bank on a cadence of quarterly planning events. It gave them a way to address all kinds of things, like running through audits with thousands of remediations that would have previously ground the bank to a halt. Instead, they were able to pull the work apart in these quarterly planning events, realize what they could and could not get done, and knock off the highest-priority items. We could have a conversation about which features were customer-delighters, and what the scope of these features might be. We could discuss the trade-offs of each approach, rather than letting them get decided by inertia and inaction.

One key to our success was using the language of the organization itself—terms like “good enough for now,” and “done enough.” Or, “great idea, not yet.” This gave people a vocabulary to talk about prioritization without being too technical or too dismissive.

As this example illustrates, even in organizations that plan in year-long cycles, there is room to build in more frequent opportunities to share knowledge and adjust course. And, as we discussed in Chapter 2, incorporating language that is already well understood within an organization can help make new ideas and practices feel more approachable and applicable, even as they pose a substantial challenge to business as usual.

The Paradox of Agile: Using Structure to Achieve Flexibility

At the heart of most Agile methodologies is the somewhat paradoxical idea that a regular cadence creates more room for flexibility. This is because a fixed and finite cadence—like the Agile sprints we discussed in Chapter 3—makes responding to change a regular part of the way we work, not a challenge to the way we work.

When I began learning about Agile, I was concerned that a more fixed and frequent structure would make my team slower and less responsive. Committing to getting something done every two weeks felt much more rigid and regimented than planning to get something done roughly every couple of months or, even better, “whenever it’s good enough.” To my surprise and delight, though, a shorter fixed cadence actually resulted in my team making bolder and more exciting choices. We were able to build and test lightweight prototypes for new product directions, knowing that we could always abandon those directions if we learned that they were not adding value for our customers. And we were able to better plan around the quarterly and yearly goals of the organization knowing that we had the power to adjust course every couple weeks if we did not appear to be hitting those goals.

Sure enough, nearly all organizations operate under plans that extend beyond the two-week increments of a standard Agile sprint, whether it is a quarterly product roadmap at a small technology startup or a yearly budget for a large enterprise. Agile practitioners (especially newly indoctrinated ones who have been through a lot of training) often see any long-term cadence as a threat to true agility, and eventually declare that being truly Agile is “just not possible in an organization this large and bureaucratic.” Alan Bunce, a consultant and former marketing leader at organizations like IBM and Salesforce.com, described to me how the most successful Agile practitioners seek out a balance between long-term planning and short-term adjustment:

I’ve never worked at a place, no matter how “Agile,” where you didn’t start the year by thinking about what your budget’s going to be. Especially if you’re working at companies that are gearing up to go public, it’s not like you can say “Oh, we don’t know how much we’re going to spend—we’re Agile!” The way budgeting cycles are done, sales teams and executives think about what they think they can hit or what their targets ought to be for the year. Then, marketing’s budget is backed out from that.

Agile often carries this sense of, “Hey, at any moment we can do anything”—the reality is you can’t! You have a budget. And very quickly that budget starts to get carved up. That still leaves a lot of room for agility, but it’s by no means a blank sheet of paper. You need to strike a balance between long-term and off-the-cuff.

What that balance looks like will depend a lot on how an organization uses those long-term cycles. Are they chiseled in stone, or are they more guidelines, with an understanding there will be some adjustment? If those longer-term guidelines are used not as the absolute truth, but as a directional guide, that still leaves a lot of room for agility. But once things become fixed and bureaucratic, “you said $10.1 million, not $9.9 million,” then things get trickier.

As both this example and Kathryn Kuhn’s story from earlier in this chapter illustrate, having yearly plans in place does not mean that we must abandon our quest for agility. If anything, it means that we must be even more proactive and disciplined about establishing shorter cadences that we can use to keep our team’s work aligned with those longer-term plans—and to incorporate the new things we learn from our customers along the way.

Here are a few steps you can take to keep your team’s short-term cadences aligned with long-term goals and planning structures:

List out the fixed cadences of your organization and work with, not against, them

Does your organization have a yearly budgeting cycle? A two-year strategic planning cycle? A quarterly goal-setting process? Draw them all out on a sheet of paper and write down what is actually decided upon in each cycle, who is making those decisions, and what they expect as a result. Then, think about how you can build a shorter cadence around these cycles that creates more room for flexibility while respecting and accommodating organizational planning cycles that are unlikely to change.

Celebrate change

When we are planning only in long-term cycles, change of any kind can seem like a demand for frustrating rework. Adding shorter-term cycles allows us more time to get out ahead of changes to our initial plan and reconcile new information with our longer-term goals. We can draw attention to this newfound flexibility by celebrating change rather than decrying it. In other words, if we realize two short cycles into a much longer cycle that we have been on the wrong track, rather than saying, “Crap, there goes four weeks of work down the drain,” we can say, “We are so lucky that we caught this now and we can adjust course while there’s still time for us to hit our quarterly goals.”

Focus on what’s possible

The tension between short-term agility and long-term planning is one that never fully goes away, and inevitably creates situations in which your team cannot do the exact thing it wants to do at the exact time it wants to do so. But blaming the organization at large for not being as “Agile” as it should be is likely only to hurt your team’s morale and motivation. Instead, focus on what can be done given the real-world constraints of your organization.

In many cases, embracing this do-what’s-possible approach can actually help make long-term planning cycles more useful by clarifying their purpose and the expectations they create. As teams and organizations work toward finding the right balance of short-term and long-term planning, they are better equipped to understand and appreciate the value that both can offer.

The Double-Edged Sword of Experimentation

Inevitably, planning for uncertainty means making our best guess and moving forward before we know that everything we do will be a success. In many Agile and Agile-adjacent approaches, particularly the Lean Startup world, “experimentation” is often framed as the best way for teams and organizations to validate new product ideas and directions in a fast-changing world.

Real-life organizations, unfortunately, do not provide the pristine and sterile environs of a well-maintained laboratory. The idea of experimentation is an important one to bring to an organization, but it can also be a dangerous one if it imparts a sense of scientific certainty that ultimately contradicts the messy and fast-changing nature of the real world. At its best, experimentation can help us understand the uncertainty out there in the world, but it can never eliminate that uncertainty.

For teams and individuals looking to make definitively correct decisions, this can be a tough pill to swallow. And, sure enough, there are certain types of decisions that are easier to definitively prove out with an experiment than others. Deciding, for example, whether to make the “Home” button on a web page round or square would not be a particularly difficult thing to prove out via quantitative A/B testing. But suppose that you need to decide whether an entirely new line of business is worth getting into or whether an existing product will sink or swim when introduced to an entirely new market. While it is certainly possible—and worthwhile—to design an experiment that would help you answer these questions (the book The Lean Startup is full of great examples), no such experiment would give you the same sense of irrefutable and scientific certainty as that simple A/B test.

In theory, this should mean that teams and organizations wind up spending more time on the more difficult and ambiguous experiments that validate complex, market-based decisions. But in practice, it often means the opposite: teams and organizations wind up spending a disproportionate amount of time on the experiments that are easiest to validate in absolute quantitative terms, even if these are the least impactful for the business.

When my business partners and I are working with organizations, we often ask them to map out the experiments they are running on a quadrile we call Integrated Data Thinking, as shown in Figure 5-2. This quadrile maps out data-related initiatives along an axis from “discovery” to “optimization” and “qualitative” to “quantitative.” My Sudden Compass business partner Tricia Wang developed this framework after working with many organizations that had been inadvertently over-relying upon quantitative, optimization-level work such as A/B testing while neglecting the much more difficult and ambiguous work of validating discovery-level decisions and running experiments that are primarily proven out via qualitative data.

Figure 5-2. Sudden Compass’s Integrated Data Thinking model.

Nearly every company with which we have run this exercise winds up with a completed quadrile that leans very heavily toward quantitative optimization at the lower right. But when we ask those same organizations to map the business questions that are keeping them awake at night along the x-axis from discovery to optimization, the quadrile leans just as heavily toward discovery on the left. It is not uncommon, for example, for an organization to be most preoccupied with major discovery-level questions like “How can we grow our business into new markets” while running the vast majority of its experiments around incremental optimizations to existing products, markets, or messages. Simply acknowledging this disconnect is often enough for individuals to take notice and start exploring new ways to run qualitative and discovery-level experiments in the upper-left quadrile.

Unsurprisingly, one great example of such an experiment comes directly from the Lean Startup world. Former Lean Startup Productions CEO and cofounder Sarah Milstein described to me how she was able to run simple, low-cost experiments to validate new product ideas, and how qualitative data often factored into these experiments:

When we were launching a new conference as part of Lean Startup Productions, we had the idea that we should sell tickets for a remote version. We didn’t think it would be terribly popular, so we hypothesized that we would sell about 10 tickets. And the day we put it up for sale, we sold 100 tickets. This was a really big sign for us that our thinking wasn’t caught up to where our customers were. And if we didn’t have a hypothesis, 10 and 100 would have looked the same. This kind of hypothesis-driven experiment is just as valuable if it turns out you’re wrong—you’re not even aiming for rightness necessarily, you’re aiming to gauge where your current thinking is in relation to the actual customer you are serving.

It’s also worth noting that people can get fetishistic about experimentation pretty easily, to the detriment of its purpose. Sometimes, an experiment can be much more about qualitative signals; for example, the way people start using a phrase that’s in your marketing materials. This approach is officially called “artifact analysis.” If we change the wording on our website to “inquiries,” for example, will the content of the emails we receive start to be different? We don’t always have a number, but we know what we’re looking for and why we’re looking.

As this story illustrates, the easiest things to test and measure are not always the most important things to test and measure. When we begin by asking the questions that are most important to our business and our customers, not the questions that seem easiest to answer with a quantitative experiment, we are being true to the complexity and uncertainty of the world around us.

Agile Is Uncertain, Too

Perhaps the most common antipattern I’ve seen in organizations seeking to implement Agile practices goes a little something like this: “We understand that the world changes quickly, so we are going to implement a set of Agile practices…that are guaranteed to work forever and that we will never need to change.” Planning for uncertainty in our organizations also means planning for uncertainty in the way we approach Agile—which can be very challenging for organizations that see Agile as a box they can check off rather than an ongoing journey that will itself require a constant embrace of change.

To navigate this change, teams and organizations must take shared ownership of the processes they use, and build enough trust and transparency to speak candidly about what is working for them, what is not working for them, and why. This is often difficult to accomplish when Agile is seen as simply a mandate that comes down from on high or is brought in by an army of external consultants. Even when a team of well-intentioned practitioners is driving the adoption of their own Agile practices, taking time to reflect on and refine those practices can prove challenging. Abhishek Gupta, an engineering manager who has worked with companies like Apple and American Express, described to me how opening a conversation about the goals of a team’s Agile practices can lead to difficult but important changes to that team’s routines and rituals:

One big challenge with Agile is that it becomes a set of things you need to do, without an understanding of the “why.” This is made even worse when Agile is treated as a silver bullet. “Our projects will be great, because we’re doing Agile!” That doesn’t translate if the spirit isn’t there. For people who deeply care about product quality, Agile is a means, not an end. To confuse the process and the outcome is at the core of the problem here. If you don’t care about product quality, if you don’t care about delivering value to your customers, then Agile won’t save you.

I worked with one team that had been “doing Agile” for a while when I started working with them. I asked them, “Is this something you see as valuable?” And the initial responses I got were, “Oh yes, very, very valuable.” So for two months, I attended their Agile meetings to see what was working well for them. Every meeting was a similar thing; show off your tickets in [software development tool] Jira, say what are you working on, is it done, is it not done. The team was much more focused on closing actual tickets than they were on understanding the impact of the work they were doing; it was a lot of process management without giving much thought to actual outcomes. In other words, it was a lot of busywork.

So, after a few months, I had to say to the team, “How is this actually useful to you?” I had a lot of one-on-one meetings with engineers asking for this kind of candid feedback. And what I heard was that they found it useful to not have to work on too many things at once, to be able to know what they were working on, and have that kind of focus. So we talked about how we could retain that focus, but bring in more big-picture, directional thinking to make sure that focus was understood through the value we were creating for our customers. This meant stepping away from a lot of by-the-book Agile rituals, and asking as a team, “How can we work in a way that best achieves the outcomes we want for ourselves and our customers?”

Indeed, truly embracing the Agile principle of planning for uncertainty means that we must regularly ask our teams that very question, and be open to our answer changing as our goals, our teams, and our customers change. In most cases, this eventually involves giving up the sense of comfort and safety that comes from doing Agile “by the book” and finding the particular set of practices that works best for the individuals on our team. This can be a scary step, but it is worth remembering that the set of practices and frameworks that we now call Agile were themselves developed through trial and error by practitioners before the word “Agile” was ever used to describe them. When we understand our organizational needs and we follow our guiding principles, we open ourselves up to discovering new ways of working, and we empower our teams to feel ownership over them.

Agile Practice Deep Dive: The Retrospective

If Agile is the engine that helps you achieve escape velocity and overcome the laws of organizational gravity, the retrospective is the valve that stops that engine from overheating and burning out. A retrospective is a meeting at the end of a sprint or the completion of a project during which a team reflects on the way they work together and identifies changes they can make for the next sprint or project. Note that the goal of a retrospective is explicitly not to critique the actual work that was just completed, but rather to reflect on how the team completed that work.

The retrospective constitutes an important opportunity for teams to build a shared sense of purpose and ownership around the way they work. It is a chance to first ask the question, “Is the way we’re working helping us live up to our principles and achieve our goals,” and then, “What are we going to do about it next time?”

For many teams I’ve worked with, especially those outside of product and engineering, speaking openly about what is and is not working can be an uncomfortable prospect. People often assume that the way they currently work must have been put into place for a very good reason, and that questioning it might amount to undermining somebody else’s experience or authority. But I have been truly amazed at how many times a particular practice or artifact—like a regularly scheduled meeting that provides no real value or a campaign planning template that demands way too much information—turns out to be a simple historical accident that nobody has felt empowered to reevaluate. I have participated in many retrospectives, for example, in which somebody sheepishly suggests that a long-standing practice is no longer serving the team, only for everybody else in the room—including that team’s leader—to react in swift and violent agreement. Moments like this can have an immediate and incredibly positive effect on a team’s morale and productivity, but they simply do not occur unless you create space for them.

One of the fantastic things about retrospectives is that you can run them at the end of any project, regardless of whether that project involves any other Agile practices. Adding a retrospective to any regularly scheduled work such as a monthly newsletter or quarterly planning meeting can open up a new kind of space for teams to discuss how they work together and why. Emma Obanye, founder of Mindful Team, explained to me how she came to value the retrospective as one of the most important tools for building trust and communication on a team:

Most issues can be solved with communication, and a lot of companies miss the human side of things. They think that Agile is going to make people faster, but people are not robots! And there are a lot of silly issues and miscommunications that can become big problems unless you bring people together for an open dialogue. Sometimes, just the safety net of being able to express yourself in front of your team is enough to get started—and once you have that, you start to get a team into the state of flow. And for me, that starts with the retrospective. Each Agile ceremony has its reason. But to me, the retrospective is the key to continuous improvement. Without that, a strict and regimented framework is all you’ve got.

We’ve talked to a lot of Scrum masters who have trouble communicating the value of Agile to their teams. And if you have that problem, you need to start from the beginning. You need to open up that dialogue, and give everybody on the team the opportunity to say what they really feel. There will almost certainly be conflict, but that conflict is good—it’s what drives you to the next level. Without bringing that conflict into the open, a lot of teams are stuck in that first level, unable to work through the very first challenges that they find in an newly formed team.

Retrospectives are often challenging for the very reason that they are ultimately so valuable: they open up a space where people can voice their doubts, questions, and uncertainties about the way that they work together. These conversations are rarely comfortable, and they rarely yield easy or certain answers. But the simple fact of the retrospective is often enough to begin addressing the unspoken beliefs and assumptions that can leave teams feeling stuck and disempowered. Here are a few tips for keeping your retrospective on track:

Model vulnerability and uncertainty

If you are the person bringing Agile practices to your team, your teammates look to you to understand how they are “supposed” to behave during a retrospective. This might leave you feeling like you need to have all the right answers, or to defend the Agile practices you’ve introduced. But the best thing you can do for your team is to model the kind of openness and honesty that will enable you to continuously adapt and improve. If somebody asks about a particular practice and you don’t have a good answer, feel free to say, “I don’t really know. What does everybody else think?”

Stay focused on what you are going to do next time

In many organizations, taking time to reflect on the way a team works only happens when there is a major problem. As a result, retrospectives can devolve into evasiveness and finger-pointing. The engineering teams at Etsy solved this problem by holding what they call “blameless postmortems,” in which participants can openly reflect on mistakes they made without fearing retribution. But another step you can take to avoid the blame game is to shift the conversation toward what you will do differently for the next sprint or project. For example, “Regardless of who was responsible for what happened last time, what can we all do together next time to make things better?”

Treat future changes as experiments, not mandates

Regularly scheduled retrospectives provide your team with the opportunity to adjust course after each sprint or project. This means that there is very little risk associated with trying a new practice or approach; after all, if it isn’t working, you will have the opportunity to change it or roll it back during your next retrospective. Remind your team that every change you make is essentially an experiment; you won’t know whether it works until you try it, and you are prepared to adjust course based on what you learn.

Keep your principles in focus

I’ve often found it helpful to have my team or organization’s guiding Agile principles physically present during a retrospective. This helps to keep the team focused not just on how they are working together, but also on why they are changing the way they work in the first place. These principles can also serve as a powerful mediator when there is a disagreement, enabling you to ask, “Which of these approaches is most aligned with our guiding principles?” rather than, “Which of these approaches do we like more?”

Hold space for what is working

Although running a retrospective is a critical way to adjust course when things are not working well for your team, it is also a critical way to acknowledge the things that are working well for your team. One approach I’ve found helpful is to ask each team member to quickly write down three things that worked well and three things they think could be changed for the next sprint or project. This gives equal time to the things that are worth protecting and the things that stand to be refined.

Break the ice

A team’s first couple of retrospectives can be particularly awkward. Sometimes, it is helpful to bring a sense of fun and ease to a retrospective by starting with an icebreaker, or framing the retrospective itself as a kind of game. Mindful Team, whose cofounder Emma Obanye provided the insightful commentary about retrospectives earlier in this chapter, offers a card game called The Retrospective Game that can provide a great first step for teams that are not used to sharing reflections in a group.

Finally, and perhaps most importantly, resist the temptation to cancel your retrospectives if you have a lot of work to do. For teams and organizations that see Agile just as a means to increase velocity, the retrospective can seem like a waste of productive time—after all, you aren’t actually making anything, just sitting around and talking about how you make things. But making time for a team to reflect on how it works is a non-negotiable if you want that team to embrace any new ways of working. In the absence of a retrospective it is inevitable that any set of Agile practices will fail to achieve their full potential, as the team implementing those practices comes to see them as just another form of “business as usual” that they are powerless to question or adapt.

Quick Wins to Put This Principle into Practice

Here are some steps that different teams can take to begin putting our Agile guiding principle of planning for uncertainty into practice:

For marketing teams, you could try…

…setting a regular cadence to reevaluate big-picture questions, such as “What is our brand promise?” and “What is our brand voice?”

…providing real-time feedback on the performance of active campaigns during daily or weekly meetings. (Thanks to Andrea Fryrear for this suggestion!)

For sales teams, you could try…

…assembling small “SWAT teams” of salespeople designed to test new products and markets. (Thanks to Alan Bunce for this suggestion!)

...running a retrospective after an important pitch or sales call.

For executives, you could try…

…communicating clearly what is set in stone and what is subject to flexibility during long-term planning cycles.

For product and engineering teams, you could try…

…setting aside one sprint to prototype what your product would look like if you had the opportunity to reinvent it from scratch.

For an entire Agile organization, you could try…

…creating temporary, cross-functional tasks forces to run shared retrospectives on projects that involve work from multiple teams.

…explicitly including opportunities to reevaluate the overall course of a project within every new project plan.

Summary: Change Is Good, If You Want It

In the wise words of psychologist Virginia Satir, “Most people prefer the certainty of misery to the misery of uncertainty.” Agile gives us a way to make uncertainty appreciably less miserable by giving ourselves consistent and predictable opportunities to incorporate new information from an inconsistent and unpredictable world. When we embrace the idea that more structure can ultimately offer us more flexibility, we can use the day-to-day practices of our team as a tangible lever to reduce our fear of change and the missed opportunities that come with it. Planning for uncertainty turns fear that new information will derail our progress into gratitude that new information can be incorporated into our work before it is too late.