Geeky Fairytales: Software Engineering process, Google way: By: Simon Wingrove ( http://www.simonwingrove.com )
We often get questions along the lines of “what is the development process at Google?” – meaning the secret sauce which allows project to magically happen and launch on time. There is an abundance of articles and blog posts which describe how Google does things, and probably some of them are right! The truth is, however, that a process that works for one group of smart people will not necessarily work for another. This is why there’s simply no such thing as “the” development process at Google. Most teams will adopt the approach that suits them best.
Establishing the process for a team is usually not something that happens “because the manager said so” – frankly, engineers have far more say in the matter. When our team (Google Play for work) realised it was growing to the point where it needed to formalise its practices, the engineers stepped up and self-organised to make it happen.
The cornerstone of any development process is the goal: what are we trying to achieve here? We want to be able to answer a few fundamental questions at any moment in time.
- Are we on track to deliver?
- What features are we currently working on?
- Can we take on more work now and still meet our deadlines?
Engineers are best placed to estimate the complexity of engineering problems, so making sure we can always answer these questions is an engineer-driven process.
Objectives and Key Results – achievable and measurable goals
Across all of Google we use Objectives and Key Results (OKRs). Every team, product area and even the company as a whole has them. OKRs are defined quarterly by the product and engineering managers, with input from the wider team on specific technical questions.
OKRs must be well-defined and measurable – so “Improve UI latency” is not a good OKR while “Frontend latency must be below 500ms for 90th percentile” can be measured. OKRs are given a complexity estimation: in our team we use T-Shirt size. This estimation is rough, but allows managers to make a basic estimate of what can be achieved in a quarter.
User stories and backlog grooming
Our team uses a “sprint” based approach to development, with sprints of two weeks. We maintain a “backlog” of work to be done. We regularly meet as a team to groom the backlog. In this process we take OKRs and split them into “user stories”: increments of product function that could be delivered in a single sprint and provide value to the end user. We estimate the size of the stories as best we can, and order the stories on the backlog into a strict priority order.
We often use planning poker to estimate the size of a user story - ideally every team member gives his estimate how long this story will take, and if there are significant disagreements they are discussed until common ground is reached. This approach helps clarify requirements, and means that everyone on the team has at least some degree of understanding of the problems the team are working on.
Sprint planning
At the beginning of every sprint we hold a sprint planning meeting. The goal of sprint planning is to pull user stories from the prioritized backlog and commit as a team to delivering them in the sprint. This session is attended by all engineers as well as the product owner/manager. The end result of sprint planning is that we have committed to delivering a set of user stories, and stories are split into sub-tasks (each no longer than a day of work) assigned to owners. Usually engineers “claim” either whole user stories or specific subtasks.
The ideal outcome of a sprint is a potentially shippable increment of product function that provides additional value the end user.
Story tracking and daily stand-ups
To know where are we while the sprint is running it’s crucial for engineers to mark their progress on specific sub-tasks. When engineer starts working on something, they “accept” the sub-task, and when finished they mark it as fixed. To catch problems as early as possible we have a daily stand-up at 12:30. In the stand-up engineers give
- a brief explanation of what they’ve done since yesterday’s stand-up, and what they will do before the next stand-up
- whether they are on target for the sprint
- whether they have any concerns or blocking problems.
If anything looks like it may slip, we arrange to take remedial action that day. Ideally we reassign tasks so that the sprint goals can still be met. If this isn’t possible, we punt the least critical item from the sprint and then rearrange tasks.
Sprint review and retrospective
We end the sprint with two short meetings, the review and the retrospective, which we usually hold together accompanied by drinks and pizza. (After all, what’s software engineering without pizza? :-)).
We tidy-up all our tasks and stories, and look at what we did and did not deliver in the sprint. We also demo to each other, and the product owner, the cool new features we developed in the sprint so that everyone knows where the product is.
Google famously has a “launch and iterate” approach to products, and we have the same approach to our development process. It is really hard to get everything 100% perfect, and we constantly re-evaluate our progress. During the retrospective meeting, we discuss what went right and what didn’t. Sometimes features slip because of something outside of our control. Sometimes things take longer than we expected, and occasionally we decide to change direction entirely to improve the product.
The most important thing is to make our product high quality and useful to the user, and not to encourage the development team to “meet their target” by shipping a low quality product. It is therefore important to keep this meeting focussed on constructive feedback, and ways to detect issues quickly, rather than pretending that we can see the future and never make any mistakes.
