Debunking Three Common Myths About Agile

Over the past decade and a half, the word Agile has gone from a tactical distinction among software developers to an inescapable nugget of business jargon. Before we talk about the specific history of Agile and how we can use its core values and principles in our work, let’s look at a few common myths and misconceptions about Agile that I’ve encountered many, many times:

Agile is a rigid and prescriptive methodology

Fun fact: Agile is not really a methodology at all. As we will discuss, Agile is a movement that began when people who had worked on multiple software development frameworks and methodologies came together to discuss the common values expressed in their respective approaches. Many practices that are implemented under the guise of “doing Agile” actually run fundamentally counter to these values.

Agile is a way to do more work, faster

On numerous occasions, I have stood in meetings while senior leaders describe Agile as a way to “increase our output” or “get things done quicker.” If I could capture the looks on the faces of senior developers during these meetings, I would be happy to simply present them as the entirety of this chapter and call it a day. Agile is not a matter of working more or of working faster, but rather of working differently. In fact, following the core values of Agile often means slowing down, at least momentarily, to reflect on how we currently work and how we could work better.

Agile is only for software development teams

Because the Agile movement emerged from software development, people often assume that it is relevant only to software development. This is not at all true. In fact, when software development teams implement Agile practices in a way that disconnects them from the broader organization, they too are often “doing Agile” in a way that actually runs counter to the core values of Agile.

Turning to the Agile Manifesto

The Agile movement kicked off in earnest in 2001, when a group of 17 software developers gathered together at a ski resort in Utah to discuss alternatives to the “documentation driven, heavyweight software development processes” of the day. The resulting Agile Manifesto reads, in its entirety, as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

It is worth taking the time to read this over thoroughly, many times. More than once, I’ve had it taped up over my desk as a team with which I’m working begins to explore Agile practices and methodologies. Fundamentally, Agile is not about following a single prescriptive set of rules; rather, it is about designing and implementing practices that align with a set of values. Core to these values—and reinforcing the approach to product management described in this book—is the embrace of human complexity. Truly valuing individuals means looking beyond titles and org charts to understand the actual people with whom you’re working. Processes and tools can help facilitate our connection with those people, but they cannot replace that connection.

Here’s my very favorite thing about the Agile Manifesto: it actually came after the development of some of the most popular Agile development methodologies such as Scrum and XP. When the people who developed these methodologies met up, they didn’t argue incessantly over why “Scrum is for kindergartners” or “XP is just way too difficult for real-world organizations.” Instead, they were able to reach a clear and definitive agreement about the core values that these methodologies share. Feel free to bring this up the next time you see product managers engaged in a heated debate over which Agile methodology is “the best.”

From Manifesto to Monster

Those who have spent a good deal of time navigating the world of Agile software development and “Agile business transformation” might note the irony in the Agile Manifesto citing “individuals and interactions over processes and tools.” In the years since the Agile Manifesto’s signing, the Agile ecosystem has become a dizzying Lovecraftian swirl of frameworks, practices, tools, and certifications. This irony is not lost on many of the people who actually wrote the Agile Manifesto. And even if you suspect me of being a process-hating anarchist, surely you must be interested in what they have to say. To that end, Agile Manifesto signer Andy Hunt wrote a blog post called “The Failure of Agile” that lays out his perspective on how a set of inspiring ideas got turned into a prescriptive ideology that fundamentally violates its own core values:

In the 14 years since [the Agile Manifesto], we’ve lost our way. The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they’ve forgotten their aim. And worst of all, agile methods themselves have not been agile. Now there’s an irony for you.

Hunt goes on to describe why he feels that Agile has been so badly misinterpreted:

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.

Again, we return to our first guiding principle: clarity over comfort. As we discussed in Chapter 8, clarity does not mean absolute unflinching certainty. Achieving and maintaining clarity is ongoing, difficult, and at times deeply uncomfortable work. At its best, Agile provides us with a way to value and protect that work. But it cannot do so if we turn to it only for certainty, for absolutism, for “the right way to do things” regardless of the specific individuals involved.

