Scaling A Happy, Productive Team
Grooming, pointing and psychological safety
Over the last year the Mobile SLB team grew from 1 to 5 members. Throughout this time we adopted practices for improving the predictability and quality of output while also reducing stress. Over the last two months 85% of our projects launched on time and included no scope creep. For the projects that miss, a common pattern is underestimating the work it takes to integrate with the backend. We will be diving deeper into these misses to see what more we can learn and determine action items.
We typically groom the tickets a sprint before they will be worked on. Our grooming meetings used to often go over time and we had to schedule more follow up meetings to get through all the tickets. One main reason was because the tickets lacked details and clear owners. As a result, we spent time speculating over what the tickets entailed. We took a while to make estimates and lacked confidence in them. A Sprint last October contained three separate meetings totaling 2.5 hours.
At the end of each Sprint we have a Retrospective. We seamlessly transitioned to remote working because we use a simple Google Doc. Our Retrospectives are especially productive because teammates feel safe bringing up concerns. A great retrospective is one where teammates feel psychologically safe and where action items are completed. Post it notes are optional!
A teammate brought up the amount of grooming meetings in a Sprint retrospective. Our solution was to appoint Tech Leads for every feature. These leads are responsible for coordinating with the PMs and backend to write tickets. Everyone on the team regardless of their level owns at least one feature. We also created a template JIRA ticket to ensure that tickets have enough detail. For example, one sample of this template:
Now it’s common to spend 1.5 hours on pointing per sprint, one less hour than before. If we miss an important requirement during planning, or cause an unintended side effect, we add it to the template so it’s not missed in future sprints. Examples include analytics, whether the feature is implemented over the course of multiple sprints and whether the modified code is consumed by other teams.
- “Is the code consumed by a different team?” was added after we made critical changes to clustering on the map. We realized later that these changes introduced bugs in other features we don’t own, because the map is heavily consumed by these features. The solution was to either keep the feature feature proof, or to agree to propagate the change to other teams.
- “Will the feature be implemented over the course of multiple sprints?” was added after we forgot to update the experiment name and realized that enabling it would release a half-baked feature in older versions of the mobile app.
- “Does this feature need analytics?” was added after a PM told a teammate about analytics requirements the day before an app release. Due to time constraints, the developer was only able to add the minimum amount of data for each event.
Ideally, each Lead would execute only the tickets in their ownership area. However, that’s not possible since the number of points per project varies each sprint. A teammate brought up these pain points in a Sprint retrospective. We used this as an opportunity to strengthen our tickets even further. Links to and screenshots of designs and a description of where the code lives all give the developer the context they need to get started. This reduces the need for a context dump from the Lead once the ticket is pointed and the developer has already started work. Last Sprint Retrospective a QA engineer said “Current search tickets provide in depth notes, pictures and videos. This greatly helps with testing.” QA engineers rarely need to reach out to developers with questions now.
The culture of a team determines the feasibility of impactful improvements. It’s easier to ignore the harder issues in a retrospective in favor of ones the team can quickly and easily address. This may lead to a flurry of action items with no real change on the team. It’s also important to foster an environment where developers of any level can bring up frustrations or concerns without needing to already have a solution in mind. In the SLB team, all it took was one developer to bring up his growing frustrations with long grooming meetings for the team to brainstorm together on possible solutions and make an impactful change.
