Agile for software development is one of the most common approaches to software development, requires certain stages to be implemented properly: Thus, it is often initiated by customer’s stories/journeys and executed by the collaborative effort of cross-functional teams of developers working in a single project management tool and lead by certain people — Agile Coaches/ Qualified Scrum Master.
Since its inception, Google has always wanted to keep its 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.
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.
Case Study: Google Chrome
A classic example is the Google Chrome release cycle. Google put together a blog post describing their change in the release cycle. According to the Chromium Blog, the Google Chrome Developers mentioned that their new cycle would be “about once every six weeks… While the 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 goal is that they do not want their users to wait months before using new features, instead of 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 of 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, the 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 the 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.
Source: