Escaping the Frameworks Trap

This is how we’re doing things, so get out.

This was the message given to an experienced Agile coach tasked with transforming a transportation company in the United Kingdom. His crime? Asking why.

This company, like many companies, had picked out an Agile framework that it was convinced would deliver the speed and flexibility it desired. The framework this company chose came with new, fancy vocabulary. It came with a set of easy-to-follow rituals. It came with the promise that if these rituals were observed to the letter, this company would be able to work faster and more efficiently than ever before.

But this Agile coach, having been through this kind of thing before, was not interested in following the letter of the law without having a candid conversation about the intent of the law. “Why did we choose this particular framework?” “What are the principles we are following in our implementation?” “How will this be different from the way we are currently working?” These were the exact questions that members of this team did not want to ask, and they made this known in no uncertain terms.

Six months later, another Agile coach working with the same company returned to check on its progress. This Agile coach described the situation to me as follows:

They had become “experts” in the methodology they chose—but they were basically doing everything the same way that they had before, just with different jargon. “Instead of doing this meeting, we’re going to do THIS one.” Same meeting, different name. “Instead of doing this documentation, we’re going to do THAT documentation.” Same documentation, different name. They had done nothing to address the fundamental challenges that they were facing as an organization, and had done nothing to create a more accessible, open, and transparent culture. Instead, it was all about playing work, having this new title, having this new lingo.

Without even realizing it, this company had fallen deep into the frameworks trap: implementing a specific set of Agile practices without taking the time to understand the underlying issues that it was actually trying to address, or the principles that it would follow to address them. As shown in Figure 2-1, organizations often approach new frameworks and practices in the general hopes of being faster, more flexible, and broadly better than they were before, only to find themselves right back where they started.

Figure 2-1. The frameworks trap—rinse and repeat!

As this story illustrates, organizations often fall into the frameworks trap not only because they believe a single framework will magically solve all their existing problems, but also because they actively resist having a conversation about what exactly their existing problems might be and how Agile might help them solve those problems.

It is for this reason, perhaps, that many organizations and teams find it safer to approach Agile as a set of operational rules rather than as a movement guided by principles and values. In a blog post titled “The Failure of Agile,” Agile Manifesto signer Andy Hunt describes why the “joy of rules” can lead organizations to superficial and ultimately fruitless implementations of Agile practices:

Instead of looking up to the agile principles and the abstract ideas of the agile manifesto, folks get as far as the perceived iron rules of a set of practices, and no further.

Agile methods ask practitioners to think, and frankly, that’s a hard sell. It is far more comfortable to simply follow what rules are given and claim you’re “doing it by the book.” It’s easy, it’s safe from ridicule or recrimination; you won’t get fired for it. While we might publicly decry the narrow confines of a set of rules, there is safety and comfort there. But of course, to be agile—or effective—isn’t about comfort.

Indeed, any rules that are followed without a clear and well-understood purpose are useless by their very nature because their intended use has never been defined. As Hunt suggests, this entirely rules-based approach allows teams and organizations to superficially adopt “correct” practices without interrogating what was “incorrect” about the way they were accustomed to working, ultimately leaving any and all underlying issues unaddressed. This is a painfully common pattern for “organizational transformations” and reorganizations of all kinds, including but by no means limited to those labeled “Agile.” Here are four common signs that you might be falling into the frameworks trap:

That last framework or methodology you tried was a disaster, so you’re trying a new one!

Teams and organizations stuck in the frameworks trap often have very strong opinions about the frameworks and methodologies they’ve implemented in the past. “Oh yeah, we tried Scrum, and it was a total disaster—so now we’re switching to a scaled framework.” A few months later, “That scaled framework we chose just had nothing to do with the way we work, so we’re going to try out a different one.” Usually, by the third or fourth failed Agile initiative, you begin to hear things like, “I just don’t understand all this hype around Agile, but we just spoke to a consultant who specializes in Lean Six Sigma, and I think that’s going to be a much better fit for us.” Meanwhile, business as usual continues.

“Talking Agile” is considered “being Agile”

Organizations that implement Agile superficially often become fixated on that most superficial of all things: jargon. Agile terminology is trotted out relentlessly at meetings, and anybody who furrows their brow at the idea of “daily scrum meetings” or “time-boxed iterations” is met with a dismissive eye-roll or smug smirk. Those who dare to ask “why” are accused of “not getting it.” Nonetheless, business as usual continues.

Conversations about what isn’t working for this organization are rebutted with tales from other organizations

“This framework completely transformed Company X” can be a persuasive argument, especially when voiced by somebody who actually worked at Company X. Not wanting to push back against something that has been proven to work (or, at least, is the subject of a glowing case study), organizations will often double down on frameworks and practices that are quite obviously not delivering positive outcomes. Faced with this disconnect, employees are left to conclude that they will simply never be as adaptable, as innovative, or as successful as Company X. Business as usual continues. (Though, come to think of it, if Company X is so great, why did the person who’s pushing all this Agile stuff leave there to come work here?)

