Bubble Squads: theory and practice
This post is the second in a series of two. The previous post contains the back-story to the creation of the concept which we call ‘Bubble Squads’. This post is concerned with the theory and practice of the squads themselves.
Our concept of Bubble Squads has been heavily influenced by the Lean philosophies, the Spotify team structure, and Agile practices like Scrum and Kanban. However, where there is often a strong preference for long-lived, cross-functional teams in these methodologies, we felt that there was perhaps a benefit to trading longevity (and higher relative performance) for carefully selected, appropriate resourcing that varies depending on the objective and the lifecycle stage of the project.
Bubbles are a conceptual structure that we’re explaining to our teams and allowing them to choose to use. We still value long-lived teams, but we wanted to share this experiment with you from the beginning.
As Is, To Be
Scrum teams at reed.co.uk look much like anywhere else. Product Owners, agile coaches, UI, UX, developers and SQL experts. They’re long lived (often years old), have their own names and personalities*, hire their own resources and are assigned themes and epics which they break down into sprints. Line Management sits outside of the Scrum team structure, with chapter leads providing guidance and appraisal to members of the team.
There’s nothing inherently wrong or broken with this model — many companies use it successfully, and it’s worked well for us. However, there is a sense that when aligning talent with problems that need solving we could be smarter and more effective. We also believe that we can add non-development resource to these teams, especially in earlier stages of the product lifecycle where we should be focusing on customer learnings and commercial realities. Adding sales savvy and financial modelling skills to product teams at earlier stages may well prevent months of unnecessary work, and serve as an incredible education for everyone involved.
Our key goals with Bubbles therefore are:
- Small teams of experts
- from across the whole business
- given a single, clear, customer focused objective
- that use resource flexibly from a wider pool
- Learning quickly (failing if necessary) and preventing unnecessary work
And the key differentiators from a Scrum team are:
- Small — cross functional, but resourced specifically for a single objective
- Short-lived — bubbles ‘burst’ when they achieve their objective
- Single-minded — if you’re assigned to a bubble, you do nothing but work on your objective
If I had to be really stark about the difference — Scrum teams are like the A-Team (or the Famous Five) while bubbles are like MASK (or Thunderbirds). I’m a child of the Eighties. Live with it.
* We’re still not sure how we allowed the Hypercrabs to be called that
Bubbles are better
I previously wrote at length about team size and the benefits of smaller teams. Needless to say, I believe that smaller teams are generally more effective than larger ones. Timo Hilhorst, who worked both within our larger product organization and one of reed.co.uk’s startup projects, Startup Startup, had this to say about his experience in a 4 person team:
“Paradoxically, I’ve found working in a small, focused team actually allowed us to achieve more in a shorter timeframe. In small teams, people are forced to complete any work they can do, rather than wait for a specialist to pick it up which is often the case in larger scrum teams.”
We’ve learned a lot from the reed.co.uk startups, not least just how incredibly effective these small groups are. But, Timo’s experience also highlights one of the issues that we’ve found in our long lived product teams who are often moving through product maturity levels. It’s true that having passionate experts delivering a goal and being willing to pick up any task is a great thing — but it’s ultimately not as sustainable as having people doing what they love and offering progression and mastery.
The behaviour of a team working on validating a hypothesis is very different to a team managing updates to an already operational product. Not only is the behaviour different, but the resources and skills required are very different as well. At the moment, our scrum teams, long-lived as they are, can often be working across stages of the product lifecycle, requiring that they fill their backlogs with different types of work, balancing discovery items with delivery through such mechanisms as Dual Track Scrum (a tool some of our teams have experimented with). There is almost always an element of context-switching, by virtue of the team filling a backlog with both short and mid-term work.
We’ve found that in an attempt to bring together experts in different disciplines our Scrum teams can swell, and sometimes those experts are juggling many small projects to fill their backlogs — not every Sprint needs a UX researcher, nor does every Discovery need a SQL developer.
The concept of Bubbles, then, is primarily driven by a desire to let the people who know best — the ones facing the work — make the decision about which resources they want to commit to an objective. How they deliver, who they deliver with and even how long they take to deliver are details that the team must propose when they commit to achieving their goal together. The business must then trust that these teams will deliver.
Those not involved in a new bubble are free to seek work that they can more effectively contribute to, hopefully by having visibility of a prioritised backlog and forming bubbles of their own.
We passionately believe that experimenting is better than theorising, and that we can only really learn if we test, fail if we need to and move on if it hasn’t worked. Bubbles is another experiment, and by having more teams involved, we can test and learn faster.
If the concept sounds interesting, you can take the low risk approach and see what happens with our experiment. Or, alternatively, if you’re brave you can try your own bubbles.
How should you go about it?
Define your objective
The idea of Bubbles will work best where there is a clearly defined success statement. Not, “make a mobile app”, but perhaps, “build a proof of concept app and user test it with 50 users”.
Make your team
Having defined your goal, speak to the people who might work on this. Explain the big vision and the short term objective. Let them give feedback on who they need to achieve the short term goal, and allow them to commit to a timeframe to deliver within. Aim for no more than 4–5 people in the team.
Protect the team
Once the team have identified themselves and committed to achieving their objective, make sure that they work on nothing but that goal. Context switching is to be avoided at all costs, and while the team will be made of specialists, they should still pick up cross-functional skills from the other experts in their bubble. If possible, sit the team together and away from their previous distractions.
Burst the bubble
The team hit the objective — celebrate the success (or failure), and then let the team fall gracefully to earth. Assign new projects to the team, which may include returning them to their protective Scrum teams.
Then let us know how it went!
Bubbles are new for us and we’re just in the process of trying to choose objectives well suited to this structure and coach our teams about where it might be useful. Watch this space and we’ll let you know how our experiment worked.
Oh, and I’ve also got half a post written about why long lived teams are better than ephemeral ones — just ready to point out the flaws in my own argument.
Originally published at www.ridley.co on January 26, 2016.