While there are many working methods adapted to teams (Scrum, Kanban, etc.), a particular level of organisation is required for scaling up. Among the solutions available to make several agile teams work together, SAFe (Scaled Agile Framework) is a popular but sometimes criticised framework. What are the advantages? What are the points of vigilance in the implementation of this methodology? Discover the essentials of SAFe via the advice of Michael Gicquel, SAFe® certified expert at Wemanity.
1. What does the SAFe framework consist of?
Like any framework, SAFe is not a silver bullet for practicing agility at scale. It must be adapted to the reality of each organisation and has both advantages and certain limitations.
A. A comprehensive scale agility framework
SAFe® was developed by Dean Leffingwell, author of the book “Agile Sofware Requirements”. In his book, the American entrepreneur lays the foundations of the model he names the “Big Picture”, in response to the need of large organisations to have a framework to align the various teams working in agile mode. The idea then evolved into the creation of the company Scaled Agile in 2011, which has since marketed training and certification programs. Highly popular, the SAFe framework is used by 35% of companies that transform themselves at scale according to the 14th State of Agile report published in November 2020.
The SAFe state of mind
To be used correctly, SAFe involves respecting five key values specific to the Lean and Agile mindset.
- Alignment: it is about synchronising people and activities on a goal and/or a plan.
- Integrated quality: one of the objectives of SAFe is to deliver maximum value, which implies integrating quality practices.
- Transparency: the framework asks to work in confidence, making sure that problems can be detected.
- Execution: as in Scrum, teams regularly provide deliverables.
- Leadership: the methodology relies on people endowed with real leadership and capable of creating favourable conditions for transformation.
In addition, SAFe is based on ten immutable principles. Broadly speaking, the framework assumes to have an economic and systemic vision, to work by iteration and to adopt an organisation allowing progress to be visualised, teams to be synchronised, and value to be delivered in a timely manner.
A layered model with steps
Beyond the details relating to the posture to adopt, the SAFe framework defines different practices depending on the context in which it is deployed. Currently, version 5.0 of SAFe distinguishes three different layers.
The Essential layer groups together the “Team” and “Programme” layers which were separated in the previous version. It is at this level that organisations start, it being specified that it is then a question of synchronising several teams by making them embark on a virtual “train”, a process known as “Agile Train Release” (ART).
The Large Solution layer is located at a higher level of deployment, insofar as it consists in aligning several trains (themselves made up of several teams). It is useful for working on complex solutions.
Finally, the Portfolio layer relates more to executive functions by covering strategic aspects, including the budget.
The SAFe framework goes even further in detail by offering a 12-step implementation roadmap. Through its degree of precision affecting all aspects (values, principles, layers, roadmap), the methodology therefore gives at first glance a real feeling of complexity, no matter what the operation! In fact, it is easier to understand than it looks.
B. Agility at the scale of a programme
Beyond the specific vocabulary employed, SAFe consists in deploying the way an agile team works at a higher level, by integrating additional elements to be able to synchronise the teams.
“In SAFe, we have several agile teams working on the same solution and who have dependencies to manage,” explains Michael. “In this context, we need a higher layer to manage these dependencies. This presupposes new roles, new artifacts and reasoning at the scale of a program, and no longer of a product as in Scrum.”
In general terms, in SAFe we therefore find the counterpart of what is practiced in Scrum. Given it must take into account the dependencies with the other teams, each team on board an Agile Train Release, therefore, works as it would do in a classic way in Scrum, with defined roles (Product Owner, Scrum Master, developers) and established points (sprint planning, daily meetings, etc.).
In contrast, in SAFe, new roles and events appear “above” the teams. Once again, however, the logic remains close to that of Scrum, with events that are modeled.
Some examples:
- SAFe begins with the PI Planning (Programme Increment Planning) ceremony, which is the equivalent of Scrum Planning.
- Each week, the PO sync brings together the product owners of the teams for a synchronisation point, as does the daily every day meeting within each team.
- ART sync aims to synchronise PO sync and the Scrum of Scrum
- In the same way that we have a sprint review and a retrospective in Scrum, we must in SAFe provide for a PI System Demo and a PI retrospective known as the Problem-Solving Workshop.
C. The advantages and disadvantages of SAFe
The SAFe model isn’t just gaining traction. As it is practised over three months and is particularly precise, it is sometimes perceived as too restrictive and complicated, even as anti-agile.
However, we must recognise the advantages of its disadvantages! Even though SAFe is difficult to access without training, its precision makes it reassuring to the organisations that use it. Well applied and adapted, the framework allows different teams to share a vision and move forward together on large-scale projects, avoiding the coordination problems usually encountered in the absence of a framework (duplicate work, misunderstandings, differences in timings etc.). As it is designed to deliver maximum value, the tool is also distinguished by its performance: it serves both the end customer who benefits from higher quality products and services and the company which succeeds in asserting its vision across the board.
Finally, it generates commitment among employees, who are required to present their work well beyond the extent to which they usually do. They also benefit from a certain freedom, since in SAFe, there is no provision for the development of functionalities during the last fifteen days of an increment, so as to let the teams innovate.
2. How can you implement SAFe in your organisation?
To get started, the ideal is to practice SAFe at the level of the Essential layer, that is to say by constituting a first “train” (Agile Release Train). However, the framework requires prerequisites and implies respecting certain best practices.
A. The prerequisites for practising SAFe
The SAFe framework is quite complicated to understand without an agile background. To implement it, it is therefore better to already have a culture of transformation and to focus on training.
Corporate culture
Because it concerns agility at scale, the SAFe methodology affects all levels of the organisation, from top management to operational teams. It also requires cross-functional thinking, breaking down silos. Unsurprisingly, every organisation wishing to implement it should ideally operate with values conducive to this transformation.
“We need a strong enough coalition for change,” says Michael. “It must be made up of people from different levels within the company, including managers. They must have an appetite for communicating with people, a natural ability to bring about change and real leadership. Training also plays an important role: it is necessary to train, at the same time, the leaders of the transformation, the people who will play a key role and the teams.”
SAFe training
The official SAFe website offers all the content you need to understand and implement the framework in your organisation for free. In practice, however, it is difficult to achieve agility at scale with this tool without training! There are around a dozen certification courses offered by Scaled Agile, covering the different roles and contexts.
While this is a significant investment since everyone must be trained (from leaders to operational staff), it should however be noted that the training courses can be followed by teams who have not mastered the basics of agility (even though this is still preferable).
B. The roles to be expected
To practice SAFe at the Essential layer, four key roles must be assigned.
Le RTE (Release Train Engineer)
The RTE takes care of the methodological framework. Its role consists in particular of facilitating communication between stakeholders and the smooth running of the various rituals (PI Planning, System Demo, etc.). It also provides support to teams and governance with a view to achieving alignment and continuous improvement. For this reason, we usually designate a person who knows how to manage large projects and facilitate, such as a Product Manager, a senior Scrum Master or an Agile Coach.
The Product Manager
This person is responsible for building the solution. As such, they must have an excellent understanding of the client’s needs to develop a vision for the solution and build their roadmap. For Michael, it is preferable to choose “a person with a great knowledge of the product, but also communication and negotiation skills, because this role requires knowing how to say no, how to prioritise.”
The System Architect
This person must define and communicate an architectural vision that will be shared by the teams making up an Agile Release Train.
The Business Owners
Business Owners play a key role in decision-making on priorities, on product content or solutions, as well as in communicating the business context to the SAFe train. There can be several of them per train and they can shed light on the business part and the added value.
C. The basic principle: composing an Agile Train Release
As you will understand, SAFe starts with the composition of a “container”, borrowing the image of the train, in which all the agile teams that need to work together will be gathered. Concretely, an Agile Train Release involves between 50 and 125 people, that is to say 3 to 10 teams. To define its composition, SAFe invites us to reason from the notion of value chain.
“You first have to identify the different steps to deliver value,” explains Michael . Then, we must identify the solutions supporting these different stages, then, behind these solutions, find the people who participate in their development. We start from the operational value chain to train our ART ”.
D. PI planning and other events
PI Planning is SAFe’s first flagship event. Organised over two days, it brings together all the people concerned face to face and is used to plan the start-up for the next three months. During PI Planning, among other things, we identify the dependencies between the teams, seeking above all to obtain an alignment between all the people who will make up the train.
While the SAFe framework is very detailed, it does not specify with what level of preparation to approach PI Planning. For Michael, the programme of this ritual is so dense that it is better to act in anticipation:
“Ideally, the teams should work a little on the creation of user stories upstream of PI planning. The best is to have user stories defined either completely or in part, so that during the PI planning, the only thing that remains is to cut them out as needed, to detail them and to plan them, then to manage the dependencies with the other teams.”
The SAFe framework is also based on other points, all organised for the purpose of synchronisation and alignment.
During the weekly PO sync, product owners and product managers discuss what is happening at the level of each team, to verify the absence of problems. The “Scrum of Scrum” ritual brings together the Scrum Masters and the RTE to manage blocking elements.
In conclusion, SAFe is both easy to understand and complex to implement. It is therefore important to prepare your teams as well as possible if you want to use this agility framework at scale, by investing in training. However, once the decision is taken, you will need to get started and stick to the deadlines set. Your first PI planning and your first SAFe experience will not be perfect, but this is one of the components of agility: to embark on the path of transformation, you have to experiment and then keep going in a logic of continuous improvement.
