Agile Is Ruining Your Product
The quest for small, fast, and autonomous teams is creating fragmented, confusing, and disjointed experiences.
Trouble in Paradise
In my work as a product coach and consultant, the first question I usually get asked is, “How can we be more like [famous tech company X]?” This question has been answered countless times in well-publicized case studies, such as Amazon’s “two-pizza teams,” Spotify’s “squad, tribes, chapters, and guilds” model, and Facebook’s since-retired “move fast and break things” mantra. Taken as a whole, these stories paint a compelling picture of what product development looks like in best-in-class digital companies: small, autonomous teams operating at lightning speed.
The idea of small, autonomous teams — core to many Agile methodologies used by modern technology companies — offers an appealing alternative to the bureaucratic, command-and-control structures that still dominate the corporate world. And yet, this approach also carries a substantial risk: that the products created by small, autonomous teams will feel like a disconnected set of small, autonomous features.
For real-world examples of this anti-pattern, one need not look farther than the flagship products made by some of those very “best-in-class” digital companies. (See the “Explore” section on Facebook’s home page for a particularly galling example, or try to navigate seamlessly between the products once known as “Google Apps.”) As digital products grow bigger and more complex, it is more important than ever that we look beyond individual features and think about how those features combine to create seamless, cohesive experiences. And doing so will require acknowledging that the very dependencies that slow down the work of small, autonomous teams may sometimes be good for the customers those teams ultimately serve.
Operational Speed vs. Customer Need
The principles and practices of the Agile movement have proven particularly compelling to organizations looking to keep pace with a fast-changing world. And, without a doubt, breaking large and interdependent teams into small autonomous teams is likely to increase the speed at which each team can release improvements to the particular piece of the product for which it is responsible.
The problem, it turns out, is that the internal friction removed by small autonomous teams is still often felt by external customers. A 2013 Harvard Business Review article called “The Truth about Customer Experience” makes a critical point that often gets lost in the conversation about small, autonomous teams: from a customer’s perspective, the most important part of a product is often not its individual features, but rather how those features come together to create a seamless and cohesive experience.
Scoping, prioritizing, and executing such work necessarily involves a high degree of coordination between and across teams — and that coordination takes time and effort. For organizations measuring each team’s success by the operational speed of their work, this can create a glaring disconnect between the work that is most important to customers and the work that each small autonomous team is likely to prioritize. This ultimately begs the question: is autonomy really the goal we want to be working towards?
Putting It Back Together
Breaking down big products into small, manageable pieces is no easy task — but putting those pieces back together, it turns out, is much more difficult. Many scaled Agile frameworks are designed in part to balance small-scale autonomy with big-picture coordination. But the most important step towards keeping small teams connected and coordinated, as I discovered while researching my latest book Agile for Everybody, is less a matter of org charts and frameworks than one of collaboration and culture. As Spotify VP of Growth and Marketing Mayur Gupta told me:
When people refer to the Spotify model, they’re usually talking about guilds, tribes, and chapters. But those are just rituals. I don’t believe that you break down barriers by changing reporting lines. When you have a truly cross-functional team, reporting lines become irrelevant…. As you keep going through your life and career, you realize that what truly drives these changes is the culture.
In other words, simply redrawing your org chart to follow “The Spotify Model” (or any model for that matter) will not actually recreate the culture that has led Spotify — or any of those “best-in-class” companies— to achieve its biggest wins. Rather than following a single ready-to-adopt operational model, nearly every success story I heard when researching Agile for Everybody followed three high-level guiding principles:
- Starting with customers and their needs, not with a company-centric goal
- Collaborating early and often across multiple teams (regardless of how those teams are formally organized), to identify big opportunities as well as tactical dependencies
- Planning for uncertainty to actually incorporate new information as a project progresses
Teams and organizations that had truly embraced these principles were able not only to break down big challenges into smaller pieces, but also to dynamically rethink how those pieces fit back together. Their goal was not to achieve operational speed or pure autonomy, but rather to work together towards solving the biggest and most important problems facing their customers.
A Path Forward: From Silver Bullets to Elastic Organizations
The title of this article is intended to be provocative, but it also speaks to an important truth: any organization that is too focused on operational, company-centric goals like speed, autonomy, or “following the rules of an Agile framework,” runs the risk of pulling farther away from its customers. While the quest to remove internal friction is a worthy one, we must start by understanding the external friction experienced by our customers, and work tirelessly (and collaboratively) to minimize that friction.
Here are a few steps your organization can take to avoid pursuing speed and autonomy at the expense of customer experience:
- Resist the urge to measure progress strictly by operational speed (i.e., frequency of release or lines of code). Instead, think about speed from your customer’s point of view — are you helping them to achieve their goals quickly and easily? Or are you slowing them down with complex, fragmented experiences?
- Make sure that individual and team incentives are not so localized that they implicitly discourage taking the time and effort to work across teams.
- Clearly differentiate “good dependencies” (i.e., opportunities to combine efforts or features into a seamless experience for customers) from “bad dependencies” (i.e., dependencies that needlessly slow down an organization’s ability to meet customer needs). Be particularly vigilant in seeking out situations where multiple teams are doing duplicative or redundant work, a common problem among organizations that have sought to eliminate dependencies and foster autonomy.
- Be wary of catch-all menus and lists (like Facebook’s “Explore”) that can become a dumping ground for disconnected features. Remember that each new item you’re putting in front of your customers comes at a cost to their time and attention.
- Beyond “Agility,” the most successful organizations are truly elastic; that is to say, they can quickly spin up new organizational patterns and structures without a massive, formal reorg. One immediate way to build this elasticity is to form temporary “SWAT Teams” with representatives from multiple levels, functions, and feature-based teams, tasked explicitly with looking at how the work of these individual teams can combine to create a better customer experience. As an added bonus, try assigning such a team the task of completely reinventing the entire product from scratch, regardless of its existing feature set. (I’ll be writing more about elastic organizations and the “SWAT Team” approach in a future article.)
For more information on this subject, I hope you’ll check out my new book Agile for Everybody. As always, feel free to get in touch with me directly at matt@mattlemay.com if you have any thoughts, tips, or suggestions!
