If you’ve read our previous post comparing Agile Scaling Frameworks (and if you haven’t, we’d encourage you to!) then hopefully you have a good idea of which framework you wish to implement.
Today we’re focusing on how you can approach this implementation process. We’ll start, as we often do, with some background.
Agile at Scale implementation: Does one size fit all?
The approach you take to Agile at Scale implementation will depend on your chosen framework. There are some practices that most frameworks have in common, but each will have its own unique considerations and processes.
SAFe, for example, which is is one of the most popular frameworks, prescribes a detailed set of roles, organisational structures and processes. In line with this, it provides a closely defined path to implementation. Other frameworksleave the process a little more open or are offer a greater degree of flexibility.
In today’s post, we’ll cover how you can implement the following Agile Scaling frameworks:
Implementing Agile at Scale Frameworks: Best practice
While each of the seven Agile Scaling Frameworks we’re covering today will have its own terms, and processes, all will share some common traits.
For one thing, every Agile at Scale Framework is built on multiple Agile teams, typically comprising 7-15 people. The chosen framework provides ways for these different teams to work together towards common goals, resolving dependencies and co-ordinating timelines.
Another common truth is that any scaling framework requires changes to working practices and culture. To achieve such change, your senior management must commit to the programme. In the most successful implementation projects, we see a clear understanding among stakeholders about the need for a scaling framework and the benefits it will bring.
In fact, let’s pause for a moment to list a few benefits that Agile at Scale Frameworks can bring to organisations (if implemented effectively):
Faster time to market of key products or features
Transparency across teams, and the break down of silos
Cross-functional collaboration, leading to higher quality work
If you’re at the point of implementation then, of course, you should already be familiar with the above benefits of Agile at Scale Frameworks. But if your senior stakeholders are not, then it’s vital you educate and explain to them what they can expect.
Ideally, we’d hope that your senior management team are also knowledgeable about the main elements of your chosen framework and how it will work in practice. This buy-in is essential for implementation processes, as it then trickles down into your teams.
Are you considering implementing an Agile at Scale Framework? If so, a dedicated and experienced consultant can help to guide you through the process, train your team members and support with change management. Wherever you are in your Agile journey, why not talk to us today.
Now, presuming you have buy-in across your organisation, you then need to start the implementation itself. This is where approaches begin to differ.
Some scaling frameworks recommend starting small, and rolling out to a wider user base gradually. Others, such as SAFe, prefer a broader, more immediate rollout, to promote inter-team co-operation (and, it’s fair to say, to speed things along).
Let’s take a look at a few frameworks in greater detail.
Agile at Scale Frameworks: How do you implement each one?
SAFe
A Scaled Agile Framework (SAFe) implementation requires choosing the right SAFe configuration. Based on your organisation’s size, structure and goals, the configurations range from ‘Essential SAFe’, for smaller organisations, to ‘Full SAFe’ for the largest ones.
For a more in-depth breakdown of SAFe configurations, take a look at our short guide here.
SAFe recommends drawing up a detailed implementation plan including timelines, milestones and the roles and responsibilities of each team member. Scaled Agile Inc, the company behind SAFe, provides comprehensive materials to help you draw up this plan.
A SAFe implementation typically begins with a Program Increment (PI) planning event, which is then repeated quarterly. It should also start with a single Agile Release Train (ART), normally consisting of between 50-125 team members, before being rolled out more widely. It is possible that a different initial size may be chosen, but this depends on the Agile maturity of the organisation.
Disciplined Agile
In a similar vein to DAD, successful Disciplined Agile Delivery (DAD) implementations build on a strong base of existing Agile principles and practices. It may, therefore, be worth spending extra time working with your different teams to agree common Agile ways of working before implementing DAD.
Following this, the framework recommends developing a detailed implementation plan and, as with LeSS, starting small. There is a strong focus on training training team members in the principles of the framework and on specific practices and tools.
LeSS
In a similar vein to SAFe, Large Scale Scrum (LeSS) requires you to choose which edition of LeSS should be implemented: ‘Basic LeSS’ or ‘LeSS Huge’. This is based on the number of teams required: Basic is suitable for two – eight teams, (around 10 – 50 people), whilst LeSS Huge is designed for eight or more teams (so 50 – 6000+ people).
Once you have chosen your edition, feature teams are formed. These are cross-functional, self-organising teams, responsible for delivering a particular piece of functionality. Feature teams own all aspects of the development process, from gathering requirements to testing and deploying the final product.
As this framework emphasises the empowered, decentralised elements of Agile, LeSS implementations are reliant on a pre-existing and well established Agile culture. LeSS recommends starting with a small implementation, before expanding it across the organisation.
Nexus
Nexus implementations depend first on there being a strong understanding and mature practice of Scrum. To achieve this, you may need to establish precursor projects to introduce common Agile practices and embed Scrum among your Agile teams. (This is something that we could help with!)
Once enough Scrum maturity exists, appropriate individuals should be chosen to form the Nexus Integration Team (NIT) and the Product Owner. They will determine the participating Scrum teams and establish the single backlog shared by them all. (In essence, Nexus is based on a group of 3-9 Scrum teams with a single Product Owner and a single backlog.)
Nexus prioritises holding regular reviews, retrospectives and planning meetings between the Scrum teams, to promote team collaboration.
Spotify
The Spotify framework is more customisable than most. Practitioners are encouraged to take the elements that suit them best and use only them.
As with LeSS, Spotify encourages a high degree of autonomy and ownership among team members. This in turn requires significant Agile maturity in your organisation.
When you implement the Spotify framework, you will need to form cross-functional teams, such as Squads, Tribes and Chapters. Materials on Spotify implementation are available in a book and some online resources, and Spotify continues to evolve its own Agile practices and publish articles on them. It’s worth noting, however, that the framework is not actively maintained as a single methodology. A Spotify implementation will therefore rely heavily on the customisations and improvisations of your implementing team.
Scrum@Scale
Scrum@Scale is a hierarchy of Scrums of Scrums. As with many of these Agile Scaled Frameworks, implementation depends on a high level of existing maturity with Agile principles; in this instance, Scrum.
For a deeper dive into Scrum@Scale, this recent post may be of interest.
As an early step in a typical implementation, we’d recommend that you identify the right people to lead the scaling effort, including a Scrum@Scale coach, a Product Owner and a team of Scrum Masters. A clear governance model between these roles should then be established to conduct Agile ceremonies, manage dependencies between teams, and define the product backlog and implementation backlog.
Guidelines for rolling Scrum@Scale out to the teams are provided by Scrum Inc, the organisation behind Scrum@Scale. Scrum@Scale places emphasis on collaboration between teams and providing the forums in which this can take place.
Enterprise Kanban
Enterprise Kanban is not owned or managed by a single organisation, and there is no single approved way to implement it. We’d suggest that you do, however, follow guidance set out in the Enterprise Services Planning framework, a set of guidelines originally developed by multiple authors and now adapted, expanded and maintained by a community.
A key early step in implementation is to define the governance framework and the roles and responsibilities of the stakeholders. Since Enterprise Kanban is usually based on teams practising Kanban, rather than Scrum, the workflows need to be more closely defined than with other scaling frameworks. We’d suggest you map out the value streams and identify key process steps, including work items and their statuses and metrics.
As with several other frameworks, Enterprise Kanban emphasises continuous improvement and training.
An Agile implementation is never truly finished…
Implementing Agile at Scale and striving for enterprise agility is a major undertaking, but there are rich benefits in doing so. From our perspective, the key foundations for a successful Agile at Scale Framework implementation (and we believe that these are common across all frameworks) are:
Senior management engagement and support
Teams to agree on a core set of common ways of working
Continuous improvement
Because of course, with regards to this last point, your implementation is never truly finished. Agile is, at its very core, built on a foundation of continuous improvement. Any implementation team worth its salt should acknowledge that not everything will be right first time.
Only through embracing a Kaizen mindset and continually taking time for introspection and iteration can you ever hope to achieve enterprise agility.
What’s next?
There’s a lot to take in on this topic, and we’ve really only skimmed the surface of Agile at Scale implementations today. The good news is that our team of dedicated Agile experts are ready to help you begin your next steps, whether that’s reviewing your existing Agile processes, or considering implementing a new framework. Do reach out to us today, and learn how we can help you.
And if you’re wondering how on earth you’re going to keep track of all that agility in your organisation, you’ll be glad to know that this is going to be the topic of our next post in this series! We’ll be focusing on the tools you can use to support your scaled Agile and how they can help maximise your productivity – so watch this space.
