A well-known start-up in the UK, Moonpig is all about making someone’s day brilliant, writes Amanda Colpoys Lean, Agile & Growth Coach.
An ecommerce 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 methodology 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.
‘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 deliver only some improvements in efficiency – to really deliver at pace, we needed to improve our technology. Over the next two years, we focused on re-architecting the codebase, moving from a monolith to a service orientated 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 five 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
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:- ‘Everyone works in silos.’
- ‘There’s no communication within teams.’
- ‘We have too many objectives.’
- ‘Lack of trust to let people do their jobs.’
- ‘There’s no collaboration across teams.’
- ‘We have conflicting objectives.’
- Lack of alignment between teams
- Lack of visibility, communication and collaboration
- Lack of speed
- Ineffective processes
- Limited use of data and experimentation to optimise outcomes.
What and how?
What… 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’. How… To achieve these outcomes, I formulated a high level plan to:- 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. 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.