Adopting Agile practices is seen as an intrinsic goal, not a means to an end

In some cases, organizations stuck in the frameworks trap feel that their Agile journey has been very successful. All of their teams have adopted Agile! They’re checking the boxes for all the most important Agile rituals, like having daily stand-up meetings, working in sprints, and holding retrospectives! And yet nothing really seems all that different. New cross-functional teams are just as siloed as the old functional teams. Work is delivered in two-week increments, but planned in two-year cycles. The organization has “gone Agile,” but business as usual continues.

Although it is appealing to think of Agile as a revolutionary one-size-fits-all solution to the challenges facing modern organizations, simply applying the superficial practices and lingo of Agile without asking “why” all but guarantees that you will find yourself stuck in the frameworks trap. The only way for Agile to meaningfully change the way a group of people works together is for that group to understand its own needs, its own goals, and how its current practices are stopping it from achieving those goals. As shown in Figure 2-2, working together to gain this understanding can help organizations escape the frameworks trap and accomplish meaningful change.

Figure 2-2. Two “off-ramps” for escaping the frameworks trap: making it count, and making it your own.

In this chapter, we look at two “off-ramps” that we can take to escape the frameworks trap: making it count, and making it your own. Both of these steps serve to anchor Agile practices to Agile values as well as to the specific needs and goals of our organization, thus preventing the frameworks trap from perpetuating an endless untethered cycle of superficial change.

Making It Count: Establishing Your Goals and Challenges

Many companies are drawn to Agile because they see it as a way to be faster and more flexible. But “faster” and “more flexible” are very broad goals that can mean different things to different organizations. What are the specific goals we have with respect to speed and adaptability? How will we know when we are achieving those goals? And, critically, what about the way we are currently working is preventing us from reaching those goals? Without asking these questions, organizations can spend millions of dollars and thousands of productive hours wildly firing silver bullets, without ever asking where they should be aiming in the first place.

Any successful implementation of Agile should begin with a hard, honest look at what is currently working and what is currently not working. If you see Agile as a trivially demanding operational add-on to your current way of working, the value you derive from it will be just as trivial. Changing practices without challenging the underlying beliefs and expectations that motivate those practices all but guarantees that people will revert to their current state, no matter how many fancy new frameworks you try. Before you implement any specific Agile practices, be prepared to ask and answer the following questions:

• What is the desired future state of our team or organization?

• What is the current state of our team or organization?

• Why do we believe that we have been unable to achieve the desired future state of our team or organization?

These questions are often difficult to answer. Most of us know that we want the way we work to be better, but actually imagining what “better” might look and feel like often means calling into question the deeply held beliefs, expectations, and behaviors that provide us comfort and stability. Indeed, it is not uncommon for people to be very excited about the general idea of positive change but deeply skeptical and resistant to any specific change. In my experience, this skepticism tends to cluster around a few consistent themes:

“We are too hierarchical”

There is no easier way to outright dismiss the possibility of change than to preemptively insist that such change will be scuttled by the powers that be. “We are too hierarchical” is often shorthand for “I am doing my best to work within the parameters and incentives provided by management, and I am afraid of what might happen if those parameters and incentives change.” This is a great opportunity to open up a conversation about what aspects of their work your colleagues perceive to be within or outside of their control, and to discuss what kind of change feels possible and desirable within those constraints.

“We are too siloed”

Just about every organization struggles with functional or project-based silos. Agile is often perceived as offering an easy operational solution: reshuffle people from their functional silos into small, cross-functional teams. But these teams can easily become their own silos if the underlying cultural issues are not addressed. As we discuss in Chapter 4, there are real and valid reasons why people do not often venture outside the comfort of their immediate teams. Understanding what those reasons are in your organization is critical for thinking through what Agile practices you will deploy to break down organizational silos, and what steps you can take to ensure that cross-functional teams don’t become their own silos.

“We are too heavily regulated”

For people working in industries like banking and healthcare, strict regulatory requirements can seem like an impossible obstacle to overcome. But there are still plenty of opportunities to bring Agile principles and values to these industries, even if the specific manifestations of those principles aren’t “by the book.” Acknowledging the fixed constraints of your organization out of the gate can help you ask “what can we do,” instead of throwing in the towel as soon as you encounter an Agile practice that would be rendered impossible by regulatory issues.

“We tried to do this before, and it didn’t work”

In some cases, there simply is not a widespread belief that change is desirable, or possible. This is particularly true in organizations that have been through the ringer of the frameworks trap multiple times. In cases like this, it is critical to look at why past change initiatives have not succeeded—and to do so in a way that is open, honest, and reflective beyond “we picked the wrong framework.”

If they are brought to the surface early enough, these common reasons for resisting or doubting change can help you understand exactly what kind of change your organization needs. For example, I have worked with several marketing teams that feel too far removed from their counterparts in product to effect real change for their customers. With this concern brought to light, we have ultimately been able to prioritize tactical steps—some as informal as “email somebody in product and see if they want to grab coffee”—that can contribute to a newfound sense of possibility and momentum. Beyond that, we have been able to model from the outset that giving voice to the challenges we are facing will not impede our Agile journey, but rather direct and accelerate it.

Making It Your Own: Agile Principles and Values to Drive Change

After you’ve taken the time to articulate the goals of your team or organization, it is time for you to address how Agile might help you to meet those goals. At this point, it can be tempting to jump directly to a framework or set of concrete practices. But doing so misses out on a crucial step: defining the values and principles of Agile in a way that will resonate for your particular organization. For some organizations, the Agile Manifesto does this quite handily. For other organizations, the Manifesto is not nearly specific enough—as one Agile practitioner I spoke with put it, “Who wouldn’t say that they value individuals over tools?”

Many Agile practitioners will rightly point out that opening up the core ideas of Agile to any kind of rewording or reframing is a dangerous game. After all, what is to stop people from declaring “Agile” to be whatever they want it to be? What is to stop people from cherry-picking the easiest parts of Agile and ignoring the rest? And what is to stop people from sanitizing the values and principles of Agile so completely that they present no substantive challenge to “business as usual,” resulting in the very kind of superficial implementation we discussed earlier in this chapter?

These are important questions and real concerns. But in my experience, asking the question, “How can we frame the values and principles of Agile in a way that will help our team or organization meet its goals?” can bring to light the doubts and disconnects that might drive people to ignore or undermine Agile practices once they are introduced. It gives us a way to engage with potential naysayers while we are still having a high-level discussion about principles and values, helping to create a shared sense of accountability. And most importantly, it helps to mitigate the very real risk that off-the-shelf Agile values and principles will seem vague, unrealistic, or completely irrelevant to our colleagues. As Jodi Leo, an experienced UX practitioner and educator who has worked with organizations like Nava PBC, Apple, Google, and the New York Times, told me, “Things always start to go sideways when Agile paradigms are introduced that have absolutely nothing to do with the way that a company is set up to work.”

It is important, then, to have a clear sense of whether we are specializing our Agile principles and values to maximize their impact, or sanitizing them to avoid challenging the status quo. To provide an example of the latter, some teams I have worked with have suggested completely removing any references to “collaboration” from their Agile principles and values because they fear that organizational leaders will assume this to mean “more meetings.” But this very fear reveals an unmet need to define “collaboration” in a way that will challenge those assumptions. Crafting a specialized principle such as, “We will use our time together to collaboratively shape works in progress, rather than only sharing things that are finished and polished,” gives us a chance to frame up the broad idea of collaboration in a way that speaks to the specific needs and goals of our team—which, by this point, we have already had the opportunity to articulate.

Therein lies the critical difference between specializing and sanitizing, as shown in Table 2-1. When we specialize the general values and principles of Agile to make them our own, we are looking to preemptively resolve and address any disconnects that might serve as future excuses for reverting to business as usual. When we sanitize the general values and principles of Agile, we are already making excuses for why we cannot meaningfully challenge business as usual.

The chapters that follow break down Agile into three guiding principles that represent my own attempt at capturing the Agile movement in terms that are broad enough to be accessible to all functions and organizations, but specific enough to be actionable. But to be clear, these principles will be much more valuable if you make them your own. Maybe, for example, simply referring to “our customers” is too broad or not applicable for your organization, and you want to change it to “user experience” or “value for our clients.” Great! Maybe the “collaboration” you need most immediately is between individuals from specific teams or functions, and you want to codify that in your guiding principles. That’s great, too! You have still captured the general ideas of customer centricity and collaboration, and you have done so in a way that will be clear and actionable within your particular organizational context.

Summary: Agile Beyond the Frameworks Trap

Escaping the frameworks trap requires taking two steps before you begin looking into specific practices and frameworks:

1. Taking an honest and hard look at what you want your team or organization to look like and what has stopped you from getting there.

2. Adopting (and, if necessary, specializing) a set of guiding Agile principles that you can follow in order to move your team or organization toward your stated goals.

After these two steps are in place, you can commit to a set of practices that will put these principles into action, and work collectively to change these practices if they fall out of synchronization with your guiding principles.

In the next three chapters, we explore three general guiding principles of Agile, some practices that support them, and some common success signals and warning signs that you can use to keep your team or organization on track.