Not all engineering projects require the same level of planning. Quantcast’s Head of Seattle Engineering Durban Frazer said that each of his team’s sprints consist of smaller projects and tasks that are part of a larger product vision.
While this strategy currently works well, it’s one that has changed over time.
“As we continue to experiment on this process, the most substantial change came about three years ago,” said Frazer. Quantcast had outgrown the ad-hoc approach they had been relying on, so leadership introduced Scrum and Waterfall methodologies into the mix.
Frazer’s team isn’t the only engineering department consistently iterating its software development lifecycle. Two other Seattle tech executives from Ookla and LevelTen Energy broke down their sprint cycles and shared how their teams’ processes have evolved as their headcounts have grown.
Quantcast’s Durban Frazer said that one of the biggest benefits of the team’s current software development life cycle is ongoing experimentation. According to the head of Seattle engineering, the current planning process makes it easy for anyone to suggest improvements, and regular retrospectives allow developers to review what’s working and test new ideas.
Give us some insight into your team’s software development life cycle.
We use a mixture of Scrum and Waterfall approaches depending on the size of the project. Each sprint is usually a combination of tasks that stand on their own and tasks that ladder up to a larger project. For example, spending two days implementing a new feature that makes development easier may be a smaller task. Larger projects, like switching a certain reporting system from a batch process to a real-time process, are typically scoped out at the beginning of the quarter. Once engineering teams and PMs determine what they can release over the quarter, the engineers will plan out the more specific tasks needed to support this new feature on a sprint-by-sprint basis.
For large projects (6-12 months) such as making sure the entire company supports GDPR, we create a small team made up of a product manager, project manager and technical lead. They coordinate technical design and project work across different teams.
Each sprint is usually a combination of tasks that stand on their own and tasks that ladder up to a larger project.’’
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
As we continue to experiment on this process, the most substantial change came about three years ago. We had gotten too big to use the ad-hoc, informal planning processes we had. Employees weren’t sure how to ask another team for help or who was in charge of building what.
Our current approach has several advantages. Engineers are always involved in setting the roadmap. It could be as small as choosing minor tasks for the next sprint or as large as setting the technical roadmap for many months. Because we are constantly involved in planning, we can easily make changes as new information or challenges come up.
It provides an easy way of communicating procedure to others. Daily standups, sprint planning and reviews help inform everyone of the work being done, which results in discussions about alternative approaches and advice on how to better tackle the problem. Sprint boards and cross-team sprint meetings help communicate team progress to other dependent teams.
According to VP of Software Development Marc von Holzen, having a flexible team structure allows Ookla engineers to strike a balance between focused collaboration and individual interests. His team relies on a few specific Agile principles for maximum efficiency, as outlined below.
Give us some insight into your team’s software development life cycle.
The software engineering teams at Ookla use Scrum. However, more importantly, we focus on well-defined roles and the following key Agile principles:
Key Agile Principles
- Product owns the business case, writing and prioritizing small and testable user stories, written as functional slices of a complete solution
- Software engineering owns architecting this solution, sizing user stories and delivering working software
- Scrum masters own running and evolving the process
- Engineering operations owns keeping the lights green, allowing software engineers to focus on development
The composition of Scrum teams can change over time to ensure coverage of all products and to rally around delivery of specific initiatives. Ookla as a whole uses objective and key results (OKRs) to ensure that everyone is pulling in the same direction.
We are not afraid to experiment with processes.’’
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
The most recent change was driven by a significant increase in our team’s size, as a result of strong company growth three years ago. We are not afraid to experiment with processes, as long as the changes are supported by data and sound engineering principles.
Building small slices allows us to release early and often, which in turn allows us to incorporate learnings and course-correct as needed. The healthy tensions between developing and operating drives us to build observability into our components from the start.
Between tasks like simplifying the power sales process and offering real-time portfolio performance monitoring, LevelTen Energy employees stay busy. CTO Eric Snyder said that in the last few years, the engineering process has evolved in a few key ways as the team has grown. One significant change? They now have multiple scrum teams that they refer to as “squads.”
Give us some insight into your team’s software development life cycle.
We’re an Agile development shop. When we had just a couple of engineers, we followed more of a Kanban flow with minimal structure, releasing as soon as we had something new or interesting to share. As we grew to include remote employees, designers and product managers, we began to follow a more formal Scrum process. It includes backlog planning, two-week sprints and a detailed task board with tickets linked to our source control system.
Following a scrum process allows us to develop more thoughtful requirements.’’
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We recently expanded again. We now have multiple scrum teams that we refer to as “squads.” Each squad consists of a mix of engineers, energy analysts, UI/UX designers and a product manager who focuses on a specific area of our platform. Our platform is a two-sided marketplace centered around detailed energy and financial analysis, so there is no shortage of complex problems to solve.
Following a scrum process allows us to develop more thoughtful requirements while giving us flexibility to more easily adjust our plan to meet the needs of our business.
