In the previous post I described our squad principles and roles. In this post I’ll talk about the broader framework in which the squads operated — some of the ceremonies and practices we introduced to provide visibility and coordination between squads.
I spend most of my days with large digital focused organisations. They usually have diverse platforms and scores of people trying to continuously deliver. But, like all huge organisations, implementing change, whether a product, process, business practice etc is a mammoth task. They talk agile, but to many, it is an elusive as a handful of sand. At the same time, agile has long since passed the tipping point. There are too many experts screaming it from the rooftops.
In the previous post I talked about the process of moving from a functional to cross-functional structure. In this post I’ll describe how we used Spotify’s model of squads and tribes as a guide. What we ended up with was quite different from Spotify, but it relied on the same principles. I’ll also outline the values and roles within our squad model.
In many of the places that I have worked, both as a consultant and as a part of a product delivery team, it is usually a case of keeping the Enterprise Information Security team (EIS) at arm’s length. Truth be told, many teams hold to the old adage that the less EIS get involved, the better. Even more so with agile delivery, as the focus towards shorter, more targeted delivery means that EIS is a thorn in product delivery’s side. And though this article leans towards agile delivery, the points made are equally applicable to any waterfall delivery.
Beyond the obvious reasons why alignment is sensible, for me alignment was critical in order to promote speed. I believed this would help achieve one of our key outcomes - to get faster.
Lean Startup and Design Thinking are two complementary principles that can be used in the process of creating and building new businesses, products or services. These principles are widely used in large and small organizations. But what is the difference, and when should you use each?
Before we dive into that, let me first explain both principles.
Recently, I have undertaken a number of roles as an Agile Engagement Lead, working with large corporates as they began the journey of migrating their operations and delivery to agile ways of working. In most cases, I was starting with entirely new teams who had absolutely no agile experience. It was challenging, but interesting as I had to develop a systematic approach to rolling out Scrum. There were a number of hurdles that kept on repeating themselves and along the way, I was lucky to be able to pilot a few new approaches
Have you ever had a boss who rejected your idea? What can you do about it? Pretty much nothing.
Unhappy with the company direction? What can you do about? Pretty much nothing.
You are assigned to work on something that you think is a waste and possibly detrimental to the company. What can you do about? You get where I’m going with this.
In order to organise my own ideas, I realised it would be helpful to have a clear vision for what I wanted to achieve, together with measurable outcomes. I began with a mission statement:
“I want to design a tailored system of work that optimises the entire organisation, allowing Moonpig to innovate and move fast at scale, whilst still ensuring it is a place that people love to work.”
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”.