This is an account of how large successful companies like
Microsoft, Amazon, Google, Facebook, Spotify, LinkedIn, Netflix and HP LaserJet Firmware
achieved agility at scale with tangible and lasting business benefits.
Compare this account with The results of companies migrating to heavy-weight scaled frameworks and off-the-shelf platforms.
Disclaimer: I don’t and haven’t worked for these companies. The info reported below has been cross-checked from multiple publicly available sources (videos, articles, documents, posts) coming from, then, company’s employees, in few cases from a journalist that visited the company, in one case from a previous employee, and from the company’s blog. For some of the companies, I could double-check with a current employee the resemblance of the whole resulted from putting together info from different sources.
All these big and successful companies work to deliver digital services and/or digital products, or physical products with embedded software.
These successful companies have achieved Agility at scale, with tangible and lasting benefits for their business.
Agility here is intended as being fast, dynamic, innovative, flexible, adaptive, and resilient.
It means they all achieved agility at scale in their business, in their organisation and in their technology.
At Scale, because they employ from a few hundred to several thousand software developers and engineers; and some of them develop large software systems that require many of those developers and engineers to work together on the same piece of software/delivery initiative.
With tangible and lasting benefits for their business, as is proven by their undisputable successes.
The image below shows a comparison of a few aspects, among all eight companies (WoW acronym stands for Ways Of Working).
An infographic follows below with some of the key points.
Some of those companies had that agility from the outset and maintained it while they grow (Google, Facebook, Spotify, Amazon) while others at some point in time went through some kind of change or transformation to achieve or recover such degree of agility (Microsoft, LinkedIn, Netflix and HP LaserJet Firmware).
Their pursuit of agility has been driven both bottom-up and from the top, with a lot of autonomy as well as responsibility for the teams. The balance between the bottom-up and the top drive vary from company to company. People, their autonomy, their mastery, their involvement, and team-work have been fundamental ingredients.
None of these companies even remotely refers to, uses practices from, or takes inspiration from any one of the commercial scaled agile frameworks (e.g. SAFe, DaD, or even LeSS).
None of these companies adhere to just one of the official Agile frameworks, not by the book, not by imitation, nor in a prescriptive or uniform and standard way for all the teams with a cookie-cutter or cut-and-paste approach.
All these companies have grown their own ways of working internally, in a continuous process of experimentation-learning-adaptation-evolution, in order to suit their specific circumstances and needs (no scaling by imitation, no copycats).
All these companies’ ways of woking take inspiration or are congruent with many of the Lean and Agile principles, values and mindset. With a few exceptions for two of them on sustainable pace, psychological safety, and daily collaboration with the business.
In their pursuit of agility, all these companies have a strong focus on technical excellence with a strong engineering culture. All of them consider the company culture as an important ingredient of their agility (suggested reading: Culture and cultural change frameworks and ideas).
All these companies’ have some technical practices at scale that have their roots in Agile and specifically in Extreme Programming (e.g. Trunk Based Development, Continuous Integration, Test Automation, Continuous Delivery).
They are still continuously evolving their own ways of working (no transformation programs, no target operating models or any end-state or end-date, no distinction between improving and delivering, just every-day continuous improvement).
Some of these companies (Microsoft, Spotify, HP LaserJet Firmware) explicitly define themselves as Agile and explicitly adopt ideas and practices from several Agile frameworks (e.g. Extreme Programming, Scrum, Kanban, Lean Startup). The other companies do not explicitly define themselves Agile and do not have any explicit company-wide policy about Agile, while Agile exists in pockets in their organisation because of the autonomy of the teams.
None of these companies talks about scaling Agile, some talk about Agile at scale.
In conclusion, for all these companies, their agility has been instrumental for their business, financial and commercial success, and for keeping their edge and innovativeness while growing and at scale.
These stories shared below provide good learnings about things that worked very well for these companies. Correlation does not imply causation, so do not just copy these as recipes, instead use these learnings to inform and inspire the experimentation in your company with an experiment-learn-adapt-evolve approach.
The Agile journey at Microsoft has been underway for some ten years starting from 2008 and continues to evolve.
Over these ten years, the journey has been:
The ways of working have grown internally without following or taking inspiration from any of the commercial scaled frameworks. The approach indeed has been to be Agile at scale, not to scale Agile.
Initially, there was a focus on Agile technical practices (Continuous Integration, Continuous Delivery, keeping on top of technical debt), and Scrum together with an increased focus on customers. After that the emphasis moved on an Agile mindset, a culture of trust and business results, keeping the customers involved, and giving the team the right balance of autonomy and alignment.
Microsoft’s rediscovered agility has been instrumental in its turnaround. Microsoft overcame the disease of bureaucracy, took quick and bold decisions: they de-prioritized Windows, bet big on the “cloud”, opened up to and embraced perceived rivals such as open-source, Linux and open standard making Visual Studio cool among developers and successful.
Below the suggested content.
Big Picture Article: How Microsoft Vanquished Bureaucracy With Agile
Article: Microsoft’s 16 Keys To Being Agile At Scale
Video: Account from Aaron Bjork of the initial journey at the team level
Videos and articles: DevOps at Microsoft
Unlike the other companies mentioned here, the adoption of the modern post-bureaucratic ways of working in Amazon has been led from the top. Amazon in some ways has adopted such modern ways of working from the outset as a public company since 1997, and continuously evolves them. Some of the elements of Amazon’s approach are:
It was 2002 when Jeff Bezos introduced and quickly implemented the frequently quoted “two-pizza teams”: small entrepreneurial teams aligned to the strategic priorities of the organisation, that almost independently build, run, support and ultimately own a set of services/product capabilities.
The transition to “two-pizza teams” included a fundamental technical change that enabled teams to quickly innovate at scale with a strong customer focus: Amazon made a huge technical effort to move the technical platform, infrastructure and architecture from a two-tier monolith to a fully-distributed, decentralised, services platform. Some identify this pivotal moment as when Amazon achieved its Agility, but many argue that the seeds of agility were there from the beginning and this adaptation was an expression of that.
Amazon modern and continuously evolving ways of working are grown internally.
Amazon doesn’t call itself “Agile” though its approach enacts many lean and agile ideas, principles and approaches for example around the team, customers, products, prioritisation, and technical agility (see for example Scrum, Extreme Programming, Lean startup) with a couple of peculiarities:
The latter point is not aligned with the Agile principle of sustainable pace of work, nor with psychological safety that is one of the ingredients to support individuals as per one of the agile principles.
In the Amazon approach, there are no implicit or explicit references or influences to and from any commercial scaled agile framework.
Amazon’s ways of working, culture and ultimately agility have been the foundations of its commercial and financial successes in very disparate markets and products, e.g. AWS and Echo and Kindle.
Below the suggested content.
Article: How Amazon Became Agile
Pdf: A Conversation with Werner Vogels (Amazon CTO)
Article: How Mapping The Agile Transformation Journey Points The Way To Continuous Innovation (paragraph The Amazon Story)
Post: Amazon Leadership Principles
Article: How Amazon Uses Agile Team Structures and Adaptive Practices to Innovate on Behalf of Customers
Google is a tech company with more than 40 offices around the world.
People at Google people don’t say “IT” (information technology) because the business & tech work closely together, and IT is an integral part of the business.
Google does large-scale software development: as reported in posts from 2010-2013, they have 15.000+ developers working on a codebase of more than 100 million lines of code.
Because of the scale, Google needs to develop its own tools and infrastructure.
In more technical terms Google practice Trunk Based Development: it has a single monolithic code tree, with all the submission done on the head and all the builds and the releases done from source. Google also practice Continuous Integration at scale, has extensive test automation with 100+ million test cases run per day, and more than 50000 builds per day on average.
Technical practices used by Google such as Trunk Based Development, Continuous Integration, and Test Automation, have their roots in Agile software development and more specifically in Extreme Programming. But Google does not make any explicit references to Agile in relation to their ways of working while taking some inspiration or using the evolutions of Extreme Programming.
In relation to scaling their ways of working instead there is no reference at all, no inspiration, no use of any idea or evolutions from any of the commercial agile scaled frameworks.
There is a lot of freedom and organic emergence of tools, practices and processes from those doing the work, in Google.
There are only a few processes and practices and tools mandated in Google, while engineers have a lot of autonomy.
At an individual delivery initiative level (the original paper uses the word project), uniformity is rarely mandated and adoption of tools and processes is left to an internal “market” to decide. A large portion of Google tools is developed by motivated individuals to solve local challenges. Similarly, the process is tailored specifically to the initiative. While this leads to a healthy amount of chaos, good ideas tend to spread quickly, because they have been proven useful by others. Engineers decide what’s best for engineering.
Agility has been fundamental for Google to remain innovative and fast while growing at an unprecedented scale, and ultimately maintaining its technical supremacy that started with taming the sea of information, continued with reinventing emails, mapping the world, … , and now leading the progress of Artificial Intelligence applications.
Below the suggested content.
Article: The five keys to a successful Google team (while doubts have been raised on the validity of this study, its account still gives a snapshot of teams at Google)
Article: The Design Sprint (see the final paragraph “A Brief History of the Design Sprint”)
Pdf: Continuous Integration at Google Scale
Article: Google’s Scaled Trunk-Based Development
Article: The Birth of Automated Testing at Google in 2005
Article: Test Mercenaries (account of the 2006-2009 Google initiative to improve test automation)
Online Book: Google Site Reliability Engineering
Pdf: Google’s Innovation Factory: Testing, Culture, And Infrastructure
Article: Is Google Going Agile?