Using Alistair Cockburn’s “Heart of Agile” to Bridge Values and Practices

The tragedy of Agile’s sloganization is that many of the practices used in Agile software development really can help us enact its stated values. Alistair Cockburn, another signer of the Agile Manifesto, responded to what he called the “overly decorated” state of modern Agile by distilling the entirety of Agile practices and processes into four actions at the “Heart of Agile”:

• Collaborate

• Deliver

• Reflect

• Improve

Cockburn explains how the simplicity of these four actions provides a needed counterpoint to the jargon-heavy discourse around modern Agile practices:

The nice thing about these four words is that they don’t need much explanation. They don’t need much teaching. With the exception of “Reflect,” which is done all too little in our times, the other three are known by most people. You know if you’re doing them or not. So simply saying, “Collaborate. Deliver. Reflect. Improve.” already says most of what you need to say and do.

These four actions provide a bridge between the values of the Agile Manifesto, and the practices that come with specific Agile frameworks and methodologies. They get to the very, well, heart of what separates Agile from the siloed, heavyweight processes that came before it and still persist in its wake. And, most important, they provide a simple and plainspoken yardstick against which you can measure the success of any specific Agile initiative.

One of my very favorite things about Agile—and about Cockburn’s “Heart of Agile” in particular—is that it contains within it the blueprint for its own success. If you are taking time to truly reflect and improve, then wherever you start, you will wind up somewhere better. The single biggest mistake I’ve seen organizations make when implementing any kind of Agile process is to take an all-or-nothing approach in which a framework or set of practices is implemented and then declared an outright failure when it does not work perfectly right away. If, per Cockburn’s actions, you don’t take the time to reflect on the way you’re working and improve the things that don’t work, then any Agile practices will stagnate, fall into disrepair, and ultimately fail to have any real impact.

Four Steps to Future-Proof Agile

Depending on the specifics of their role, a product manager might have more or less direct authority over the Agile rituals, practices, and methodologies used by their team and organization. But it is critical to remember that reflecting upon and improving Agile practices is, itself, an Agile practice. Even if you see yourself as simply being a practitioner of Agile, thinking about how you can improve the way your team works is still part of your job.

Here are the four steps that I’ve seen lead to the most successful Agile adoptions for large and small organizations alike.

1. Begin with a “North Star” such as the Agile Manifesto or the “Heart of Agile”

   Before rushing to implement specific rules or methodologies, share a high-level vision for why you are making these changes in the first place. This can be the Agile Manifesto, or Alistair Cockburn’s “Heart of Agile,” or anything else that provides guidance on the order of values, principles, and outcomes, as opposed to practices, ceremonies, and outputs. In the absence of this North Star, it is impossible to know whether the specific practices you are implementing are actually helping you achieve your goals—because nobody knows what your goals are in the first place.

   I recommend putting some kind of visual reminder of your North Star—such as a poster of the Agile Manifesto or a visualization of the “Heart of Agile”—somewhere central and visible to your entire team. This helps create a shared sense of purpose and accountability, and prompts your team to constantly reflect on why it is adopting any specific practices or ceremonies.

2. Pick an off-the-shelf Agile methodology

   Pick a methodology—any methodology! Because you’re committed to adapting as necessary based on what is or is not helping you achieve your goals, you don’t need to worry all that much about where you choose to begin. As a rule, though, I would recommend starting with an existing, well-documented methodology like Scrum or XP. Starting with something that already exists and is well documented gives you a “referee” to settle any initial confusion or disagreement—which in turn makes it easier to be very clear about what is working and what is not working.

3. Regularly evaluate the specifics of that methodology against your North Star

   In most Agile methodologies, there is a “retrospective” in which the team commits to changing how it will work moving forward. I’ve seen many product managers either half-ass the retrospective or omit it altogether, because it does not involve actually producing software. Often, this is because the mandate they have been given is to work faster, so anything that does not involve cranking out product is seen as a waste of time. This might feel like a defensible short-term optimization, but it has serious ramifications in the longer term. Without making time to reflect and refine your process, that process will eventually fall apart. And without having that initial North Star against which to evaluate the specific practices you’ve chosen, you can easily fall into the trap of constantly changing course without knowing which way you’re actually headed. Having a North Star in place and making time to reflect empowers you and your team to ask questions like, “Are the meetings we are regularly holding actually helping us collaborate?” and “Is the way we work enabling us to deliver value to our users as often as possible?”

4. Work with your team to change the specifics of your methodology accordingly

   Here’s where things get a bit trickier. If you’ve started with an off-the-shelf methodology, and found that some of the specific practices within that methodology are not working for you, you are likely going to need to go “off-manual” and implement new practices that are designed to meet the specific needs of your organization. This is where you and your team must commit to full accountability for the way that you work together, to changing the rules, not breaking the rules, to giving up the safety and comfort of pointing at a book or manual and saying, “I’m just doing what it tells me to do.”

   When changing specific practices within an organization, I’ve found it very helpful to document the change being made, the goal of that change, and how we will know when it is succeeding. In Chapter 4, I provided a simple and straightforward template that can be used to bring a goals-first approach to organizational practices. You can easily customize that template for working within Agile practices and methodologies:

   We used this Agile practice in our last iteration of work: We implemented it because we thought it would have this effect toward achieving our North Star goals: The actual effect of this Agile practice was: So, for the next iteration of work, we are changing it in this way: We hope that making this change will have the following effect toward helping us achieve our North Star goals: We will know that this change is succeeding when:

   This template provides an opportunity for you to tie back any specific practices or ceremonies you adopt to your North Star goals, and to explicitly track the difference between what you think a new practice or ceremony will accomplish and what happens when you actually implement that practice or ceremony. This can be tremendously helpful in better understanding the fundamental patterns and rhythms of your organization.

As you might have noticed, these four steps are not a “one and done” approach to implementing Agile practices. Following these steps means taking time to constantly adjust your approach based on what is working and what is not working. Again, the Agile Manifesto itself tells us that responding to change is more important than following a plan—even if that plan is for implementing Agile practices.

Bringing this approach to your work, you might find yourself changing some things that feel like immovable orthodoxies of Agile software development. That is totally fine. Nearly every product manager I’ve worked with has at some point made a major change to Agile sacraments like the daily standup meeting or the writing of user stories. Going “by the book” is a great place to start. But the book doesn’t know the specific individuals and interactions that drive your team and your organization. At the end of the day, it’s up to you.

A Few General Caveats About Agile

I am a firm believer in the core values of Agile. But Agile was not intended to be a cure-all for every organizational challenge. Here are a few potential limitations of an Agile approach that are worth keeping in mind:

Agile does not always explicitly address the “why”

Agile provides wonderful guidance as to how modern teams can work together. But most Agile practices do not intrinsically solve for “why.” As a product manager, you can ostensibly succeed at doing Agile while executing against a roadmap that still delivers no clear value to your business or your users. Resist the temptation to hide behind process and say, “Well, as long as I’m doing all this Agile stuff, I’m doing my job.” Even if you have a clear North Star guiding your Agile process in the right direction, you still need to make sure that you’re using that process to build the right things.

Agile rituals can become a false stand-in for user centricity

One common Agile practice, which we discussed at more length in Chapter 9, is writing out feature specifications as user stories. At its best, this practice can help product teams stay focused on user value rather than getting bogged down in implementation details. But at its worst, this practice can give product teams a false sense of user-centricity, even as they fail to interact directly with their users in any meaningful way. If you are writing user stories, I would strongly recommend using the template from earlier in this chapter to clearly spell out why you are using this practice—and how you will know whether you are succeeding in meeting those goals. For example, you might explicitly set as a success metric that writing “user stories” will result in your product team spending more time interacting face-to-face with users. Remember, no matter how many user-centric rituals you incorporate into the daily workings of your Agile team, you still need to talk to your users.

