How we scaled agile in a large organisation to create a more responsive team and to build software products more closely aligned to business priorities.
MoJ Digital is turning three years old and despite its young age it has been very successful – not only has it built a World class digital delivery capability from the ground up and delivered all four of its Government exemplars it has also been leading agile transformation across the justice system.
Our three year birthday is a good checkpoint for an organisational retrospective to see how we are doing and where we should go in the future.
Why we needed to scale agile
The MoJ digital team had grown rapidly over the last few years – from a handful of people to close to two hundred digital experts. We are huge advocates of agile development with some teams using scrum and some using Kanban. However we started to get the feeling that agile designed and optimised for one team was not appropriate now we had a large number of delivery teams. We were lacking the additional guidance that was required to align many teams working together. That is when we started investigating a scaled agile framework.
Rethinking agile organisational design
The reasons we were looking to optimise the organisational design to scale agile are to:
- Create a more responsive organisation
- Build software products more closely aligned to business priorities
- Accelerate development by reducing bottlenecks, coordination and handoffs
- Create a great place to work by giving teams more authority and autonomy
- Create a flatter organisation with less management overhead
After some intense discovery we decided that the Large Scale Scrum (LeSS) framework would be ideal for our needs. Since LeSS is based on Scrum, the learning curve of adoption would be minimal.
What is LeSS and how is it used
Large Scale Scrum (LeSS) is a scaled up version of one-team Scrum, and it maintains many of the practices of one-team Scrum. In LeSS, you find:
- a single product backlog (because it’s for a product, not a team)
- one definition of done for all teams
- one potentially shippable product increment at the end of each Sprint
- one (overall) product owner
- many complete, cross-functional teams (with no specialist teams)
- one synchronised sprint cadence
When scaling up development, there is a tendency to add more process, more roles, more artefacts, and more control. These additions often cause overhead and rigidity. The “more with LeSS” principles assumes there is a way of scaling up without adding this additional overhead.
Most of this was bread and butter for a mature agile organisation like us but some of the principles challenged our current working.
How LeSS differs to our existing delivery model?
1. A larger definition of product with a single combined backlog. Currently we have product teams organised around large feature sets e.g. Make a Plea, Lasting Power of Attorney etc. LeSS argues that customers use the whole product and as such requires an expanded definition of product. This suggests we group all of existing product backlogs into one master backlog for each agency.
2. Multiple teams working on one backlog. Currently we have one team working on one product, in LeSS multiple teams work on the highest priority items in a single backlog. This takes advantage of queuing theory to enable faster delivery.
3. Long-formed teams. At the moment teams stay together until their product goes into live support, at that point teams are disbanded back into the resource pool. In the future teams will stay together for 2-4 years so they can ‘jell’ for higher performance.
4. Less management overhead. The team has more autonomy over their destiny – they choose the people in their team, organise their own workspace, choose their own ScrumMaster, monitor their own performance etc.
5. Multiskilling and learning. To reduce bottlenecks we will start cross training the teams. Ideally each person will learn at least one additional skill they are interested in e.g. a user researcher might also learn UX or a content designer might learn to code. So if we have an increased need in one skill area we will be better placed to smooth the spikes in demand.
6. Travellers spread best practice and increase technical excellence. We will introduce travellers who are domain experts who work with teams for 1-2 sprints before moving to a new team. This is to help share best practice and maintain high standards of quality.
What are we going to do?
As a result of these workshops we decided to run a small, iterative experiment with a few teams to see how a scaled agile framework might work.
We have chosen a small area of the business and expanded our definition of product – from many small products to something much larger.
Before we implement LeSS we are going to have a boot camp to kick off the first sprint where the teams will work through the process in detail and understand the new ways of working. In this boot camp we will allow the teams to self-form, so that they choose who they work with based on personality fit and alignment on styles of working.
No change is easy so we are going to support the teams with independent coaches who will work with the teams, product owner and stakeholders. In addition we are working out a way to give objective emotional support for anyone who needs help with the transition.
Getting ready
Before we roll this approach out to the rest of the organisation there are certain milestones we need to hit. You have to earn the right to scale. In our change model there are four stages:
- Ready
- Credible
- Sustainable
- Scaleable
The first step is getting ready. We put together a ready checklist of logistics, communications, support and training to make sure we hit the ground running. We then put this backlog in Trello, prioritised it and assigned items to owners. Finally we had regular catch ups to ensure we were on track to hit the go live date.
Becoming credible
To assess whether the scaled framework is successful we will have review meetings at the end of each sprint. This will involve looking at a range of metrics (which we will refine over time) to check if we are moving in the right direction:
Primary metrics:
- eNPS – are people generally happier (team, product owner, stakeholders, users)
- Value created/ savings enabled – is valuable work being done?
Secondary metrics:
- Potentially shippable increment – at the end of each sprint
- Stable velocity – 3-5 stories per sprint
- Backlog being in good shape – enough items for next sprint planning
- Stakeholder engagement – attendance at meetings (PBR, planning and retro demos)
- Cycle time – how quickly work items move through the system
We need to keep in mind that change is an investment and new ways of working often cause a temporary dip in performance while people get used to the change. This needs to be factored in when measuring progress.
What is the leader’s role in this?
As the Chief Information and Digital Officer, I committed my team to implement this new framework within just four weeks. No long deliberations and in-depth analysis. The leader is the catalyst for the change and an advocate for improved ways of working. The leader has to create space for teams to adopt to change and then ensure that successes are communicated to stakeholders to build momentum. The leader should also support the teams when they cannot resolve issues, make sure they have the correct resources and help unblock complex organisational impediments.
So what next?
We believe that adopting LeSS will reveal challenges in our organisation and ways of working. Our job is to fix the challenges that are revealed and not blame the framework. Keep in mind that the challenges were always present they weren’t as visible.
Over the next few weeks I will be writing a post at the end of each sprint outlining what we have learned, challenges we have faced and progress on performance. This will give you a sense, in almost real time, what a LeSS implementation in a large complex organisation looks like.
You can read more about Large Scale Scrum at less.works.
If you think this sounds cool then I want to hear from you. We are currently hiring permanent team members from developers, technical architects, designers, to user researchers. Our purpose is to transform the end to end justice system and build the next generation of digital services for citizens and civil servants. If you are interested, visit this page and send us your CV.
This post is part of a multi post series: