How We Work in GoustoTech — Part 2 — Squads
In the first part of our series looking at How We Work in GoustoTech we focused on the overall team structure. This post digs into more detail about how an individual squad works, the methodology they follow and what the day-to-day role of an Engineer or Product Manager is within a squad.
Structure
Each squad in GoustoTech consists of five Engineers and one Product Manager. As we grow our team there may be fewer Engineers, but the overall goal is to be a six-person team. The aim is to make each squad a small, self-contained, independent unit that works towards achieving a mission. Squads use metrics that they own to understand their progress towards achieving this mission e.g. Improving our CSAT (Customer Satisfaction) score. Ownership of features also means that each squad owns a number of the technical components of our architecture. We structure ourselves so that, where possible, we can minimise the dependencies between squads.
The experience and skill-set of each Engineer differs within a squad. We aim for a good balance of back-end, front-end and full-stack capabilities to ensure the squad have all the skills to succeed in delivery value. We also aim for a variety of different experience levels. At Gousto we have Junior Software Engineer, Software Engineer, Senior Software Engineer and Lead Software Engineer roles. I’ll describe the difference between these in another post. Each squad only contains one Lead Engineer, but may have different numbers of other Engineers, especially as people progress through their careers.
The Product Manager is responsible for working with our Digital Product team and their stakeholders to manage the upcoming backlog. This involves prioritising change across our three areas of focus:
- Big Batch — large roadmap projects, fundamental enhancements and upgrades to our product — we spend approximately 60% of our time working on these
- Small Batch — small incremental enhancements or changes to our existing product — we spend approximately 20% of our time working on these
- Engineering Improvements — changes to improve the overall architecture or improve the engineering of our platform — we spend approximately 20% of our time working on these. Of course, there are times where we want to take on a larger investment in our platform that requires more than 20% of our time, these numbers are guidelines only.
Outside of a squad we have an Agile Coach role at Gousto. At the current team size we have one agile coach who helps to support 5 squads, but as we continue to grow we will increase this. The Agile Coach works with teams to help them improve how they work in a much broader role that the traditional Scrum Master role.
Methodology
All squads work to a Scrum based methodology. There are many similarities between the way each squad works, but we ensure that as we employ adults we provide the flexibility to tweak this as each squads needs change.
The similarities between squads mainly focuses on the Scrum ceremonies that take place. We follow a two weekly sprint process and each squad holds:
- A daily stand-up each morning (normally between around 9.30 and 10am)
- A number of Story Refinement sessions that take place each week — most squads do 2–3 30 minute sessions, normally straight after stand-up to minimise distractions. These sessions are to ensure that the squad know what each story consists of and can estimate it effectively.
- A sprint planning session at the start of each sprint. This session is to ensure that the squad plans work into a sprint that they agree is achievable.
- A sprint retrospective at the end of each sprint. This session is used to reflect on what was learned during the sprint and to look at actions to take into next sprint to improve how we work.
- A sprint demo at the end of each sprint. This session is to show stakeholders what was delivered in this sprint.
At Gousto we have always had a Tech Demo that is held monthly to the whole company. We have recently added the Sprint Demo for each squad, each sprint to enable quicker feedback for stakeholders and to ensure that squads get to show what they have created quickly. We will keep our monthly Tech Demo as a way of showing the whole company what has been achieved each month — but is unlikely to go into the same level of detail.
All of our squads adopt a Definition of Ready and a Definition of Done. The Definition of Ready is intended to ensure that stories have enough information to be taken into a sprint. The Definition of Done determines when a story can be marked as completed and therefore be counted towards our velocity.
WIP
Through our whole process we work with squads to ensure that we complete as much as possible. In order to do this we encourage teams to measure and minimise Work In Progress (WIP). We do this through a number of methods such as adding a WIP alert on our JIRA boards and carrying out our stand-ups by discussing boards right to left to focus on completion of tasks.
Roles
The Product Manager in each squad fulfils the Scrum role of Product Owner. They are empowered to manage the priorities and backlog and work as a member of the squad.
We do not specifically identify the role of Scrum Master in each squad. Our Agile Coach fulfils some parts of this role such as facilitation of retrospectives and coaching of the team. We firmly fight against having a ‘Scrum Mum’ i.e. a Scrum Master who spends all of their day acting like a mum to the team, in favour of promoting the team to take responsibility.
During the past few months our Agile Coach has been working with squads to understand the ‘Five Dysfunctions of a Team’ to improve how our squads work. Across all squads we have certainly seen very different starting points in this model.
Stories
Product Managers take responsibility for writing stories that are shared and refined with teams. While we don’t have a set format for all stories, we do try to follow some best practices. The main approach we follow is that all stories should follow the INVEST principles. Stories should ideally cover a full piece of functional change, rather than having a separate story for front and back-end work. We also look to ensure that stories have acceptance criteria on them. Over the past 6 months we have started to formalise this using Gherkin syntax.
Estimates
Most of our squads estimate using an effort based number. This is generated by the team in their refinement sessions by estimating using planning poker with the modified Fibonacci sequence. Where possible we try to remove the linkage between effort and time, although (like most teams) this occasionally creeps into squads.
When a squad is less mature we have focussed on capacity based planning. This means we have worked with the team to understand how long each ticket will take and sketched this up against a plan of the sprint. As the team gets more mature and achieves a more stable velocity we move to a velocity based planning. For this we then take the past average velocity as an indicator of our capacity and then the team uses their experience to understand if the amount of work is feasible to commit to.
Tech 10%
Every sprint we also have a Tech 10% day. This happens every two weeks on a Friday. Tech 10% is a time for self-learning and exploring technologies and ideas that you haven’t had time to look at for the other 9 days a sprint. Our only guidance around Tech 10% is that there should be some benefit to Gousto in what you are working on.
Last year we had a number of projects that moved from Tech 10% into production including our Alexa Skill and enhancements to our apps previously blogged about by Ryan.
OKRs
Gousto follows a quarterly OKR (Objectives and Key Results) process. This process allows us to align on our goals across the whole company each quarter.
Each squad works to set OKRs based on their squad KPIs, the features they own and our ongoing roadmap. We ask squads to set OKRs based on four pillars:
- Deliver our roadmap
- Move business KPI’s with small batch
- Improve quality, security, technical stability and performance
- Improve the teams capacity and ways of working
These OKRs are set at the end of the previous quarter and then reviewed and scored by the team at the end of the current quarter. We score all OKRs on a 0–1 scale, where 0.6 or above is considered a good result. This pushes each and every team to set stretch goals and pushes us to achieve more than we would expect through each quarter.
Coordinating Between Squads
The main method we use for communicating dependencies and impediments across teams is a two-weekly, all-squad retrospective. At this session each team brings along a Product Manager and an Engineer. Each squad shares any dependencies they have on other squads (which are recorded in a log) along with any impediments that they are unable to address themselves.
For impediments we keep an eye on organisational wide impediments such as broken builds, increased build times, office issues etc. These are areas that generally require outside help to fix.
We also use this meeting to agree on any areas where we feel we should have consistency across squads. In the past this has included getting agreement from all squads that their Definition of Done should include working on our local DevBox. Architectural coordination is achieved through our Architecture Group, which I’ll write about further in another post.
We’re Hiring
Given the amount of growth we’re going through this year it should come as no surprise we’re currently hiring. If you like what you’ve read about the team please get in touch workintech@gousto.co.uk (no agencies please). You can view a list of our current open positions on our jobs site.
