Agile for Everybody

Introduction

My Introduction to Agile: “Twice the Work in Half the Time”

We are going to be implementing some new Agile processes that will allow our product teams to get twice as much work done in half the time.

This was the first thing I heard about Agile, and I had no reason to doubt it. I was working as a product manager at a medium-sized company, and our executive team had called a company-wide meeting to share its plans for the coming year. I was not sure whether “Agile” was a thing with a capital A or just a general descriptor of the way we would be working moving forward, but in either case, it sounded pretty good to me. My team had been fairly slow to get new products out the door, in large part because changes in leadership had left us without a clear vision against which to execute. Maybe this “Agile” thing would help us solve for that? Upon returning to my desk, I quickly did a search for “Agile process,” and was greeted with the following paragraph via Wikipedia:

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

Reading this explanation left me with a creeping sense that I was far out of my depth. All of the concepts in this dense paragraph—“self-organizing,” “evolutionary development,” “rapid and flexible response to change”—sounded like they were almost certainly good things. But it was entirely unclear to me what I was supposed to do about any of this. What exactly is a “time-boxed iterative approach?” And how was any of this going to result in us doing twice the work in half the time?

Feeling uncertain about what was expected of me, I sought out the help and advice of some more experienced developers and designers on my team. They explained to me that Agile was a term used to describe a set of approaches that were broadly similar in spirit but different in their specific methods. The most popular of these approaches was something called Scrum. My colleagues recommended a few books and articles, and I set out to learn what this Scrum thing was all about and how it could help my team be faster and more efficient.

After a weekend spent reading ebooks and blog posts, I was able to glean a few tactical steps that seemed essential to implementing Scrum. First, we were to break down our work into two-week periods called sprints. At the end of each sprint, we were to have something actually finished and ready to release to our users. And during each day of the sprint, we were to have a daily standup or daily scrum meeting. During this meeting, each member of the team was to share what they’ve completed, what they’ve been working on, and what might be blocking their progress.

I reported back to my colleagues that I had read the books and articles they had recommended, and that I was ready to make some exciting changes to the way we work. The idea of actually getting something finished every two weeks seemed like a surefire boost to both productivity and morale, and having some face-to-face time every morning seemed like it could only improve our team’s communication. My more experienced colleagues exchanged a kind, but knowing look. “OK,” they said, “let’s give it a try.”

It did not take long for me to understand why my naïve enthusiasm was not necessarily shared. No sooner had we started implementing these new Agile processes than they were swiftly undermined by the very executives who had sold us on “Agile” in the first place. We began planning out work in two-week sprints, but these sprints were consistently derailed by new top-down demands and priorities. In one particular case, an executive emailed a member of my team asking that she work on something different for the duration of the sprint—and, oh, by the way, don’t tell the rest of the team about this. All the dysfunction and discord that had impeded our work previously was still there. We were no faster, and we were no more efficient.

But still, something was undeniably different. In their own sneaky little ways, each of the changes we made helped us see something about our organization that had been invisible to us before. Prioritizing and committing to deliverables in two-week cycles made it clear just how often the high-level vision for the product was being pulled in conflicting directions. Checking in with one another every morning made it clear just how disconnected individual members of my team had become from our shared mission and goals. It was as though the poltergeists of organizational dysfunction that haunted us had suddenly taken a material form and were showing up, ectoplasmic coffee in hand, to our team meetings.

With these dysfunctions brought to light, my team and I were able to take some difficult but necessary steps toward actually addressing them. Disagreements between team members that would have previously affected the quality of our product were exposed in our daily meetings and then resolved in smaller follow-up conversations. I felt emboldened to push back on last-minute executive changes by pointing out that we could not get anything out the door half as fast, let alone twice as fast, if we couldn’t even go two weeks without dramatically changing course. Power that had once been wielded through subterfuge and sabotage now ran up against a clear and agreed-upon set of operating procedures. In short, the silver bullet brought in by executives turned out to be more of a Trojan horse.

The Alchemy of Agile: Uniting Principles and Practices

After my initial experience with Agile, I felt like I had made a great discovery: Agile was not just about processes and tools, it was about people and culture!  Though the tactical changes we made had not gone according to plan, they had brought us together as a team and helped us to understand the challenges we were facing as an organization. Inspired by this realization, I began to dig a little bit deeper into the history of the Agile movement—a history we explore at greater length in Chapter 1. It did not take me long to realize that my great discovery was not much of a discovery at all. People and culture, it turned out, had been at the heart of the Agile movement all along.

This knowledge changed my approach to Agile dramatically. The human values and principles of the Agile movement provided a bright and steady North Star that my team and I could follow, even when doing a particular practice “by the book” didn’t seem to be working for us. This proved particularly valuable because, as it turns out, there are a lot of different books that will tell you a lot of different things. Rather than feeling paralyzed by having to decide which of many seemingly contradictory approaches to Agile was “right,” I was free to ask, “What can I pull from each of these approaches that will help the particular team I’m working with put Agile principles and values into practice?”

Indeed, the truly powerful thing about Agile is not that it provides a concrete and actionable set of practices or that it is guided by an inspiring set of principles, but rather that it necessarily involves both. Agile demands that we keep our ideals and our actions closely aligned with each other, which in turn compels us to ask some very tricky questions about why we do the things that we do as individuals, teams, and organizations.

For those who see Agile as a one-size-fits-all ticket to easy operational gains, this often comes as a nasty surprise. Even when we approach Agile in the hopes of doing more work in less time, we often find ourselves challenged to bring more of ourselves to the table—more energy, more openness, more willingness to reflect honestly around difficult questions. Agile, as its name suggests, asks us to be willing to challenge our assumptions and change our minds, which is no easy task.

In the decade or so since my introduction to Agile, I have seen similar stories unfold across dozens of very different organizations. I have worked with product and engineering teams at financial services organizations that adopt Agile practices in the hopes that they can better keep pace with a fast-changing world, only for those teams to realize that the inertia which they initially blamed on their leaders and their industry was largely a result of their own fear of change. I have worked with marketing teams at Fortune 500 consumer packaged goods companies that adopt Agile practices in the hopes of working more like cutting-edge technology companies, only for those teams to realize that they are completely unaware of the forward-thinking work being done by the R&D departments at their own companies. My experiences with Agile have made me a true believer, not in the sense that I believe Agile is a single solution to all the problems facing modern organizations, but rather in the sense that I believe Agile can help teams and organizations better understand and address the specific set of problems they are facing.

Why Agile for Everybody?

In a 2011 Wall Street Journal op-ed, venture capitalist Marc Andreessen famously declared that “software is eating the world.” It is not terribly surprising, then, that the Agile principles and practices utilized by so many modern software development teams are taking a bigger and broader bite. A quick search for “Agile marketing” or “Agile sales” or “Agile leadership” yields a plethora of articles, books, and blog posts that describe how the principles and practices of Agile can be applied to a broad set of business functions. In part because of its association with the high-tech world of software development, “Agile” has become a popular prefix for all kinds of cutting-edge business activities, just as “digital” was in the late 1990s and early 2000s.

In theory, the idea of extending the core ideas of Agile beyond software development seems like a logical next step. As we discuss in Chapter 1, the founders of the Agile movement were keenly aware that the values and principles they espouse are relevant and applicable throughout modern organizations, well beyond product and engineering teams. At their best, these values and principles provide a shared language that can break down functional silos and unite organizations in collaborative, customer-centric work.

