Improve Business Processes with Agile

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

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:

• ‘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.’

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 processes
• 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.

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.

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 led 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

Once our cross-functional squads were in place, we were able to start leveraging lean and agile working practices to optimise performance. These will be very familiar to anyone working 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.

Outcomes

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 Minimum Viable Product (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 faster… We saw more dramatic gains in speed, particularly in delivery of our marketing content where we saw cycletimes reduced from months to days. Getting better… Whilst I can’t reveal actual numbers, the squads delivered very healthy growth during the first six months. A less scientific, but no less revealing, indicator was that the leadership team were extremely pleased with the squads’ results! 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. Before you make any transition of model, you should be prepared to have the following in place to help specify what is wanted from change, monitoring and progress and measuring results. See more from TSG Training on Agile, DevOps, Service Management and all life cycle courses:

• Classroom & Virtual here.
• Online, Self-Study here.

Download Security Versus Virtual Working Here