Agile adoption at Google: Potential and challenges of a true bottom-up organization

Mark Striebeck

Talking Heads · Leadership

Tuesday, 16:00, 1 hour 30 minutes | Grand Ballroom North

Download Presentation

Despite its size, Google does maintain a strong bottom-up culture. There are few standards regarding development process, status reporting and development practices. Google believes projects perform best if teams create and own their environment.
This does sound like a perfect environment for Agile processes. But how does Google drive Agile adoption when it knows mandating its methodologies would harm that very same culture?
In this talk we will explore what engineering-driven means at Google, and how this culture helps teams find their own process. We will also see how Google encourages and enables engineers to carry these improvements into the larger engineering organization as well as various smaller initiatives that encourage and support agile adoption. Finally, we will examine the "Test Mercenary" program - one of Google's larger programs which was started to improve developer testing. And how it was structured to avoid becoming a top-down or ivory-tower program.

Target Audience and Benefits:
Whether working for a large or small company, this discussion benefits anyone who is driving agile adoption. It demonstrates how agile adoption can be made part of an engineering culture centered on the idea of giving projects maximum autonomy. This aspect of agile development arises often in the agile community when discussing how its adoption cannot be the result of top-down pressure and control. It hopefully encourages some managers to give their engineers more responsibility and less standards - at the same time, giving them some insight what they have to prepare for. Also, it might give a taste of the potential that internal user groups have - if they are fully supported and part of the company culture.
A very interesting aspect of the discussion is of the "Test Mercenaries" program and how it was structured to avoid creating a central process police. It shows how executives can empower engineers to do the right thing and to support them in implementing promising ideas.
Finally, the discussion at the end of the talk might help prepare mid- to large-size companies prepare for unique strains that agile practices can put on the corporate infrastructure.

Outline:

1. Google culture
   Describing the culture at Google, which was not created by agile practitioners but as being compatible to agile, encouraging engineers to change the engineering organization from within.
2. Top-down support for bottom-up action
   How executives, directors and managers can support Agile adoption (or any kind from and for improvement of the engineering organization).
3. 20% time and the agile user group
   One of the more known aspects of engineering life at Google are the 20% projects. We take a closer look at what these 20% projects mean and how they help run an internal user group.
4. Which agile process
   The huge variety of people and projects at Google make it impossible to standardize on any Agile process or even a set of Agile practices. One main focus of the Agile adoption at Google is to make project leads and teams aware of the need to adopt. But this leaves the question: where should new projects with little to no Agile experience start?
5. Where to start and how to expand
   Being an engineering-driven company, it is clear that Google needs to focus our efforts on engineers. But we also need to support engineering teams that adopt Agile practices to also include other project team members (QA, PM, PjM, UI).
6. Focusing on developer testing
   There has been a lot of focus at Google on improving developer/unit testing. This resulted in a Google-wide program (the "Test Mercenaries"). This initiative was started bottom-up, went all the way to the top, was significantly scaled-up and came back down to be executed. How did we structure this program and how will it help us drive Agile adoption without making it our primary focus.
7. Technical and logistical challenges
   Continuous Build across 800 projects, the load on an SCM system if 5000 engineers do TDD... Again, Google has not been started by Agile practitioners but by people who believed in practices very similar to Agile. So, we already hit many issues that an organization of Google's size hits when trying to adopt Agile on a large scale.

Biography of presenter:
Mark Striebeck is an engineering manager at Google where he runs a program that supports the engineering organization in improving their testing efforts. In his 20% time he runs an internal user group which tries to further the adoption of agile practices. He has been working for more than 10 years in the software industry in a variety of engineering and management positions. Since discovering XP and agile development methodologies 5 years ago, he has become actively engaged in the agile community. He constantly tries to put new ideas and agile approaches to work. The great variety of projects and individuals at Google give plenty of opportunity for this. Striebeck is a frequent speaker at Agile and other conferences. He holds two master's degrees in mathematics and computer science from the University of Hannover and Brunel University, London.