Agile needs to extend beyond your product team

This is not to say that your entire organization suddenly has to “do Agile.” But your entire organization does need to understand why your team is adopting Agile practices, and what the implications are for the organization’s overarching rhythms and deadlines. Again, the core values of Agile tell us that collaboration is key, but we must be vigilant about extending that collaboration beyond our immediate team, to ensure that we are not ultimately insulating ourselves from organizational dynamics that will prove critical to our success or failure.

Once again, a successful implementation of Agile comes back to the CORE skills of product management. No matter which Agile methodology you choose to implement—or whether you choose to implement no Agile methodology at all—there is still a lot of work for you to do as a product manager to make sure that your team remains communicative, well organized, truly user-centric, and focused on executing the right work to achieve your team and organization’s goals.

You Are Here

Depending on how mature the product management practice is at your organization, you might be working within a very well-understood and well-documented product development process, or you might be starting from scratch. Or, rather, you might think that you are starting from scratch. But the truth is, the lack of formal process is very much a process in and of itself. Teams that are used to operating with zero formal structure and guidance often resist change for the same reason that teams with a very mature practice might resist change: because they’ve gotten used to doing things a certain way, and they don’t want something to upset the status quo.

Regardless of whether you are working in an organization that has a formal product development process in place or one that is using an ad hoc system, I always find it helpful to take the time to sit down and map out how products are developed at your organization right now. How do you decide what to work on next? How do you estimate how long something will take? How do you break down something on a roadmap into actual tasks that can be completed? And how do you know when something is done?

Even if your organization has no formal process in place, answering these questions will help you communicate to your team that there is a way that things are currently done, which will make it easier for you to do the always-challenging work of changing organizational processes to better meet your goals. You should never make any changes to your process without having a clear sense of where you are, and where you’re going.

Summary: Ambiguity Lives Here, Too

With all of its frameworks, methodologies, and “best practices,” Agile might seem like a way to bring standardization to a role riddled with ambiguity. But at its heart, Agile is all about learning to respect and embrace uniqueness—of individuals, of interactions, and of the inevitable curveballs that will lead you away from your best-laid plans and into the great unknown.

Your Checklist:

• Avoid ambiguous and misleading jargon around Agile—say exactly what you intend to do and why you intend to do it.

• Understand the core values and principles of Agile before evaluating any specific practices or frameworks. If you just start implementing process without purpose, then you have no way to evaluate whether the process is working or not.

• Socialize a North Star vision around Agile values and principles, so that everybody on your team knows why they are “doing Agile” in the first place.

• Start with an off-the-shelf Agile methodology so that you have an impartial “referee” to resolve any specific questions about whether you’re “doing it right”—and then be fearless about changing that methodology if it is not helping you reach your North Star vision.

• Create and protect time for your team to evaluate Agile practices against the goals you’ve set. Document process changes along with their intended goals, so that there is clarity around what people are doing and why.

• Don’t let the operational details of doing Agile distract you from higher-level organizational goals. Remember that if you are executing against a product roadmap that delivers no value to your users or your business, it doesn’t matter how Agile your execution is—your product is still going to fail.

• Don’t let user-centric Agile rituals serve as a stand-in for actually talking to your users.

• Communicate the goals and rhythms of your Agile practices to people outside of your immediate team, so that they know what to expect and how to work with you.

• Understand that “no process” is still a process, and take the time to really understand how your organization is currently building products.

• If you feel that your organization is becoming too zealous about Agile, feel free to print out a whole bunch of blog posts by people who actually wrote the Agile Manifesto, describing how Agile zealotry and ornamentation have derailed the movement they started.