Agility at scale is the application of agile working methods at enterprise level. Thus, implementing agility at scale is a company-wide project, not just an IT project. It is therefore a transformation that should involve all employees… At first glance, this already seems compromised for many organisations…
Why move to agility at scale?
In reality, for most organisations, moving to agility at scale in the strict sense is wishful thinking. And this is even more true when the size of the organisation increases. Moreover, no methodology allows or proposes to align all employees. But let’s be pragmatic.
Agility at scale is possible, and especially useful for projects of a certain size that are in fact in line with the company’s strategy and budget. And then there are different methods, more or less framing, to be chosen according to one’s needs and organisational constraints. Even SAFe, the best known method, offers different levels of implementation and will be able to provide a framework for a company that wants to operate in agility globally.
The implementation of an agile method at scale will be useful as soon as it is necessary to synchronise several specialised teams working towards the same goal of transformation at the scale of the company. For example, when the company is redesigning its website, intranet and online shop: these are three distinct sites with their own infrastructure and require different skills: web design, internal collaborative solutions, ecommerce, etc. In this case, there are several teams that will have to align themselves regularly: CMS integrators, Front-end developers, infrastructure engineers, ecommerce integrators, etc.
Which agile methods at scale?
While Scrum is the most popular method for setting up agile teams, when it comes to scaling up, the choice is much wider and it is a question of choosing the method that best suits the context. While SAFe has been very successful, this method is demanding and strict in its implementation. If well implemented, it is highly effective, but requires great rigour. There are others that can be more flexible, each with its advantages and limitations. It is then necessary to find the one most adapted to their context, knowing that developing their own method remains possible, some solutions will be configurable enough to allow it, but this requires a greater maturity of agility and especially an excellent knowledge of their internal collaborative processes. Here are some methods that allow you to synchronise several teams for large projects.
Large Scale Scrum (LeSS)
LeSS proposes to apply a large-scale Scrum method, as simply as possible, to avoid setting up strict frameworks. The idea of LeSS is to have several Scrum teams working together on the same product. This is one of the limits of the method: for a business transformation or an even larger project, the LeSS method is designed for multiple Scrum teams (8 maximum) with always a single Product Owner (since there is only one product). For several interconnected products, LeSS may not be the right method, even its derivative LeSS Huge which supports more teams, but still for the same PO…
LeSS may be the easiest method to implement for scaled work, but it will quickly suffer from shortcomings in adapting to the individual context. LeSS is therefore a basic framework that needs to be customised. LeSS is therefore a basic framework that needs to be customised. This can lead to something very effective, adapted to the particularities of the organisation, but also to what would be much less effective if the adjustments to the framework proved to be counter-productive. Opting for LeSS therefore implies a real maturity in Scrum and agility in general, at the risk of making the method deviate from its basic strengths. This is the paradox of LeSS: a method that is tempting to scale up because it is not very constraining and is relatively easy to grasp, yet it needs to be enriched while maintaining its mastery.
- Number of teams: 2 – 8
- Number of people: 15 – 50
Scaled Agile Framework (SAFe)
SAFe is a full-scale agility methodology that is very comprehensive and supportive. It even proposes a schedule for the implementation of the method. In fact, it often implies a transformation of the company’s processes and its implementation is not to be taken lightly. When well integrated, it will be highly effective. SAFe offers several layers, and not all of them are deployable :
- Essential: Aligning multiple agile teams working around a complex product.
- Large Solution (Incl. Essential): Align multiple teams for one or more products that require different core businesses.
- Porfolio (Incl. Essential): Aligning teams with strategy, budget.
- Full (Incl. Essential + Portfolio): The Large Solution method with the Portfolio layer. SAFe full is suited to business transformation.
SAFe is a popular method because it offers a sharp and reliable framework, and modularity according to the size of the project and the number of teams to align. Its implementation is a project in itself, but it does not require teams to have expertise in Scrum. SAFe is quite restrictive, particularly because it does not neglect the ceremonies: the “PI planning” requires regular face-to-face meetings of all the teams for a complete alignment ( dependencies update, progress, remaining work, etc.).
- Number of teams: 10 – 25
- Number of people: 50 – 150
Scrum of Scrums (SoS)
The Scrum of Scrums approach is very simple. It consists in building a Scrum approach on top of Teams currently operating in Scrum: the Teams are therefore aligned thanks to the SoS Team(s) made up of delegates from the Scrum Teams. The objective of these scaled teams is to align the Scrum teams in order to synchronise the deliveries at each Sprint.
The implementation is quite easy, but to be optimal and even functional, it requires Scrum teams to be rather small and of the most homogeneous size possible. In general, homogeneity is the key: the maturity of each team on the Scrum method must be fairly advanced, and the complexity of the tasks or the skills of each team on their tasks must be as homogeneous as possible. For too disparate maturities, velocities, and sizes, SoS will make it difficult for virtual Scrum teams to work at scale.
- Number of teams: 2 – 9
- Number of people: 10 – 40
Spotify
The methodology bears the same name as the company that invented it. Spotify has therefore built a customised method that can keep up with its rapid expansion and culture of collaborative work. While it is indeed agile, it is very much tailored to its inventor and is perhaps more of an example or an excellent source of inspiration to build your own agile method that fits your company’s culture. However, Spotify is one of the methods recommended by many project management tools at scale, as it is a rather unique method that is interesting to consider in its agile transformation process.
The Spotify method requires a strong culture of trust and autonomy in decision-making and skill development. With Spotify, teams are free to work as they wish, even with the tools they want, but they must be transparent to the rest of the organisation. The method then allows for experimentation, and therefore failure, but to nurture innovation.
Basically, Spotify organizes people into cross-groups, and each type of group has its own role :
Squad : similar to the Scrum team concept, squads are autonomous teams that focus on a single mission, a clear objective. A Squad has its own agile working method, an agile coach and a product owner. Each member of a Squad has their own job, role and specialities. Please note that when moving from Scrum to Spotify, the Scrum teams do not automatically become the Squads!
Tribe : a tribe is a set of squads working on the same topic or macro-feature and which must coordinate closely. Each tribe has a leader who ensures that the squads are aligned and that the collaborative work is generally managed.
Chapter : a chapter is made up of the counterparts of each squad in a tribe, or people with the same skills. No more than one person per squad, and not every member of a squad is necessarily part of a chapter. Each chapter has its referent and it is used to share and develop good practice, to move squads forward.
Guild : Guilds are useful for bringing together people with a common interest or skill. The construction of a guild is free through all the tribes and the exchanges are rather informal. The idea is to exchange around a subject or skill and to make the group progress.
Squad and Tribes are the main structure, chapters and guilds nurture innovation, cross-functional dialogue and transparency. Nested together, these elements theoretically allow for effective large-scale agility up to a significant number of people.
- Number of teams: 4 +
- Number of staff: 50 +
Achieving efficiency over Scrum before scaling up
Moving to an enterprise-wide agile method can be a big change in itself and it first requires a certain maturity in terms of agility at the team level and in particular Scrum which is the basis of many agile methods at scale.
Achieving maturity within Scrum means mastering the methodology in order to deliver value more effectively than with the traditional method. This means mastering the tool itself and adopting the best practices related to it. Agility at scale solutions can be fed with project data (notably tasks at team level) by connecting to an existing tool (Azure DevOps, Jira, etc.), and sometimes do not even offer task management to avoid redundancy. The basic tool for managing tasks and sprints must therefore be fully compatible in terms of its use with the solution that will be installed on top of one or more instances of various tools, sometimes even different ones.
Jira Align for example requires one or more Jira instances to run. In a similar way, Planview Enterprise One recommends the use of Projectplace for low-level agility. At Atlassian, the Jira / Jira Align pairing being mandatory, the editor provides an audit tool (Jet by Jira Align) to check whether the Jira instances to be synchronised are ready to be scaled up with Jira Align. It is indeed a question of preparing before taking the plunge!
For further analysis of Scrum performance, solutions such as Wiveez offer to add indicators, metrics and dashboards to Jira that allow you to monitor its effectiveness in agility, to estimate its maturity for scaling up, and then to monitor its successful implementation. This is to ensure that the investment made in a change of global approach bears fruit. Project management solutions at scale can bring significant added value if they are well implemented, based on project data from agile best practice, and well-used. Yet these are difficult to measure. This is where Wiveez comes in: an agility management tool. The product is currently only compatible with Jira.
