Tag: amazon

In this BONUS Xmas Special episode, we explore what happens when we strip away the certifications and branded frameworks to recover the essential practices that make software development work. Building on Episode 2’s exploration of the Project Management Trap, Vasco reveals how the core insights that sparked the Agile revolution remain valid – and how real organizations like Spotify, Amazon, and Etsy embody these principles to thrive in today’s software-driven world. The answer isn’t to invent something new; it’s to amplify what’s already working.

Agile as an Idea, Not a Brand

“The script (sold as the solution) will eventually kill the possibility of the conversation ever happening with any quality.”

We establish a parallel between good conversations and good software development. Just as creating “The Certified Conversational Method™” with prescribed frameworks and certification levels would miss the point of genuine dialogue, the commodification of agile into Agile™ has obscured its essential truth. The core idea was simple and powerful: build software in small increments, get it in front of real users quickly, learn from their actual behavior, adapt based on what you learn, and repeat continuously. This wasn’t revolutionary – it was finally recognizing how software actually works. You can’t know if your hypothesis about user needs is correct until users interact with it, so optimize for learning speed, not planning precision. But when the need to certify and validate “doing Agile right” took over, the idea got packaged, and often the package became more important than the principle.

Four Fundamental Practices That Enable Living Software

“Every deployment was a chance to see how users actually responded.”

Software-native organizations distinguish themselves through core practices that align with software as a living capability. In this episode, we review four critical ones: First, iterative delivery means shipping the smallest valuable increment possible and building on it – Etsy’s transformation from quarterly releases in 2009 to shipping 50+ times per day by 2012 exemplifies this approach, where each small change serves as a learning opportunity. Second, tight feedback loops get software in front of real users as fast as possible, whether through paper prototypes or production deployments. Third, continuous improvement of the process itself creates meta-feedback loops, as demonstrated by Amazon’s “You Build It, You Run It” principle introduced by Werner Vogels in 2006, where development teams running their own services in production learn rapidly to write more resilient code. Fourth, product thinking over project thinking organizes teams around long-lived products rather than temporary projects, allowing teams to develop deep expertise and become living capabilities themselves, accumulating knowledge and improving over time.

Spotify’s Evolutionary Approach

“The Spotify model has nothing to do with Spotify really. It was just a snapshot of how that one company worked at the time.”

Spotify’s journey reveals a critical insight often missed in discussions of their famous organizational model. Starting with standard Scrum methodology pre-2012, they adopted the squad model around 2012 with autonomous teams organized into tribes, documented in Henrik Kniberg and Anders Ivarsson’s influential white paper (direct PDF link). But post-2016, internal staff and agile coaches noted that the “Spotify model” had become mythology, and the company had moved on from original concepts to address new challenges. As Kniberg himself later reflected, the model has taken on a life of its own, much like Lean’s relationship to Toyota. The key insight isn’t the specific structure – it’s that Spotify treated their own organizational design as a living capability, continuously adapting based on what worked and what didn’t rather than implementing “the model” and declaring victory. That’s software-native thinking applied to organization design itself.

Amazon’s Two-Pizza Teams and Massive Scale

“Amazon deploys code every 11.7 seconds on average. That’s over 7,000 deployments per day across the organization.” (see this YouTube video of this talk)

Amazon’s two-pizza team principle goes far deeper than team size. Teams small enough to be fed with two pizzas (roughly 6-10 people) gain crucial autonomy and ownership: each team owns specific services and APIs, makes their own technical decisions, runs their services in production, and manages inter-team dependencies through APIs rather than meetings. This structure enabled Amazon to scale massively while maintaining speed, as teams could iterate independently without coordinating with dozens of other teams. The staggering deployment frequency – over 7,000 times per day as of 2021 – is only possible with a software-native structure for the company itself, demonstrating that this isn’t just about managing software delivery but touches everything, including how teams are organized.

Why These Practices Work

“These practices work because they align with what software actually is: a living, evolvable capability.”

The effectiveness of software-native approaches stems from their alignment with software’s true nature. Traditional project approaches assume we can know requirements upfront, estimate accurately, build it right the first time, and reach a meaningful “done” state. Software-native approaches recognize that requirements emerge through interaction with users, estimation is less important than rapid learning, “right” is discovered iteratively rather than designed upfront, and “done” only happens when we stop evolving the software. When Etsy ships 50 times per day, they’re optimizing for learning where each deployment is a hypothesis test. When Amazon’s teams own services end-to-end, they’re creating tight feedback loops where teams feel the pain of their own decisions directly. When Spotify continuously evolves their organizational model, they’re treating their own structure as software that should adapt to changing needs.

The Incomplete Picture and the Question of Universal Adoption

“If these approaches work, why aren’t they universal?”

We’re not trying to paint a unrealistically rosy picture – these organizations aren’t perfect. Spotify has had well-documented challenges with their model, Amazon’s culture has been criticized as demanding and sometimes brutal, and Etsy has gone through multiple strategic shifts. But what matters is that they’re practicing software-native development at scale, and it’s working well enough that they can compete and thrive. They’re not following a playbook perfectly but embodying principles and adapting continuously. This raises the critical question that will be explored in the next episode: if these approaches work, why do so many organizations still operate in project mode, and why do “agile transformations” so often fail to deliver real change? Understanding the resistance – what we call The Organizational Immune System – is essential to overcoming it.

References for Further Reading

• • A book on the shift from “projects” to “products”: “Project to Product” by Mik Kersten

About Vasco Duarte

Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.

You can link with Vasco Duarte on LinkedIn.