Introducing Agile Development at Google

Since their inception, Google has always wanted to keep their software development teams self-organizing, with less management overhead, while making sure the engineers and developers work closely with their stakeholders and customers and not just stuck behind the scene like most traditional software development teams outside of Silicon Valley. Google has a unique culture where it does not want to have a standard process or structure in place for all teams, instead the teams should be self-organizing and find a methodology that would work best for their projects and teams.

Google and Agile Adoption History

Mark Striebeck, an engineer manager at Google, led the agile methodology adoption which was very contrary to much of Google’s practices. Stribeck shared his findings in his study titled “Ssh! We are adding a process”. He used the AdWords frontend (AWFE) project as his test project and found this would be a tremendous opportunity as it was a huge business-to-business application.

The agile approach he took would bring to light some software development team and process issues, to keep track of progress being made within teams and then address the findings by slowly introducing scrum to the development process. He chose this project because of its size and complex nature as it had several employees from user interface designers to engineers working worldwide on numerous simultaneous projects with a very high-level rate of change.

He introduced some simple but powerful scrum elements at first from a bottom-up approach, starting with the engineers and product managers: “Release Backlog, Burndown Chart, Expression of Project in Story Points, Checkpoint Meetings”. The test phase of the agile methodology revealed that the developers were uncomfortable. Stribeck tried to slowly introduce iterative process in two-week Sprints. The engineers in the software development team really liked the idea of developing and testing back to back instead of waiting at the very end before the release phase to test. The engineers found that they can then be more focused on a shorter timeframe of product delivery using sprints. The downfall was that they were working on numerous projects, so a software engineer can be working on a traditional release schedule for one project and agile methodology for another. Stribeck’s study revealed that Google does not want to fully adopt agile structure in their team, rather they are more comfortable with adopting practices within their projects.

Quality Releases

Outside of their team structure and dynamics, Google has succeeded among all other companies because they carefully review all of their code, have diligent agile testing and create design documents. While they do not necessarily always operate in agile fashion, they care about producing a really great product with really good back-end that can be easily revised. This way the code all have a similar standard, so developers can easily go between teams and share code with one another. For Google, it is not about announcing a timeframe, unlike traditional software development teams. They do not want to rush a really good product, which is why they are diligent about their back-end. Google wants to ensure that the best thing that comes out is quality, not how fast something goes out. As described, Google has not fully adopted one approach for the entire company- it neither uses agile, not waterfall, instead it adopts agile practices to have some project processes.

Case Study: Google Chrome

A classic example is the Google Chrome release cycle. Google put together a blog post describing their change in release cycle. According to the Chromium Blog, the Google Chrome Developers mentioned that their new cycle would be “about once every six weeks… While pace is important to us, we are all committed to maintaining high quality releases — if a feature is not ready, it will not ship in a stable release”. As mentioned above, Google does not like to announce very specific time frames. This gives them more flexibility to move features to the next cycle if a feature is not ready in the six week time frame. As seen in the diagram below, they have adopted an iterative agile practice, but it isn’t a full-on agile lifecycle.


Google Chrome Developers stated their reasons why Google has announced this rapid release cycle. Their first goals is that they do not want their users to wait months before using new features, instead small iterative features can keep the consumers excited. The second goal is that they wanted to apply more project management in which they can have an internal idea on how long it will take them to do work in a six-week cycle. The last goal is to take pressure from the software engineers as they have less pressure if a feature is not completed than the old model which when a feature was not completed, they would have to work overtime, or disable the feature and wait months till next release.

Being a project manager working with developers who are working across multiple projects, adoption of agile is difficult. I found that there needs to be flexibility in the rule book especially in the beginning. I also found, depending on the size and complexity of the project, the length of the sprint can make a statement to the quality of the product and health of your team. Find a schedule that is realistic and push back to clients if needed. A happy team makes for a great product.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s