Home / Agile / Adopting Business Agility at Moonpig: A Case Study

Adopting Business Agility at Moonpig: A Case Study

A well-known start-up in the UK, Moonpig is all about making someone’s day brilliant.  An e-commerce business, it enables people to create personalised cards online which are then printed and sent to recipients.  In addition they offer a range of gifts and flowers.

Moonpig was founded in 1999,  before Lean and Agile approaches had become mainstream in the UK.  It was not until about 2013 that Moonpig first began to adopt Agile practices.  As with most organisations, it began in product engineering.  More unusually, having recognised the benefits of agile working, Moonpig’s leadership team were keen to see if the wider organisation could also benefit from this approach.

In this post Amanda Colpoys – a Lean, Agile and Growth Coach, shares her experiences as she set out to introduce business agility at Moonpig. She outlines the vision and the outcomes they hoped to achieve, and then describes how they sought to introduce changes, and the benefits delivered.

The Journey Begins – “Let’s Try This Agile Thing”

While this post focuses primarily on organisational agility, it’s worth covering the early beginnings in technology as those successes paved the way for widespread adoption.

Moonpig began its agile transformation by establishing a Product Management team and cross-functional teams of developers and QAs.

Like many, we used the Scrum framework to start optimising the software development process and we increased the emphasis on quality, adopting software craftsmanship and XP practices.

We also sought to build cross-functional skills within the teams, gradually phasing out the dedicated QA role and developing all engineers to design, write, test and deploy code.

One key challenge we faced was a monolithic legacy codebase.  It was clear that agile management practices could only deliver only some improvements in efficiency  – to really deliver at pace we needed to improve our technology.

Over the next 2 years we focused on re-architecting the codebase, moving from a monolith to a service oriented architecture. In parallel we invested in continuous integration and deployment.  As deployment frequency increased we migrated from Scrum to Kanban and emphasis shifted from tracking velocity to optimising cycle time.

That investment in technology is ongoing, but the combination of those early investments combined with improved working practices delivered considerable benefits.

We reduced deployments from once every three weeks to 3-4 times per day and average cycle time dropped from 16 days to 5 days. Improvements in speed enabled us to adopt lean product development practices, testing and validating iterative changes.

Collectively these efforts resulted in substantial business growth.  As well as the financial benefits, product engineering teams demonstrated much healthier results in the annual staff survey:

40% Higher Engagement

46% Higher Enablement

27% Higher Alignment

Consequently Lean and Agile practices were seen to be delivering benefits in speed, ROI and engagement.  Encouraged by these results, the leadership team asked me to explore the possibility of extending lean and agile working across the wider organisation.

The Context for Change

My first step was to understand the challenges faced within our business functions.  Having been firmly rooted in product engineering since joining Moonpig, I had little knowledge about the wider business operation.

I spent many months getting to know the teams, what they did, their processes and their challenges and frustrations.  The feedback I received will, I imagine,  be familiar to most:

This coupled with my own observations lead me to identify some core problems:

  • Lack of alignment between teams
  • Lack of visibility, communication and collaboration
  • Lack of speed
  • Ineffective process
  • Limited use of data and experimentation to optimise outcomes

However, I could see no reason why the working practices we’d used successfully in product engineering couldn’t be adapted to different contexts, and I started to formulate a plan to introduce change.

The What and How?

It’s worth briefly outlining what exactly I hoped to achieve and what positive outcomes I anticipated.


Essentially I sought to create a system of work that would optimise performance across the whole organisation, allowing us to innovate and move fast at scale, whilst being a great place to work.

The specific outcomes I hoped to achieve were improved business outcomes leading to higher ROI, reduced cycle time across all value streams and higher levels of employee engagement.

Inspired by Jonathan Smart, I refer to these outcomes as “better, faster, happier”.


To achieve these outcomes, I formulated a high level plan:

  • Align relevant people around key outcomes, removing conflicting priorities and dependencies.
  • Leverage lean working practices — visualising work, reducing work in progress and focusing on finishing.
  • Embed a customer-focused, data-driven, experimental approach to minimise wasted investment.
  • Create a culture of autonomy where teams are empowered to deliver the best outcomes.

Getting Started – Aligning the Teams

This was the most disruptive change.  Like most businesses we had organised ourselves by function, but I’d observed that this prevented us from aligning and collaborating effectively.

I proposed that instead of aligning ourselves by skill set –  by what we did – that we organise our teams around what we wanted to achieve.

To accomplish this I worked with the leadership team to define a long lived set of metrics that represented growth for our business.  This was very much about the “why” rather than the “what”.

An outcome like retention, for example, will always matter.  What we do to influence retention will change relatively often, but the outcome itself is constant.

I believed this mattered as it would help us create long-lived teams.  There is an overhead to commissioning and decommissioning teams so it was helpful to develop a structure with some long-term stability.

