Agile Scaling: SAFe Best Practices for Scrum Masters

Are you working in software development in a large organisation? Then I will buy you an ice cream if you do not struggle with one or more of these problems:

• It’s hard to get products and features out of the door at the pace the business wants.
• Unpleasant surprises are more standard than the exception at the end of a development process. For a long time, it seems as if everything is on track until suddenly, it’s not the case anymore.
• There are seldom surpluses for strategic initiatives, as the majority of the capacity goes for the maintenance and completion of existing initiatives.

SAFe® is a framework that allows large organisations a means to reap the benefits of agile development, benefits which for a long time has only been an asset for smaller organisations.

Thus, organisations with up to thousands of developers can introduce agile development and gain benefits regarding productivity, quality and more satisfied employees and customers.
In the traditional agile methodology, agile methods embrace the principle of “small is beautiful”. You often hear warnings from agile practitioners, to avoid growing over a certain size as an organisation. Therefore, there is also limited tools and practices for handling scaling, when working agile.

My personal experience with agile software development in large projects

In 2000-2006, as development director of the SAS Institute, I was part of a Danish team that participated in a significant initiative involving many teams in the US and Denmark. In Denmark, we used eXtreme Programming and later Scrum. On the one hand, we experienced that it made us much faster and better to deliver quality. But at the same time, it was frustrating to see how little it meant for the overall program’s ability to deliver products.
Dependencies across teams, ambiguities about responsibilities and tasks, and a non-existent common approach to architecture were the great culprits.
However, we did one thing that made a significant improvement across teams. A relatively simple IT system where all teams could report priorities and deadlines across the program. This IT system made our dependencies visible, and we introduced a weekly meeting to follow up and coordinate plans on a 1-2 week horizon. This improvement was enough for us to deliver products that we earlier could hardly get out the door. At the same time, we could see that there was still massive potential for improvement.

A few years later, I randomly fell across an article about “Lean Construction” and “Last Planner” – in which authors Greg Howell and Lauri Koskela compared agile methods in software development with lean-inspired methods in construction. They found many similarities, and above all, they noticed that both are collecting their practices from the same paradigm: adaptive process management.

Læs artikel: Greg Howell og Lauri Koskela

I was excited. In the construction industry, one can mainly talk about dependencies; as a limitation, one has to accept. There is both the force of gravity – that you can not start building on the 5th floor, even if you have all the materials for it, but also there is an optimal sequence of work, so that you get the least problems if you make pipes before you mould the floor, finally to paint.

Was there a way to deal with these brutal dependencies, which we could adapt to software development. – With our much less square, yet nonetheless costly and highly manageable dependencies within the agile paradigm.

This thought led to a longstanding collaboration with Sven Bertelsen – Grand Old Man of construction – in Denmark called ‘Trimmet Byggeri’, where we together inspired software companies and electronics companies to use lean and agile thinking in their product development. We specifically focused on the Last Planner method, which, in short, has two general principles:

1. Let those who do the work plan it (hence the name). They know better than anyone else what is possible and what is needed for the plans to succeed.

2. Work with three horizons: The overall project plan, which primarily serves to identify problems and risks, making dependencies and optimisations visible. The rolling phase plan, which looks 3-6 weeks ahead. Do we have what it takes? Are there any issues with the deliveries? And finally the weekly schedule, which is a plan for what the sum of teams can reach in a week.

This experience was a big step for me, it explained why our simple management system worked. It also gave me new tools to plan and manage better without falling into the trap of centralised over-detailed plans that are never used but, and furthermore, often work against the purpose, making it harder to carry out projects.

At the same time, others began to talk about a radically different approach to dependencies: Solve them by collecting all the competencies that depend on a team – a so-called feature team. It is especially Craig Larmann and Bas Vodde who have put forward this idea as the primary way to scale agile development. A good idea, though with some limitations.

In some cases, feature teams are not a good idea or are very difficult to get to succeed. For example, you will not always achieve a good effect by putting mainframe, front-end and mobile developers on the same team. There can be so far between the competencies, that the advantage of being close to those, to whom you have dependencies, is less than the advantage of being close to someone with whom you can have meaningful academic sparring.
This aspect is even more apparent if you develop products that involve both software, hardware and mechanics. Here there are at least three professional groups with very different knowledge and working with different time horizons. If you put teams together with a crew like this, it will almost always fail. Here instead, you must have an approach that ensures communication and synchronised development between partially functional teams.

In 2013, SAFe entered the stage – at least for my part. I saw Dean Leffingwell, one of the key people behind SAFe, telling about the concept at the Agile 2013 Conference in Nashville. He presented the model and talked about the preliminary experiences. It was clear to me that this was one more step on the way to dealing with some of the problems that haunt large software projects.
SAFe is an expanded and well-described framework, which a.o. Include a strategy for the transformation itself; from a traditional way of working to agile and lean development. Also, it contains some structures, roles and rituals, all of which will help create teams in big programs to work together in a way that will produce far better results.

The core of the Scaled Agile Framework

In essence, SAFe takes care of dependencies and in the same way as the Last Planner method of Lean Construction, planning in the hands of those who have an interest and knowledge about what to plan. This planning gets done by identifying the team of teams working towards a common goal: An ‘Agile Release Train’ – and to define the activities that take place in this team. The core is to create an opportunity to plan together. Within 8-10 week intervals, there is a two-day scheduling activity, where everyone in the program works together to plan activities for the next ‘Program Increment (PI)’. These two days will end with goals for the coming period, a risk assessment and measurement of the plan’s credibility.

In everyday life, all involved teams work in synchronized sprints, but with some deviations: In addition to team and sprint demos, they make joined system demos that show finished features that are the sum of many teams’ collaborations.
There are also cross-cutting activities – Scrum-of-Scrums for both scrum masters and Product Owners, which are used for problem-solving and coordination between teams. Also, the same activities are included in each task, which does not originate for business purposes, but which aims to keep the architecture in a state that enables painless development of future features. In SAFe this is called an ‘Architectural Runway’.
At the end of a PI, a joint demo, and structured problem-solving retrospective is made, ensuring that challenges across the program are addressed globally and not only locally in the individual team.

Agile on three levels

SAFe differs from other methods, by very explicitly referring to the relationship between strategic goals and the practical performance of teams and teams of teams. Thus, SAFe introduces agility at three levels:

Team: At this level, self-organising teams work together in a Scrum / XP setup focusing on quality and collaboration.

Program Level: At this level, activities take place across teams for one or more ART’s. There are also people dedicated to coordination at this level as well as features that serve the entire ART and not just the individual team.

Portfolio: Also at this level, it is governed by an agile process, which primarily ensures that only a limited number of simultaneous things are used to avoid starting more stuff than it is possible to develop. By managing the portfolio in an agile process that is related to the way the rest of the organisation works, both flexibility and overview is achieved.

Picture: SAFe Big picture

Implementation of SAFe in the organisation

No major reorganisation is necessary to implement SAFe.
The core of a SAFe implementation is the identification of one or more, agile release teams (ARTs) and allows them to plan and execute program increments (PIs) together.

The functional silos that, in traditional software development, have the primary side effect of slowing down processes means far less when you let people work together across the silos.
Thus, in practice, work will be carried out in self-organising multifunctional teams where, at least, development, testing and product ownership are part of the team. Other features such as UX or DevOps will in some cases be part of the individual teams and in others it will be a function shared between several teams.
The individual teams can either be assembled by feature teams or component teams. SAFe does not recommend organising only with component teams, as feature teams are usually more effective, but in practice, you will most often have a mix. Central is visibility and minimisation of dependencies since there are always plenty of these. There are also some essential features designed to cross the individual teams, ensuring coordination and consistency. Partly, the role as the RTE (Release Train Engineer), which describes as the scrum master for the whole ART, and somewhat the role of System Architect. A system architect in SAFe has a practical orientation: To ensure the quality of ‘The Architectural Runway’, which briefly means that the system is always in a state so that you can implement the features that are a priority, without having to go through costly, unplanned redesign.

The role of the Leadership

In SAFe, the higher management has a well-defined role in the agile process, whereby the reality of the management office and the reality in the development or IT department will become a coherent whole. There is a well-defined path from strategic initiatives to specific features and products, and there are visibility of metrics and reporting that is relevant in an agile context, satisfying the needs for transparency and overview.
It is an essential task for management to ensure that decisions are taken at the right levels. In the vast majority of companies, far more decisions are made on a decentralised basis. Decisions that have potential impact, in addition to the individual team must be taken at a higher level than decisions with not so far-reaching consequences. Teams are given prerequisites and tools to make the necessary decisions. Thus, an implementation of SAFe will lead to increased clarity as to what can be decided, with more decisions left to the individual teams.
As part of the implementation, all involved in the program and transformation – including the higher management, are trained in SAFe’s essential elements. This training avoids the typical scenario of introducing agile development in a company, without the management having understood how the agile paradigm differs from the traditional way of working. This mixup can cause some unnecessary tensions and frustrations, and worst case it can be a contributing factor to the agile transformation failing.

SAFe is not a straitjacket, and there are many ways to implement the SAFe framework, but there are some things that always reoccur :

• Training of everybody who is part of the initiative from management to employees.
• Identification and launch of one or more Agile Release Trains.
• The first Program increment, including 2-day joint planning, system demos, Scrum of Scrums and a Program Increment, Completion with Joint Demo and Problem Solving.

Further readings: Agile Scaling: SAFe Best Practices for Scrum Masters