Agility at scale: the solutions
Introduction and background
In 2018, Scrum is still the most widely used methodological framework in Agile teams in the IT world (54% of IT projects (1)). The Scrum guide recommends having between 3 and 9 people per self-organised Scrum team. So what do you do if your Scrum team reaches saturation?
Do you need to move faster? You need to coordinate several teams on the same project? The client or your company gives you the budgets to increase the "velocity" of your Scrum team, it is then necessary to move to a scaled Agile framework.
As the graph below shows (2)The productivity of the team is not proportional to the number of team members. There is a threshold beyond which efficiency is lost to ensure good coordination in the team. It seems wise not to wait until you have 9 developers in your team before asking yourself the question of scaling up.
Productivity curve of a team according to its size (2)
What this graph demonstrates is the complexity of large teams to self-organise effectively (7). It is much more viable to separate large teams into two, even if it means keeping only one PO and one Scrum master for the two teams thus created. The separation should be at the functional level and not at the technological level, ideally in order to maintain coherence, independence and multidisciplinarity between the teams.
There are several models that have a good reputation for scaling up, I have chosen to present 3 of the most used models. Scrum of Scrum for its simplicity, Spotify for its ultra-Agile vision and SAFe for its reassuring approach and its application to large structures.
Scrum of scrum
Scrum of Scrum is one of the simplest models, allowing multiple Scrum teams to be run in parallel with regular synchronisation points called Scrum of Scrum.
This scaled agility framework was created by the founding members of the agile manifesto and Scrum guide Jeff Sutherland and Ken Schwaber and is deployed on 16% of(1) of agile projects.
Each team has one member who will participate in the Scrum of Scrum (a developer or the scrum master). The Scrum teams continue to perform their usual rituals without change.
The frequency of the Scrum of Scrum varies from a daily meeting to a weekly meeting. It depends on the maturity, the strength of the dependencies or the risks related to the mismatch between the Scrum teams.
In larger teams it will be possible to create additional levels (Scrum of Scrum of Scrum) to ensure synchronisation at different levels such as managerial, component or portfolio levels.
https://www.mountaingoatsoftware.com/
The Scrum of Scrum sessions should be seen as the Scrum Meeting, but they are not time-boxed to 15 minutes. It is primarily a way to synchronise teams, highlight sticking points and can be turned into a quick workshop to remove obstacles. This meeting is not a progress report or a schedule.
Concerning the duration of the sprints, it will be advisable to keep the duration proportional between the teams in order to be synchronised at the end of the largest sprints. This will allow a common review to be carried out by all the teams and will confirm the good functional and integration synchronisation between the teams.
Possible alignment of teams in sos (5)
This methodology is very advantageous because it is inexpensive. It can be implemented very naturally by choosing team ambassadors who will participate in the Scrum of Scrum. Moreover, this framework does not require additional hiring. It is the people in the teams who will play the role of ambassadors or Scrum of Scrum Master (SoSM).
Spotify
I have chosen to introduce you to Spotify because it has a different approach. The Spotify model is increasingly popular and is followed by 5% of (1) of IT product development projects in 2018. Here is a transcript of a video describing the approach made by Henrik Kniberg (3). The Spotify model is based on a corporate culture on which the Spotify company (music streaming) has developed. It is not a methodological framework with strict rules, ceremonies, .... etc. It is a feedback from the company that has managed to achieve such a high level of user and employee satisfaction that they have become a benchmark.
The Agile approach started around 2008 at Spotify with a classic Scrum approach. But the company grew and the teams multiplied to the point where the Scrum framework no longer suited them.
Their philosophy was "rules are a good start, now break them when necessary". They reoriented themselves towards the basics of agility rather than a strict rules-based Scrum framework.
Their Scrum teams have been renamed into "Squads". Each Squad consists of a maximum of 8 members and has a well-defined long-term role. The mission is the only thing imposed. For the rest, it is the team that decides what to build and how to build it.
Autonomy vs Alignment
Autonomy is one of Spotify's main focuses. They know that the more autonomous the teams are, the more motivated the people will be and the more value the teams will deliver. But they keep the means to synchronise with the company's goals, product strategy and priorities.
As far as practices are concerned, there is no imposed standard for each team. It is each team that decides how to organise itself, how to communicate, when to meet, to tell each other what ... etc. Some teams are in Scrum, others in Kanban, and each team adapts the model in its own way.
It is a pollination principle that is used. The company and the teams do everything possible to enable people to communicate effectively. All teams will regularly share their practices in workshops. If a team is using a new tool and has found significant benefits, they will introduce it to other teams and if some are interested, they can help them implement the tool in their team.
Pollination rather than standardisation
All the code is organised in small functional packages, each serving a specific need. Each system is originally developed by a team but there is no culture of ownership. Sharing is also one of the founding principles. A team can intervene if necessary on a system developed by another team. All that is needed is to ask the team that developed the functionality to validate the changes made.
The culture of sharing also involves people. There is a lot of mutual aid and a highly developed team spirit. We like to congratulate each other for a job well done and we communicate to thank our colleagues, which is very motivating.
Squads are grouped into Tribes. Each person also belongs to a Chapter. The squad is product-oriented, while the chapter is focused on a particular skill. In addition, guilds are created that straddle several tribes and allow for exchanges on cross-cutting issues.
Team organisation according to Spotify
The squads are divided into three groups:
- Features: the squads that will develop functionality for users
- Client app: the squads that will ensure that developments are compatible with all media, browsers, etc.
- Infrastructure: The squads that will support the other squads on technical matters: continuous deployment, AB testing, monitoring, etc.
This trio creates an environment of mutual support where each pole is at the service of the others.
I find that the Spotify vision takes Agile even further than the 2001 Agile manifesto and adds values that seem very relevant and proven.
SAFe
I started with a team expansion scenario in the introduction, but agility at scale will also apply to the transformation of teams already in place.
It is according to the size of the team you are going to support and the different parameters with which the teams have to deal that you can orient your choice.
For larger teams, SAFe is the most common solution on the market (30% of projects (1)).
SAFe is a much more detailed and standardised model than scrum of scrum or Spotify. This model will not be recommended for small projects as it is often criticised for being expensive to implement. It seems to be the most advanced of the agility frameworks at scale, with a more complete and wider scope. Some would say more imposing because it requires the knowledge and implementation of many concepts. This model defines and standardises roles, schedules and synchronisation processes. SAFe says that trained people are needed to implement it in a company. The eleven training courses planned for each role attest to the professionalization of this framework and its commercial stakes in the agility market at scale. New versions of the framework are released regularly (version 5.0 has just been released What's new in SAFe 5.0), which allows it to evolve and to benefit from the numerous feedbacks from which it benefits.
The essential SAFe model (6)
At the team level, SAFe combines the Scrum framework, XP best practices and fully integrates DevOps practices in a model that is levelled according to the size of your project and your teams.
More globally, it incorporates the Lean-Agile principles applied at several levels of the company. The more complex your product is, the more layers you will have to organise.
The base layer is the famous Agile Release Train (ART) which synchronises the different Scrum teams (between 50 and 125 people) at programme level. Above this, the model provides for the possibility of adding a large "Solution" layer for the coordination of several "trains" in charge of more complex solutions and requiring even more teams.
The "Portfolio" level connects the portfolio to the business strategy, defining the portfolio value streams that support programme execution and agile development. Finally, the "Full" SAFe level is the most complete because it combines these three layers. It usually includes several hundred people.
You can therefore implement SAFe in stages to start with, for example with the "Essential" level, then "Solution" or "Portfolio" or "Full"... if necessary. It all depends on who is involved and especially on the size of the team, which can range from 50 to 1000 people, the Full SAFe level being less common on the market.
The aim is to set up an organisation at each level of the company that allows self-organised teams to be managed in an Agile way and to synchronise all these teams efficiently by integrating management with Lean-Agile practices.
SAFe largely insists that it is THE framework for digital-oriented companies to become Lean-Agile. There is a whole philosophy around these concepts which are represented by many good practices or tools.
It is a much more structured model than other widespread approaches to agility at scale. This is the main criticism. It moves away from the self-organisation of teams and returns to a system with managers telling their teams how "it should be done". It has the advantage of reassuring managers during Agile transformations because it allows more control over the organisation of teams.
Conclusion
The choice of an agile model at scale is obviously not a closed question. Scrum of Scrum is appreciated for its ease of implementation. A Scrum team can move to SoS from one sprint to the next without much risk and with little investment in the subject. Spotify is a much more suitable model for mature teams who will be able to create their own Agile environments, but this will require the whole organisation to be on board and everyone to have the right mindset. SAFe is a behemoth that has proven itself in large organisations that want to move to Agile for large projects or services. There are other alternatives such as DAD, Nexus, Less, Scrum@Scale, Rage, APM, ...
All of these models have their own advantages and many companies create their own "in-house" models, such as Spotify. We see that the important thing is to orient your choice according to the company you are in.
Don't forget the Lean Startup motto: "Fail Fast!" Take the model that speaks to you the most but don't be dogmatic about it and critique its implementation to find a model that suits your business.
A company with a lot of experience on non-agile projects will find it hard to radically transform to a Spotify model overnight. If in doubt, don't hesitate to use coaches when scaling up or transforming to Agile, as this will certainly avoid some setbacks.
The field of IT development is subject to a lot of changes and the Agile market sometimes pays the price for its notoriety. The biggest pitfalls to avoid are :
- wanting to apply Agile in a dogmatic way, without listening to feedback from the teams,
- wanting to lead a transformation that does not involve people outside the project team
Author: Sébastien Leclerc (sebastien.leclerc@contentside.com) with the help of Ivan Boher (ivan.boher@contentside.com), Agile consultants at ContentSide.
References
Are you interested in this topic?