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 series 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, it’s 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 are 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 series, 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!
What’s next?
In the next post I’ll start with “why” — why did we want to adopt business agility?