With a set of long-lived metrics in place, we were then able to work out which people and skills we needed to achieve those outcomes, and thus our new team structure emerged.  Inevitably we didn’t get this 100% right the first time, so we did adapt it once we’d seen the new teams in action.

Like many organisations we were influenced by Spotify’s approach; whilst we ended up with something quite different, it shared the same principles and we adopted their terminology.

As we evolved our cross-functional model we defined three tribes around core product and service, growth and foundations.  Each tribe contained multiple squads with outcomes which supported the higher level tribe objectives.

Squad Principles

As “squads” have become well-known, people have developed preconceptions about what a squad is.  To that end I’ll clarify the definition of a Moonpig squad and the underlying principles.  A Moonpig squad is:

  • Organised around an outcome and a value stream – it has a clear purpose
  • Resourced to achieve that outcome – it is independent
  • Empowered to decide how best to achieve an outcome – it is autonomous

Our squads are not, as is commonly assumed, “an engineering thing”.  If a squad’s outcome doesn’t rely on technology, there won’t be any product engineering in the squad.  Conversely, a mission which is product or tech lead may not need support from any business function. The mission and outcome determine the composition of the squad.

Functions in a Cross Functional World

It’s worth noting that functions are not obsolete in a cross-functional world; indeed they have a critical role.

Functions provide the guidelines and principles within which members of a function can operate autonomously across multiple squads.

The engineering function, for example, will be responsible for defining preferred technology and coding standards. A creative or brand function will define clear brand guidelines.

Functions provide the boundaries which enable autonomous working in cross-functional teams without compromising quality or consistency.

Getting Better, Faster and Happier

With our cross-functional squads in place, we were able to start leveraging lean and agile working practices to optimise performance.  These will be very familiar to anyone in the agile space.

Getting Faster

Aligning teams delivered instant improvements in cycle time, but there was still much room to improve.  Rather than adopt specific frameworks, I used the concept of “minimum viable agility”.  I encouraged each team to visualise their workflow, hold a daily stand-up and a retrospective every two weeks.  With these core practices in place we were then free to support each team to tailor and optimise their own processes.

Over and above this we put in place ways to measure cycle time and bottlenecks across all workflows so we were able to provide squads with real data to help them optimise speed of delivery.

Getting Better

Alongside improved delivery capability we wanted to encourage a more data-driven, experimental approach.  Experimenting increased in all areas, helping to optimise everything from marketing content to product range.  It is still early days and there is plenty of scope to increase the tempo, but the widespread adoption is encouraging.

Cross-functional working supported the growth in experimentation as skills and experience in this area cross-pollinated within squads.

Getting Happier

You’ll recall at the beginning of this post I described how product engineering teams had shown much higher levels of engagement, enablement and alignment.  By extending the same way of working to all of our teams we hoped to see scores in these areas increase across the board.


Before I discuss outcomes, it’s worth putting them in context. The changes I’ve described took place over 6–8 months, so we are still at the “MVP” stage!  However, as with an MVP, we are looking for early validation of the approach, and the signs thus far give us reason to be confident.

Getting Better

Whilst I can’t reveal actual numbers, the squads delivered very healthy growth during the first 6 months. A less scientific, but no less revealing, indicator was that the leadership team were extremely pleased with the squads’ results!

Getting Faster

We saw more dramatic gains in speed, particularly in delivery of our marketing content where we saw cycle times reduced from months to days.

Getting Happier

Happiness was difficult to measure as we had no baseline. However, I was able to extrapolate some results by comparing annual staff surveys from before and after the change. These saw marked improvements in areas such as alignment & involvement (+13%) and enablement (+21%).

While this is the beginning of a journey, and there is still much room to improve, the early signs have given me confidence in the approach.

It has also convinced me personally of the potential of business agility.

As long as Agile remains a “tech thing” we consign ourselves to optimising a single corner of an organisation.

Lean and Agile comprise a set of principles which are ultimately agnostic of technology — every part of the organisation can benefit.

You can read a more detailed case study of Business Agility at Moonpig here

About the Author

Amanda is a freelance coach and consultant helping organisations to adopt lean, agile and growth practices, enabling them to grow, innovate and deliver value at scale.



For more information on Lean and Agile, you can listen to our webinar on the Strategic Potential of Lean and Agile

For more information about Agile Project Training, please click here

If you enjoyed this post, make sure you subscribe to our RSS feed!

About Nadine Rochester

Nadine Rochester
Nadine is a marketing director at Strategy Execution.

A experienced marketing strategist and technologist, Nadine is also passionate about project management, business analysis and agile PM, managing and contributing to the company PM blog servicing 40,000 monthly users.

Discover the new Adaptive Strategic Execution Programme

%d bloggers like this: