Adopting Business Agility at Moonpig, Part 7: Iterating on the Squad Model

About the Series

In 2017 I had the exciting opportunity to introduce business agility at Moonpig, one of the UK’s best known start-ups. This series of blog posts provides an in-depth case study of my experiences, and I hope will provide a useful set of steps for others looking to adopt and scale lean and agile. I have written this for the benefit of the wonderfully generous lean and agile community from whom I have learned so much. I hope that by sharing my learnings, others can benefit as I have.

Introduction

In the previous posts I described how we moved to a model of cross-functional squads, and the broader framework in which these squads operated. In this post I’ll discuss how we evolved the model. Having put it in to operation, we were able to observe what had and hadn’t worked and identify improvements.

What wasn’t working?

By and large the first iteration had worked really well, but there were a couple of problems we observed:

  1. Some squads were more about planning than execution

2. Some squads had more than one outcome to pursue

Both of these issues arose out of the gap between my knowledge about certain elements of the business, and the business leaders understanding of exactly what we were trying to achieve with the cross-functional model. We recognised them relatively early on and were able to make the necessary changes.

Despite your best efforts, it’s very unlikely you will get alignment right first time. There is only so much time you can spend planning, eventually you have to put a plan into action and see what works and what doesn’t. What’s important is that you react to what doesn’t work quickly — inspect and adapt.

It’s also important to manage expectations — before we rolled out the team changes I had been at pains to warn everyone that it was unlikely the new model would work perfectly, and that we would want feedback on what wasn’t working so we could respond to it. Preparing everyone for inevitable changes helps them to be accepted.

Beyond these relatively minor tweaks, there was a bigger challenge I needed to address. Some squads were too big to self-organise effectively and struggled to collaborate effectively. This lead me to reconsider the structure we had and how we could maintain alignment without compromising agility.

Tribes, Pods & Squads: Evolving the Model

Defining tribes

Previously tribes had been a concept we’d used purely for planning purposes. Yet over the first few months of seeing the squads in action I’d recognised potential benefit in more clearly defined tribes. Spotify, who developed the concept of tribes, used them as a way to make the organisation feel small as it started to grow. Tribes were used to develop small communities built around a shared purpose.

Whilst Moonpig is a much smaller organisation, it is still big enough to benefit from the concept of tribes. We had groups of squads that shared a common broad purpose, and I could see value in formally grouping those squads and articulating that shared purpose.

I recognised the need for three tribes:

Product & Service — this tribe was focused on developing and evolving our core customer value, both physical and digital. It was focused on customer missions — solving customer problems.

Growth — this tribe was essentially about marketing our customer proposition — getting more people to experience that core customer value. It was focused on business missions, leveraging our products and services to drive acquisition, activation, retention and revenue.

Foundations — this tribe was focused on support missions. We had some big re-platforming initiatives, so while this had high long term business value, it was not delivering new customer value in the short term.

The Product & Service tribe consisted of squads focused on designing and developing our card and gift ranges. This included creating the physical products and evolving the digital products which support their personalisation. Product & Service would also be the home of any new innovation around either physical or digital product.

The Growth tribe consisted of squads organised around the funnel, focusing on areas like acquisition, retention and revenue.

The Foundations squads focused on defining and building core elements of the new platform.

Size matters — introducing pods

It’s a well known fact within the agile world that smaller teams are more effective — smaller size makes it easier to self-organise. Spotify advocate a team size of 7–9, Skyscanner believe 8 is the maximum effective size. My own experience confirms this, but it also left me with a problem. What happens when we need more than 8–10 people to deliver an outcome?

The solution to this was “pods”. Reflecting on the problem I reminded myself that the core purpose of squads was to align people. Having observed the squads in practice, it was clear that multiple workstreams might be needed to support an outcome, and they didn’t have to live in a single squad, so long as the outcomes were shared between relevant squads and alignment was preserved.

A pod was simply two squads which shared the same goal — one team with two workstreams. Crucially each pod had a single data analyst — this provided a single source of truth on which hypotheses and experiments could be based.

Squads worked towards a pod goal which in turn supported a tribe goal

Sharing an outcome ensured the two squads would still collaborate, but were able to execute in smaller, more efficient units. Different pods worked in different ways depending on their goals and initiatives, but I’ll describe how the Retention pod worked as an example.

Pods in action

The Retention pod was made up of two squads:

Retention Web — a product engineering squad consisting of a product manager, engineers and a UX designer

Retention CRM — a CRM squad consisting of CRM marketers, a creative designer and a copywriter.

The pod would meet each Monday for a weekly growth meeting. They’d review the tests they’d run previously and analyse the results. Based on the new learnings, they would then meet to brainstorm together and generate new ideas. If the ideas involved experiments around emails, they’d be picked up by the CRM squad. If the ideas involved experiments on the website, they’d be picked up by the product engineering squad. The teams used shared tooling to capture and rank ideas and document analysis and learnings. Experiments themselves were executed within the individual squads, but they were generated by people across the pod.

Where coordination was needed the two squads could self-organise. There was also the freedom to share resource and expertise across the pod. For example UX designers could help improve the layout of emails. Creative designers and copywriters could develop assets for landing pages on the website.

Aside from speed, alignment and knowledge sharing, the other benefit of this way of working was learning how to work more effectively. Whilst product engineering teams are familiar with the lean approach and the test and learn cycle, it was relatively new to the CRM team. Working closely together enabled the CRM team to learn from their product engineering colleagues and hone their own skills around experimentation. Likewise, the product engineering team were able to improve their understanding of email marketing.

What’s next?

The last few posts have covered how we designed cross-functional squads aligned around strategic goals. In the next post I’ll discuss how we went about optimising those squads by introducing lean and agile working practices.


Could I help your business to become better, faster and happier? I am a freelance coach and consultant that helps organisations adopt business agility. If you’d like to know more, please feel free to connect with me on LinkedIn.