|Case Study: Adopting Business Agility at Moonpig|
Case Study: Adopting Business Agility at Moonpig
Case Study: Adopting Business Agility at Moonpig: A Case Study Author
In 2017 I had the exciting opportunity to introduce business agility at Moonpig, one of the UK’s best known start-ups. Having achieved a measure of success adopting agile practices within our product engineering team, Moonpig’s leadership were keen to see if the rest of the organisation could also benefit from agile adoption. For a number of reasons, I thought I should write about my experiences.
Firstly, I’ve told this story often at conferences and meet-ups, but I’ve found that many people crave a level of detail that cannot be captured in a 30 minute presentation. I hope this article will allow me to share that detail, explaining how I approached this project, what worked and what didn’t.
Secondly, I have benefited enormously from the generosity of the lean and agile community. Learning from the community has enabled me to take on this challenge and achieve some success. I’d now like to return the favour and share my own experiences in the hope that others can benefit in turn.
And finally, I have become frustrated that achieving agility too often seems dominated by what Dan North eloquently describes as “religious methodology”. We can be grateful to Scrum for popularising agility and turning it into a mainstream concept. However, Scrum, through no fault of the framework, is often misunderstood, misinterpreted and misapplied. Likewise its scaled counterparts might support agile delivery, but they won’t necessarily achieve the full raft of benefits that are at the heart of lean and agile working.
I’ve been reflecting on why Scrum, LeSS and SAFe have become so dominant, and I believe it’s because they appear to provide instructions on how to “be agile”. Fundamentally lean and agile are about a set of principles, and translating principles into practice is hard. A set of principles with no guidelines is much like ingredients with no recipe. The Scrum family provides a recipe. But as with recipes, if you don’t understand why you need to take each step, you start to skip steps. Scrum fails to deliver when people understand what they need to do but don’t understand why.
In this article I am going to attempt to provide an alternative recipe for adopting and scaling agile. Using Moonpig as a case study I will attempt to provide a series of steps that provide a set of useful guidelines.
Sources of Inspiration
I’ve been lucky to learn from countless people and organisations, but I’d particularly like to thank Douglas Cook, Chris Downey and Lisa Venter of Skyscanner, Harsh Sinha of Transferwise, Jonathan Smart, Dan North, Barry O’Reilly, the Poppendiecks, John Cutler, Henrik Kniberg, Joakim Sunden, Sean Ellis, Brian Balfour and Jeff Gothelf — to name just a few!
Starting with why
Introducing change is hard. Very hard. One way to make it slightly easier, is to take the time to communicate clearly why you need to change. At the time we began introducing business agility at Moonpig, most people outside of product engineering had little or no knowledge of lean or agile — and most would have believed them to be “tech things”.
As we started to introduce changes, I wanted to ensure people understood why we were making these changes, and what the benefits would be. I wanted our teams to understand that these changes were not borne of some executive whim, but were driven by changes across industry and were underpinned by solid principles and reasoning.
The external factors
As I mentioned in the introduction, Barry O’Reilly is someone that has strongly influenced my thinking. In his keynote talks, there are a couple of interesting facts Barry often quotes:
50% of companies that were in the Fortune 500 in 1995 had dropped off the list by 2015.
The average lifecycle of a company in the 1960s was 67 years — today it’s 15 years, and it’s falling.
Having dropped these “bombshells”, the point Barry goes on to make is that industry has changed. Whether you consider yourself a technology company or not, technology has fundamentally disrupted the business landscape. It has made it much tougher and more competitive.
Barry argues that to survive and thrive in this new world of business, companies need to change the way they work. They need to be able to move faster, and they need to be able to serve their customers better than their competitors. They need to innovate and they need to learn and fail fast.
While Moonpig retains much of its entrepreneurial, start-up spirit, it is in fact now 18 years old, and is bigger than many of its competitors. It is smaller than many assume, but still big enough to be cumbersome, and as with any other business, it is not immune to being challenged. It too needs to move faster and learn faster to keep succeeding. This is one reason change was necessary.
Highlighting these external factors matters; it helps organisations and the people within them understand that change is vital.
The internal factors
The story of Moonpig’s agile journey started several years ago and as with many companies it focused mainly on software development. Within that space we adopted cross-functional teams early on, leveraged agile and devops practices to improve delivery capability and introduced a lean approach to product development — using data to form hypotheses and testing assumptions. This way of working drove big benefits — as well as improved efficiency we delivered better outcomes and healthy business growth. In staff surveys, teams leveraging lean agile practices also showed significantly higher levels of engagement.
At the time we were based in offices in Southwark, and our office happened to have a wall down the middle of it. I came to think of this wall as highly symbolic. On one side of the wall we had our product engineering teams, on the other side of the wall we had our Marketing and Commercial functions.
Having spent the first few years of my Moonpig life firmly on one side of the wall, I had started to take for granted the benefits that agile working had delivered. This is not to say we were perfect, but there were a lot of positives. People worked at a sustainable pace, they enjoyed what they did, they were highly collaborative and there was a hunger to learn.
As I began to explore the potential of business agility, I started to spend much more time on “the other side of the wall”. And it was a quite a contrast. These were some of the things I started to hear:
I’d imagine these sorts of comments would be familiar to most large scale organisations. The benefit of this feedback, however, was that it proved our current approach in those areas wasn’t optimal. It supported the case for change.
“Insanity is doing the same thing over and over and expecting different results.” - Unknown (apparently this has been incorrectly attributed to Einstein!)
My experiences on both sides of the wall taught me that we had in some ways become a hybrid organisation. We had two different mindsets and two different ways of working — effectively we had two different cultures. The contrast between these two worlds suggested that agile working seemed to be a better system, and it inspired Moonpig’s leadership to adopt agility across the wider organisation.
To read Amanda Colpoys full case study download here.