In practice, however, there is a substantial risk that the growth of Agile into other areas of business will actually reinforce organizational silos rather than break them down. Every function within a business has its own specific jargon, its own specific tools, and its own specific frameworks and methodologies. If we treat, say, “Agile software development,” “Agile sales,” and “Agile marketing” as distinct and function-specific collections of tactics and methods, we are missing out on a critical opportunity to work together toward meeting the needs of our customers. In other words, we run the risk of “Agile for X” and “Agile for Y” highlighting and exacerbating the differences between X and Y rather than uniting different functions around the common values of the Agile movement.

Thus, Agile for Everybody. My goal with this book was to answer two questions: how can we frame the underlying principles of Agile in a way that is equally accessible and instructive for individuals across roles and functions, and what can we actually do in our day-to-day work to put these principles into practice?

In my work as a consultant and trainer, I have found these questions to be just as impactful for product and engineering teams at small startups as they are for marketing and insights teams at Fortune 500 enterprises. The specific approaches used by these teams to put Agile values and principles into practices are, necessarily, quite different. But starting with these values and principles creates a shared language and a shared vision that can transcend functions, titles, and even organizations. It casts Agile as a broad and inclusive movement in which all of our contributions and perspectives have value. And it gives us precious few excuses for abandoning our efforts if and when we find that doing Agile “by the book” isn’t moving us in the direction we had hoped.

To that end, the word Agile is used throughout this book to refer to the overall set of practices, principles, and values that are widely associated with the Agile movement. Many of the practices described in this book originate from specific Agile software development methodologies, but have been generalized to reflect the broader colloquial use of the term. In the interest of extending the Agile movement beyond product and engineering teams, I have found it much more actionable to take a “that’s also” approach (as in, “That’s also something we can do to put Agile values into practice!”) than a “that’s actually” approach (as in, “That’s actually part of this Agile methodology, not that Agile methodology”). Our goal, after all, is to change the way we work for the better, which means prioritizing practical action over theoretical debate.

Who This Book Is For

This book is for anybody who believes that customer centricity, collaboration, and openness to change should be at the heart of modern organizations.

In the words of one of its cofounders, the Agile movement was founded upon “a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work.” Those values, and the practices that enact them, can offer a much-needed path forward for organizations struggling with hierarchies, silos, and rote and restrictive processes.

This book is designed to provide a holistic, actionable, and accessible overview of the “why,” “how,” and “what” of Agile. It outlines the principles, practices, and success signals that individuals can use to bring the best of Agile to their organization across roles, teams, and functions. This is the book I have wanted to hand to executives when they tell me, “I’ve heard this Agile thing can make us a faster and more innovative organization,” and the book I have wanted to hand to people in marketing, sales, and consulting roles when they say, “We don’t make software, so I’m not sure how Agile could work for us.”

For organizational leaders in particular, I hope this book can convey a sense of the candor, reflection, and hard work that goes into truly embracing the principles of Agile. Experienced Agile practitioner Lane Goldstone, one of the many inspiring people I interviewed for this book, stated it perfectly: “If this book results in even one executive being more thoughtful and humane in their deployment of Agile, I think it will be a success.”

How I Wrote This Book

This book began with conversations—a lot of conversations—between myself and Agile practitioners from dozens of different companies, industries, and roles. Some work in manufacturing, some work in the nonprofit sector, some work in marketing, and some work in sales. Some are VPs and C-suite executives at multinational corporations; some are independent practitioners and consultants. Some are formally trained Scrum masters and Agile coaches, while some have never really thought about the work they do as particularly “Agile.” All were exceptionally generous with sharing their real-world experiences—good, bad, or ugly—and speaking candidly to both the power and the limitations of the approaches they’ve taken.

Many of the people I spoke with described how their most successful experiences with Agile have involved drawing upon ideas and practices from multiple toolsets, frameworks, and methodologies, some of which are not formally considered part of Agile at all. And none of the people I spoke with claimed to have figured out the single best or most correct approach to Agile. People working in real-world organizations generally don’t have the luxury of dogmatic certainty—they have products to build, campaigns to launch, and people to get along with. It follows, then, that the stories from Agile practitioners that are peppered throughout this book are not intended as a prescriptive set of the “best” ways for any team or organization to approach Agile principles and practices. Instead, they provide some real-world examples of how people across functions and industries have used Agile principles and practices to meet the needs of their specific teams, organizations, and customers. This book, as with any book, can’t do the work for you. But it can help you understand the work that you need to do.

How This Book Is Organized

This book is designed to provide you with the raw materials you need to approach Agile principles and practices in a meaningful, sustainable, and future-proof way. Doing so requires identifying and articulating why you are turning toward Agile in the first place, how you plan to put Agile principles into practice, and what real-world outcomes you are achieving for your colleagues and your customers. This approach creates a sustainable, self-reinforcing loop, as shown in Figure I-1.

Figure I-1. Keeping principles, practices, and real-world outcomes synchronized.

First and foremost, any meaningful implementation of Agile must begin with a clear sense of why a given organization or team is looking to change the way it works in the first place. To find the unique North Star of Agile principles and values that represent your “Why,” you can take two steps that we discuss in more detail in Chapter 2: identifying the goals of your particular organization or team, and then using those goals to articulate the underlying principles of Agile in a way that will be recognizable, meaningful, and actionable for your specific context.

After you’ve found your “Why,” you can begin identifying the particular Agile practices that you will use to change how your team or organization works. As we discuss in Chapter 6, actually implementing these practices often involves starting small and generating a “pull” across teams and functions rather than trying to “push” a new way of working to everybody all at the same time.

Finally, you must pay close and unflinching attention to the real-world outcomes that your chosen Agile practices are creating for your colleagues and customers. Note that I have explicitly defined “What” not as “What are the Agile practices we will implement,” but rather as “What is actually happening as we implement these practices and follow our guiding principles?” This is to ensure that we do not confuse the adoption of Agile practices with the outcomes that we hope they will enable us to achieve for our colleagues and our customers.

These three pieces form a feedback loop that we can use to sustain and adapt our Agile journey as our markets, our customers, and our own organizational structures change. If we feel that we are not living up to our North Star of Agile values and principles (“Why”), we can reevaluate the practices we have chosen to activate them (“How”). If we feel that these practices are not resulting in a better working experience for our colleagues and higher-quality outcomes for our customers (“What”), we can reevaluate our North Star (“Why”) to see whether it still reflects our best understanding of our organization, our market, and our customers.

Agile Guiding Principles (“Why”)

The first step of any successful Agile journey is understanding why you want to change the way you work in the first place. In Chapter 2, we take a closer look at the steps you can take to understand your particular goals—and how you can use those goals to articulate the Agile values and principles that will guide your organization or team. For the purposes of this book, the difference between “values” and “principles” is purely semantic; a statement of values (“we value X over Y”), a statement of principles (“we believe X, Y, and Z”), or a combination of both can provide meaningful and substantive guidance.

Chapters 3 through 6 are organized around three guiding principles of Agile for everybody:

• Agile means that we start with our customers

• Agile means that we collaborate early and often

• Agile means that we plan for uncertainty

These three guiding principles represent my attempt to synthesize and distill the underlying ideas from the Agile movement that I have found to be most impactful across functions, industries, and organizations. This approach is inspired by Agile movement cofounder Alistair Cockburn, who distilled the principles and practices of Agile into his own set of straightforward, jargon-free prompts called “The Heart of Agile”: “Collaborate, Deliver, Reflect, Improve.”

Distilling Agile to a set of simple prompts allows teams from any function or industry to accommodate the realities of their own work and still make room for positive change. For example, a marketing team could ask, “Are we collaborating early and often?” to identify new opportunities for working more closely with their counterparts in product. A sales team could ask, “Are we planning for uncertainty?” to think through different scenarios for how to adjust course if they appear to be missing their targets. These prompts themselves do not provide absolute prescriptive solutions, but they can help lead us to solutions that are both impactful and achievable.

