This was originally published on my blog in January 2016. It has been updated to the past tense.
At reed.co.uk, we had been 64%* agile for many years. We had watched others, tried things ourselves, failed and picked ourselves up again. One of the most recent additions to our internal vernacular was that of ‘Bubble Squads’, or cross-cutting teams that quickly form around particular objectives, achieve their goals and burst, releasing their team members back into a happy, energetic soup of talent. This is a model we started to experiment with, and something I wanted to share as we learned from it. To explain where this concept comes from and why we were considering it, it feels important to set the scene. This post is the amuse bouche — the next in the series will be the starter — I’m hoping you can contribute to the main course.
reed.co.uk’s agile history
Agile reared its head in reed.co.uk’s product team as long ago as 2007, in response to a business objective which required rapid delivery of a significant website overhaul. It wasn’t so much a planned adoption of a new development methodology as a fight or flight response to an overwhelming challenge. Deliver or die — which meant no more waterfall and no more 12 month projects. We threw ourselves at agile, and delivered on time; it wasn’t elegant or efficient, but it worked. We shipped the product, and the team and business kept growing.
We developed a unique Agile process all of our own, wilfully blending elements of RUP, XP and Scrum like a pie-eyed teenager mixing advocaat with sherry and bitters. We eschewed pigs and chickens, but focused on timeboxed deliveries and regular reviews with senior stakeholders. We were learning and eager to improve, but to be painfully honest, rubbish.
In 2013, it took the external perspective of our friends at Endjin to point out just where we were most misled. We decided to throw out what I now derisively refer to as ‘Ridley’s Agile Process’, and simplify to Scrum as our process. Whether I liked the pigs or chickens or not, it at least meant we could point to a book when new staff joined us and say, “We do this”.
Since then we had learned, experimented and made enough mistakes to make it look like an art form. If there was a YouTube channel for Agile fails, we’d definitely have a few entries. However, we were privileged in the same period to employ and learn from incredibly talented people from a variety of Lean and Agile backgrounds and immersed ourselves in London’s Agile community. We began to concentrate on the philosophy rather than the practice of Agile and educate our entire business on the common sense benefits of lean principles as they apply to processes and organisations. We weren’t even close to perfect, but we had enough scars to compare at the bar.
Spotify and the Squad, Chapter, Guild model
Read more here about Spotify’s model of mixing teams
One of the critical developments of our product team’s evolution was the wholesale adoption of Spotify’s Squad/Chapter/Guild model. One lesson that it feels important to share was that this took us two attempts — the first time, just before we worked with Endjin in 2013 — was a slow burning failure.
When we first adopted the Spotify model we created teams that were closely aligned with their product lines. They had two strong leaders in each team — a tech lead (always a senior developer) and a product owner (initially, often a re-titled Business Analyst). Whilst we felt that we were making a marked improvement for our teams, we had actually made two important and costly mistakes.
The first mistake was not understanding the critical difference between the Chapter Lead and Tech Lead roles. Our tech leads had strong technical leadership but also management responsibility for many of their Scrum team members. We had acknowledged that teams needed to be cross-functional and long-lived, but fixing management within the teams removed the elasticity of resource allocation. In retrospect, this appears obvious — as it should to you with the benefit of perspective. To us, in the midst of evolving from one team structure to another, this seemed like the most sensible option but meant that we missed a critical benefit of Spotify’s model.
The other mistake we made was less obvious, but even more pernicious. In creating the strongly aligned teams we cemented a fixed team-to-codebase relationship. Each team was responsible for their product line and their own codebase. Many of our products are codependent on each other for feature improvements and the seemingly innocuous decision of requiring that each team work on its own codebase took a slow-burning toll.
This was nothing but a philosophical decision that was taken — by me — that had the unintended consequence that when a developer reached the boundary of their codebase they were forced to stop work and wait for another developer on the other side of the code wall. A requirement to mirror a feature in another part of the product suite outside of a team’s own codebase meant a political negotiation by our Product Owners.
Over months, duelling backlogs became the natural order, with impassioned POs imploring each other to prioritise the development of their own critical roadmap features. This then naturally led to the conflicts being escalated to more senior management and undoing any attempts we made at allowing teams autonomy of their own roadmaps.
Spotify, Round 2
Our second attempt at the Spotify structure was from a more experienced and committed position, starting at the beginning of 2015. With a growing group of agile evangelists in our Agile Practice team (broadly, our Scrum Masters), we were better equipped to coach teams on the new chapter lead role. We made the separation between technical authority within a team and line management much more apparent and clearly reflected it in reporting lines.
This also had the side benefit of ensuring that the ‘tech lead’ role was not always occupied by a C# developer, which had often been the case, as our back-end developers tended to outnumber other disciplines within a team. The move to real chapters even allowed us to experiment with ‘leaderless’ teams which steers even more closely to the philosophy underlying Agile.
With the rebooted teams, we also made the important decision to ensure that developers had a responsibility and a right to delve into other teams’ codebases to ship their own features. Whilst we still demanded respect for the work of others, we’ve removed the entirely foolish requirement that teams couldn’t work outside of their own repos. For an almost entirely notional change, this is still taking a while to flow through our behaviour.
Needless to say we feel that with a renewed understanding of how squads, chapters and guilds should work we’re now demonstrating more cohesive and aligned teams. There’s still a way to go, and in the next post, we’ll look at why we believe Bubble Squads are the next sensible evolution of the Spotify model for us.