It’s not secret Agility has a lot to offer organizations: project management are three times more successful, better quality delivery and higher customer satisfaction. Regarding those undeniable assets, the goal is to spread those good practices throughout the whole company, or at least between agile teams working on the same product: that’s what we call Scaling Agile. But to make it work, you gotta go deep: the transformation needs to impact the entire organization. And mostly, follow the right method. To get inspired, here’s the Top 5 methods used to Scale Agile.
SAFe® – Scaled Agile Framework
SAFe® is an agile methodological framework defined by Dean Leffingwell (management consultant and software developer) in 2011. It is based on Lean and Agile methods’ pillars, and has become one of the most popular agile approaches, together with Scrum. If Scrum is more suitable for a single team project management, SAFe® is designed for companies needing to implement agility at Enterprise scale. It’s more of a company-wide strategy, a turnkey solution that implies all stakeholders, aimed at development projects that include 50 to 150 people.
This framework helps to better share business strategy across the organization; and subsequently, to align teams, setting common goals and even a SAFe tool for enterprise agile planning.
To make sure practices are well harmonized together, the Scaled Agile Framework provides a common language to better define and harmonize any roles, processes and practices, divided in a three-level structure: the Portfolio, the Program and the Essential level, all organized around one ART – Agile Release Train.
We suggest that you check out the following detailed article, if you wish to learn more about agility at scale with SAFe.
But even though SAFe is undeniably effective, it’s not the only method to scale agile: there are other frameworks, maybe more adapted to your company, your teams, that will better help you successfully deploy agility across your organization.
Scrum of Scrum (SoS)
Jeff Sutherland, one of the Scrum method’s father, has conceptualized the oldest agile at scale theory: Scrum of Scrum (SoS). It basically consists of implementing Scrum at scale with the Scrum method itself, aiming to align up to 9 agile teams thanks to the Daily Release.
Synchronizing teams with the Daily Release
The Daily Release ceremony, compared to the traditional Stand-Up, takes place every 2 days and gathers every organization’s ambassadors, one per team. The Scrum Master’s presence is generally required to monitor teams, and make sure that they stick to the Daily mindset.
Just like a Daily Scrum, a Daily Release is a way to coordinate teams, to follow and report their project progress as well as potential bottlenecks and/or dependencies, interferences. This ceremony should give an answer to those questions:
- What does my team have accomplished since the last ceremony?
- What issues have had an impact on the progress of the project?
- Are there any negative interferences among teams?
- What does my team wish to have accomplished for the next ceremony?
Also, a « Product Owner Committee » meeting should be happening each week, bringing together all the POs, in order to manage teams and orchestrate their tasks under a common vision.
To learn more about how SoS is effectively deployed in big organizations, we suggest you read how VITAM uses Tuleap as a Scrum of Scrum management tool for its government program.
The Spotify model
Spotify is a music streaming service founded in Sweden in 2006. The company has been growing exponentially and has now more than 4000 employees and 191 million worldwide users. Their secret? A true flexible and agile organization capable of adapting to business structural changes.
The company initially used the Scrum method to align small teams, but as the amount of both users and developers exploded, they had no choice but to change, to better adapt to multi-sites teams spread across the world.
As a consequence, Spotify customized its own tool, adapting the business model to the company’s organization… not the opposite!
Spotify is a great example of how important it is to choose a method that can both adapt your processes and also give you more flexibility. This is why it would be more appropriate to develop your own business model, allowing you to best meet your organization’s needs, rather than to merely implement and stick to a pre-designed model.
Spotify model’s key elements
Teams are organized according to “functionalities” or “perimeter”, made up of 5 to 10 people, led by the Product Owner.
These squads are multidisciplinary and fully autonomous: they’re free to choose their own approach, such as Scrum, Kanban and so on.
Squads are organized in Tribes, according to functional/technical challenges they’re addressing.
To be fully working, they should be limited to 80 people max.
They help gather people in different groups depending on their skills or professional profile. These Chapters are managed by a coach, responsible for their HR development.
Guilds are voluntary groups or communities of people based on a particular area of interest. This way, their members have the possibility to choose a specific skill they want to develop.
Disciplined Agile Delivery (DAD)
The DAD framework was developed in IBM, by Scott Amber, between 2006 and 2012. It is a hybrid approach, made up of different agile methods: Scrum, Kanban, EXtreme Programming (XP), agile modeling… in order to meet companies’ needs for their delivery process.
Actually, the Disciplined Agile Delivery was designed to complete agile methods – particularly Scrum – which generally focus more on development rather than on delivery.
According to this framework, roles are divided into two different categories: the primary roles, which are necessary and mandatory in a project, and the secondary roles, that are cross-functional roles involved from time to time, when necessary.
Here follows the 5 primary roles:
A person who’s directly impacted by the result of the solution. It can be an end user, a manager, the help desk… The DAD team works together with stakeholders throughout the project.
The people that are responsible for developing the solution. They identify, execute and follow any tasks related to the project.
They monitor and lead the team throughout the project. They also play the role of an agile coach and can be compared to a Scrum Master.
They represent the customer’s needs, ensuring that delivery details are fulfilled. The Product Owner’s role and responsibilities also include being the team’s representative when dealing with stakeholders, and they work closely together with the team itself.
They are in charge of the architecture, the design as well as the enhancement of the solution. In small teams, the Team Leader is also the Architecture Owner.
The Disciplined Agile Delivery is characterized by the following three stages:
- Inception: the project is launched thanks to the previous organization concerning not only the team and its workplace, but also the definition of a common vision and a technical strategy – both of them aligned to the overall enterprise strategy.
- Construction: the DAD team incrementally develops the solution through various agile tools.
- Transition (or delivery): the solution is ready to be delivered, but its deployment strategy has to be planned.
Large Scale Scrum (LeSS)
Scrum, and more…
The LeSS framework was first presented in 2013 by Bas Vodde and Craig Larman. Based on Scrum agile method, the main difference is that it can be effectively applied to multiple teams. Also, in this agile approach, there is only one single Product Owner for all the teams involved. He’s in charge of making sure they’re all united and aligned altogether. In order to be fully effective, LeSS is generally limited to 9 Scrum teams, which represents approximately 70 people.
Ceremonies to align teams
- During the Sprint Planning 1, each LeSS team is represented by 1 or 2 ambassadors and the Product Owner shows their backlog. User Stories are then distributed between the different teams.
- Teams that have to collaborate on some functionalities of one of the user story work together during the Sprint Planning 2.
- The Daily Sprint is the traditional Daily, allowing team members to check up on project progress and bottlenecks. LeSS approach enables teams that work together (and who have already met during the Sprint Planning 2) to send an observer to other teams’ daily.
- The Product Owner shows customers all the accomplishments during the Sprint Review, a meeting to which teams and managers are invited to participate and which goal is to point out potential improvements.
- Just like in Scrum, the Sprint Retrospective is useful to focus on various aspects of the latest sprint: interactions, motivation, well-being… all this, to improve team productivity and efficiency. In LeSS, the Product Owner doesn’t attend this ceremony.
- The Sprint Overall Retrospective brings together the Product Owner, Scrum Masters and the managers to evaluate the sprint; this time around, neither the teams nor the developers attend the ceremony.
- The Overall Product Backlog Refinement brings together the Product Owner and 2 representatives per team, with the purpose of clarifying and refining the Users Stories before the next Sprint, so that teams are brought up to speed.
What is the most suitable framework for your enterprise to scale agile?
All these agile at scale methods provide a framework to implement Enterprise Agile Planning (EAP) tools. Now that you have gained a clearer insight into the top 5 approaches to help you deploy agility at enterprise scale, it’s up to you to choose the one that will adapt to your business’s process and context specificities. It is important to underline that if a method – SAFe for instance – works perfectly for a given company, it doesn’t necessarily mean that it will be the most suitable solution for another company.
In conclusion, if you are willing to go for a large-scale agile transformation and to succeed in it on the long run, we suggest you opt for and implement the method that best adapts to your activity, teams and workflows… or why not create your own approach like Spotify did?!