Agile for Everybody: Creating Fast, Flexible, and Customer-First Organizations

Book Preface

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 companywide 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 “timeboxed 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 twoweek 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 topdown 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 lastminute 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