Agile Practice Quick Wins and Deep Dives (“How”)

Within Chapters 3 through 6, I share a few examples of steps that teams and individuals in different roles (such as sales, marketing, and executives) could take to put a given Agile principle into practice. These are meant to be lightweight, approachable activities that introduce Agile practices to your team without demanding too much commitment or buy-in. I’ve often found it helpful to frame these activities as little experiments that you can easily roll back if they are deemed unsuccessful; that is, “Let’s try this out for a while, and see what happens! Worse comes to worst, we can always go back to doing things the way we did before.”

In each of these four chapters, I also share a deep dive into a common Agile practice that provides teams and organizations with a tangible way to make each guiding principle a part of their day-to-day work. The goal of these deep dives is to help you understand how you can use each practice to actualize and reinforce Agile principles—and to help you identify situations in which simply implementing these practices might not be helping you to actualize and reinforce those principles.

There are, of course, many more than four practices contained within formalized Agile methodologies and countless others beyond those methodologies. If you are interested in learning more about these practices, I strongly recommend checking out the subway map of Agile methodologies and practices provided by the Agile Alliance.

Success Signals and Warning Signs (“What”)

Agile practices always play out differently in the real world from how they do on paper, and it is critical that you remain well attuned to what is actually happening to your organization and your customers as you implement these practices. Although every organization’s Agile journey is different, there are a few common success signals and warning signs that are worth looking out for. These are captured in Chapter 3 through Chapter 6 under the headings “You might be on the right track if…” and “You might be going astray if…” For each success signal, you will find a few tips and pointers for keeping the momentum going. For each warning sign, you will find a few tips and pointers for getting back on track.

Your Agile Playbook

Finally, in Chapter 7, you have the opportunity to combine the principles and practices you’ve read about into an “Agile playbook” for your own team. This is a similar exercise to one you might go through with an Agile coach, and I strongly recommend that everybody who reads this book completes it. In going through these steps, you might realize that there are some difficult questions your team needs to talk through together, or that a few small changes to the way you work could have an outsized impact.

Acknowledgments

Nodding along to the general principles of the Agile movement is quite easy, but actually following them is incredibly difficult. Throughout the process of writing this book, I found myself exhibiting some of the very behaviors for which I have admonished “Agile” teams and organizations. I balked at the idea of sharing works in progress for fear that they would not be suitably impressive. I resisted new information that complicated my preexisting beliefs and ideas. And I became frustrated when this new information called for me to rework things I had already written, even when I knew the book would be stronger for it.

All of which is to say, the process of writing this book constituted its own kind of Agile journey for me personally. I am deeply and profoundly grateful to everybody who took the time to provide their input and feedback, both on and off the record. The stories and perspectives included in this book have proven inspiring and instructive, both professionally and personally, and it is a true honor to share them here.

I am also deeply and profoundly grateful to my wife, Joan, who can see things I cannot see and is always brave and generous enough to voice them. And to my mom, Carol, a skilled communicator by nature and by trade, who helped distill and clarify many of the concepts in this book. Many of those concepts emerged directly from the work I have done with my Sudden Compass business partners, Tricia Wang and Sunny Bates, whose support and partnership mean the world to me.

Enormous thanks to everybody at O’Reilly Media, both for shepherding this book into existence and for giving me the opportunity to road test its content via trainings and videos. Enormous thanks to Lane Goldstone, Courtney Hemphill, and the Balanced Team NY community for giving me the opportunity to test some of the ideas in this book with skilled and experienced practitioners. And enormous thanks to Amy Martin, whose illustrations perfectly capture the human dimension of Agile. You can find more of Amy’s amazing work at http://www.amymartinillustration.com/.

This book is dedicated to everybody who has been brave enough to challenge the status quo and seek out new and better ways of working, whether or not they are called “Agile.”