Restructuring teams to achieve more with Spotify’s squad framework, a case study.
Growth in business is a wondrous thing. However, it can come with a rather weighty collection of baggage. This can often blindside those that are so enamoured with achieving it. Any issues associated with growth are often defined as “a good problem to have”. Whilst this may be true that does not excuse them from being problems.
One of the more prominent issues introduced to growing start ups is that of structure. In this article, I will explain the difficulties our developer team at Birdie experienced as we grew. I will then go on to explain how we resolved these issues and significantly improved our velocity and focus using Spotify’s squad framework.
The problem
“Lack of direction, not lack of time, is the problem. We all have twenty-four hour days.”
Zig Ziglar
I’m sure the scenario we faced at Birdie has symmetry with many other tech start-ups. We had recently secured our series A funding and were going through the motions of upscaling our development team. We had grown from a modest pod of three devs into a team of seven. Initially, we saw this mainly as an opportunity to get more done; and in the beginning, this seemed to be the case. However, the demands of managing an API as well as both web and native apps began to surface.
Picture this: you come into work, open your laptop and decide to take a look at what’s on the scrum board. You see a board plastered with more tickets then you possibly have time to read. There are six other people involved in this smorgasbord of deliverables and its abundantly clear that multiple goals are trying to be achieved at once.
It’s now 9:15am, and the team gathers for stand up. Rather hilariously, all the devs, designers and PO can no longer fit in the office in such a manner as to make a circle, so some banish themselves to the outer edges. Things start off peppy, but even with people trying to only state what is relevant, we still find ourselves running over.
Eyes begin to glaze as the aforementioned broadness of our sprint becomes palpable to all that attend. It’s now 9:50am, and some people have excused themselves to continue focusing on what they need to complete before the end of the sprint.
It’s 2pm and the team have their retrospective. Everyone writes their opinions about how the previous week went on the whiteboard. It’s not long until we’re struggling to find space on the whiteboard, signifying the futility of any attempt to finish this ceremony in 30 minutes.
We vote for the issues we believe to be the most prominent, but like with previous weeks we still find ourselves with a relatively spread set of concerns. We cut conversation off 40 minutes later with a rather sour feeling that not everything has been settled.
Then, the sprint planning begins and is probably the most drawn out of the ceremonies. It could easily run for over an hour and a half. The large nature of the team means we cannot frequently get them together for preparations and technical refinements. This means that when people are brought together, those that have earlier technically refined stories need to re-explain issues to other developers.
It was plain for all to see that this large structure was causing some developers to lose involvement in the direction of the work and its relation to business demands. It was becoming harder and harder to focus in these meetings. A cacophony of context would often obscure our ability to see the full picture in a sprint.
At last, the sprint is created and we begin our work. What we had was a situation where seven devs, two designers and a PO were working under the veneer of a single acting unit. In reality, we had multiple goals that team members were more passively directing themselves towards.
In short, our team’s size was responsible for causing too large a breadth of work for people to focus on. This was illustrated by our relentless ceremonies. We needed to change if we wanted to keep focus on delivering quality work.
The solution
We were essentially faced with three options.
Firstly, we could try and improve process so that a larger team could continue to thrive. If anything, this is wildly optimistic.
Secondly, we could split teams by specialisation (API, frontend, mobile etc…). The main problem this causes is an incredibly tight coupling between specialities. Let’s say the front end team finishes their work three days before the API team can finish theirs, you end up with a bottleneck. The front end team will now have to create more work for themselves whilst they wait for the API team. This interdependency between teams will almost completely undermine the whole reason you split the larger team up in the first place.
Another problem with this, is that it leaves you little room for restructuring in the future. Let’s say another year passes and now your “API team” is twice the size. You’ll find its complicated to further specialise developers so that you can split it further.
This method also leads teams to define business problems by technology, lacking any tangible business ownership. Things get blurred behind non-domain specific terms like front end and back end. Once again we begin to move our developers away from business direction, which causes them to fade into obscurity. You’ll know this is a real issue in your company when people become afraid to speak directly to developers.
So, what we can deduce from everything we don’t want is something we do. The third, ideal option. A splitting of teams into smaller sub groups that are autonomous and directly related to single business domains or goals. This is where Spotify’s squad framework comes to the rescue.
This video does a great job of explaining the squad framework in depth. However, the main point is that you split your teams into autonomous entities or “squads”. It’s important that you keep them small. You also need to give them a single mission that is directly related to business goals and is close to your product.
In order for these squads to be truly autonomous, it is vital they are multidisciplinary. If you find that your squad is always having to borrow resources from another, then a restructure may be in order.
At Birdie (here’s a little more about what we do to provide context) we split our large team into two squads. One focused on our Alert Manager, which allowed care managers to stay on top of any red flags concerning an older adult’s care. Another focused on medication management, which provided care managers to effectively handle medication schedules, dosages etc. for older adults. Finally, one team was to focus on how we could use our existing data to deliver predictive insights to care managers about the wellbeing of older adults in their care.
Team members were given choice over which squad they wanted to join. Luckily people managed to even themselves out, but in case this doesn’t happen, it’s important to note that one of the benefits of squads is that they are prepared for restructure. It’s common for squads to either evolve into multiple newer squads after growing, or revolve into squads of the same size but with a new mix of members when necessary.
As we were already using OKRs to track our progress, we decided to implement this framework onto our squad missions. This provided a definitive coupling between a squad’s direction and our domain’s.
We also began to see the creation of guilds (structures that spread across squads) soon after we began to form our second round of squads. Members from each squad would join outside of their normal work to discuss the creation of a design system that would help improve the accessibility of all our products.
The impact
As soon as we split these teams, you could feel the increase in engagement from developers. There was a palpable sense of excitement that teams got by getting closer to the product and achieving goals. The first thing we really noticed was the improvement in communication. Direction was entirely clear for all squad members. There was one goal per sprint and therefore everyone knew what they were doing.
This had a knock-on effect on ceremonies. Stand ups became much shorter. Not just this, but we began to notice a natural evolution towards a leaner approach to agile processes. Sometimes, developers knew exactly what everyone else was working on. Communication became so commonplace that we could drop some of the dogma attached to the validity of these processes. If we felt it necessary to have a stand up then we’d have one but felt much more capable to decide whether it was needed or not.
Velocity increased as we spent much less time on ceremonies and could communicate more effectively. There was also a lot less mental cognitive resources required to understand the full scope of your teams work. Which meant that you rarely looked at a scrum board and felt overwhelmed. Team members were able to effectively help each other much more than they had before. The autonomy of squads meant that we weren’t governed by the doctrine of what may have worked for another team. We decided what worked best for us, and became dedicated towards a specific product vision.
Being so close to this vision also brought everyone very close to that particular product. Developers were able to confidently discuss their respective areas of the business both internally and externally. Not only this, but they were capable of making well-founded suggestions for what the future direction of these products should be. This launched the engineering team beyond the technical realm, making it a force for domain-driven innovation as well.
The creation of a guild mentioned earlier, allowed developers to occasionally work in other areas if they began to feel too siloed. This provided a strong mechanism to give respite to such focused work, as well as encouraging cross-squad communication.
The potential downside to this new structure was squads not having visibility of what other squads had done. We diminished the effects of this by having weekly snippets (discussing what had and hadn’t been achieved) and demos (demonstrating created work) for squads.
In short, what we created were small, autonomous teams that attached themselves directly to business visions and goals. A strong sense of ownership was felt across these teams, allowing them to communicate effectively and drop or shorten unnecessary/lengthy processes as a result.
So, to anyone that is struggling to be one team…
If you’re having too many meetings, if ceremonies are anaemic and overdrawn, or if you’re experiencing a lack of direction, I would highly recommend taking the first steps into splitting your team into squads.
We’re hiring for a variety of roles within engineering. Come check them out here:
