What is SAFe®, and when would you use it instead of Lean-Agile software development?

What is SAFe?

SAFe stands for Scaled Agile Framework®. It’s still Agile, usually of a Scrum variety. The difference is that it’s scaled up so that multiple development teams can work together on features for the same product or within the same portfolio. SAFe has a fixed structure, methodologies, and guidance to support numerous Scrum teams working together. Roadmapping happens for the features for the multiple teams and then uses an Agile Release Train (ART) structure to plan the work against the roadmap. The ART has regular milestones and development periods (such as iterations) planned and synchronised together. There are different levels of SAFe; specific methodologies for portfolio-level, platform-level, and team-level.

Whilst SAFe isn’t the way we usually work at Bluefruit, when clients have requested that we work in SAFe in the past, we’ve been happy to collaborate with them in this way. Plus, at Bluefruit, we love working in Lean-Agile for all the improved quality and value delivery we get from it. So, if you need to work on a much larger scale, SAFe can tick a lot of those boxes too.

If that sounds good, how exactly does it work?

Plan in Increments

Multiple iterations (sprints) form each milestone, called a Planning Increment (PI), which might last around 12 weeks. The different development teams all contribute to delivery goals and priorities for each Planning Increment.

(Pictured below: The Agile Release Train (ART) comprises development teams A, B, and C, which are working in iterations that are in sync with each other. At the end of each iteration, there is an iteration demo, and there is continuation between all teams and the overall ART. Every five iterations, there is a Planning Increment milestone. The final sprint of each Planning Increment is different to the others.)

Work is shared between the teams using Continuous Integration, enabling regular incremental releases to deliver value sooner. Close collaboration enables teams to share knowledge. A solution that Team B finds can benefit the other teams, resulting in improved quality and time saved overall.

Each PI begins with a full-team planning session to help everyone understand the context and plan the high-level features collaboratively.

At the end of each PI, there is an Innovation and Planning iteration to support continuous learning. This provides time for planning, reflection, training, tool improvements, and buffer time for completing delayed work. In theory, this reduces the risk of missing the PI deadline or having work that rolls over into the following PI.

Cross-functional teams and support roles

Various roles work across teams to help the Agile Release Train run smoothly and ensure the project is successful:

• Release Train Engineer (RTE)—a servant leader who facilitates the key decisions and communication between the key parties involved, escalates risks and drives improvements across the development teams. They also work with Scrum Masters on each team to help each team deliver value.
• Product Manager—coordinates Product Owners on each team to ensure all align on the priorities and requirements. This cross-team collaboration is vital to stop teams from becoming siloed.
• System Architect—manages the technical architecture across the project, the non-functional requirements and ensures continuous integration happens.
• UX Designer—manages the overall user experience of the software developed across the teams.
• Development teams—made up of cross-functional engineers, each team is self-sufficient and capable of implementing and delivering their assigned features.

So why would an organisation or business consider using it?

You might wonder: why not just use multiple development teams working separately? Surely having multiple teams producing content at their regular rate and using familiar processes would automatically mean improved productivity?

Multiple teams working in parallel could increase productivity and enable a faster time to market. But poorly coordinated teams, siloed from each other, risks delivering less value to the client. This is especially true if the teams are part of different organisations.

How one team does Agile or Lean-Agile can be different. If teams are more familiar with less iterative forms of development (such as Waterfall based methods), things can get tricky.

SAFe provides a framework to get everyone on the same page quickly when scaling fast is crucial to success.

What are the risks if you don’t align teams well?

SAFe executed well is meant to help teams align. You might have already experienced some of the principal risks of siloed teams running without something like SAFe in place.

(Pictured below: Three trains. One train has arrived at the station, but two trains are delayed.)

Keeping multiple teams aligned towards the same goal

We must repeat—aligning teams towards the same goal means focusing on delivering the most value to the customers. Alignment happens in the form of a PI Roadmap that plans out the contents of the “committed” next PI and the “forecast” contents of subsequent increments.

Work tasks on a Solution Roadmap are identified as either “enablers”, a dependency of another task, or “epics” with specific business value. Enabler tasks, which are more exploratory, such as performing research or making a prototype that can reduce risk, are called “spikes”. Additionally, knowing how the work is divided between the teams and regular collaboration means no siloed teams. It’s clearer how the outputs of each team will work together to create the best outcome for the customer.

Delivering less value

Each team could have a different understanding of the priorities and goals of the project. The teams are each working on what they think is the most important, but this might not be the most valuable offering to the customers or the project overall.

The delivery dates might not be consistent, and the teams might not have balanced workloads between them. One team could finish significantly later than the others, holding up the final release. This is a bit like trains due to arrive at the station—you might not realise there is a severe delay until the first one reaches the destination ahead of the others.

Cross-team dependencies neglected

Another major issue that could arise is that it gets more complicated when there are dependencies between pieces of work. It slows everyone down when some teams cannot start their tasks until another team completes their activities first.

Teams might not produce a releasable deliverable if they can’t integrate their work. These things risk delaying a working product to the customers or missing a release date. SAFe calls these tasks “enablers” because their completion enables another piece of work to begin. Sometimes it is necessary to prioritise enabler tasks.

Not sharing knowledge

Without collaboration, problems solved by one team might also be struggles for another team. Similarly, one team’s successful practices and knowledge might not be shared across all teams, resulting in a significant difference in quality or efficiency across the different teams.

What are the benefits of SAFe?

Practised well, SAFe can help with the above alignment issues.

Help comes in the form of collaborative “ceremonies”. These ceremonies include an all-hands kick-off meeting and Planning Increment planning sessions, with all-level stakeholders and team members in attendance. Using these ceremonies, you can align everyone involved with the product vision. They also bring regular communication between the different teams.

The collaboration at the PI planning event is a major benefit. The event can include a live system demo performed by the different teams who show off their work, followed by Q&As, and risk identification and analysis. Because everyone is available for the entire event (which could be a few days), you can catch up with relevant people to get more information at any point.

So SAFe enables you to maximise the business value to deliver within the next Planning Increment.

There are good reasons to use SAFe if you need to develop at scale. We describe some of them below:

Know you are part of the big picture

Have you ever wondered if what you have been tasked to work on is something your customers will even use? Or have you stopped to think about the customers who will use it? Adding a button is just adding a button unless you know that this new button will enable your customer Sandra to access the medicine she needs. Then it suddenly seems more valuable and essential.

People at work are thirsting for context, yearning to know that what they do contributes to a larger whole. —Daniel Pink

Each team member attends the cross-team planning sessions and participates in defining or learning about the product vision and customers. They have visibility of the steps required to get to that goal and see how what they are working on contributes to the big picture. Doing this can help give them a sense of ownership and know that they have value. Understanding the context makes the work more meaningful.

Iterative development with something releasable at regular stages

When you conduct journey mapping and value mapping, you can plan the upcoming iterations and focus on the most valuable work. The Agile nature means that there should be something potentially deliverable at the end of each sprint. Sprint reviews (demo sessions) can give the stakeholders early visibility of the new features to encourage a strong feedback loop. Goals can be adapted to changing market or user needs in an Agile way.

Knowledge and best practice shared across multiple teams

Sharing knowledge and learnings across teams improves the operation of all. Suppose one team has discovered an easy workaround to a hardware fault or a way to do something very efficiently. In that case, they can share this information with the other teams. A culture of continuous learning and improvement is encouraged as part of the SAFe mindset.

What are the downsides of SAFe, and can we avoid them?

Things can still go wrong when adopting SAFe, and these are some things you can look out for if you choose to try it.

Being Agile and avoiding mini waterfalls

When you’re planning in 12-week blocks, there is a risk that each Planning Increment could become “mini waterfalls” that are resistant to changing priorities or scope between iterations. To try and avoid this, you need to keep the focus on the things that are most valuable to the business and the customers. If necessary, you might need slightly shorter PI lengths to mitigate this.

Similarly, it is harder to “be Agile” if multiple teams are involved. For instance, even minor changes (from user feedback) can affect various teams and completed work. There might be resistance to making a change that could disrupt progress or cause significant rework.

To help handle this, keep stakeholders involved throughout. Invite them to demos at Reviews and listen to their feedback from using the early products. It’s also essential to ensure that everyone is notified of relevant changes to priorities or requirements so that everyone remains aligned towards the same goals.

Everyone involved at all levels needs training and to adopt an Agile mindset. There is SAFe-specific training available that can help up-skill the team.

Planning challenges

Large planning events are trickier if not meeting in person (and we know the pandemic hasn’t made this easier). The in-person planning events we attended were great. However, if everyone is remote, you miss some spontaneous-conversation benefits that would happen in person. Small groups tend to break away into separate video calls to chat about specific issues, so not everyone can overhear the discussion or the outcome. It’s possible, but you must work harder to create those social and discussion opportunities.

Even with a sprint as a buffer, you can still risk over-estimating capacity. Most people have optimism bias and will make smaller estimates. To try and compensate for this, encourage realistic estimates so that work doesn’t carry over from one PI to the next. Also, monitor the team velocities, or allow extra buffer time for completing tasks.

Dependency management

Dependencies can be tricky to track between teams—another team’s work might block some work. Find a decent work tracking tool that highlights these enabler tasks and make the time to review and assess the tasks that might block progress with the relevant teams at the PI planning event. Effective communication makes a big difference here.

What have we liked most?

There are lots of things that we liked when working in a SAFe way, but the main ones were:

Stakeholder involvement

Stakeholders can often be remarkably busy people, but projects tend to go better when getting regular information, answers, and feedback from stakeholders. At PI planning sessions, having presentations given by key stakeholders about the vision for the solution and how it fits with the company strategy and user needs can be very inspiring and motivating. It is also helpful to get regular stakeholder feedback at iteration review demos. It is reassuring to know that you know you’re building the right thing or plan changes if required.

Seeing our value

You feel empowered when you know you’re part of something big and know that what you’re doing will make a difference. It can come from hearing stakeholders talk about the customers’ problems and how a product will solve them, focusing on the ideal solution and aligning multiple teams towards a shared goal.

Meaningful milestones to work towards focuses teams on the things most important to the customer and the benefit the customer will get from your work. This is something that many Agile organisations still find challenging, but we can also use this in Lean-Agile using Journey Mapping and User Story Mapping workshops.

Collaboration benefits

It can make an enormous difference to get key stakeholders and subject matter experts together in the same room for planning sessions. People who know those areas best can identify and discuss potential issues and risks quickly and easily, which gives the project less room for failure.

PI planning sessions also help identify the pitfalls, skill gaps, and other known unknowns in an environment where concerns can be addressed. Once identified, you can mitigate them.

There are many benefits to collaborating with other teams working towards the same goal. All teams do things slightly differently and can have different specialisms and experience. Working closely with other teams shares knowledge and, as a bonus, it can make the work more interesting.

Finally, we like the emphasis on everyone having an Agile mindset. Every single person in the team attends formal SAFe training. Roles and responsibilities are explained, so people know what they need to do and whom to talk to about specific aspects of the project. Having everyone share foundation knowledge on Agile means more consistency, self-organisation, and less room for misunderstandings.

How does it compare to Lean-Agile software development?

You’re probably wondering how SAFe with Scrum compares with the Lean-Agile software development we usually do.

Here are some of the things they have in common:

• Continuous integration, be able to release small and valuable deliverables regularly.
• Continuous learning, keeping those processes Lean, and sharing knowledge between the teams to encourage innovation.
• Value focus, work on the most important things first.
• Aim for delivery early and often to reduce the risks and get early feedback.
• Respecting people and investing in people, such as making time for training.

SAFe can bring cohesion when you risk having none

SAFe is for when complexity is unavoidable due to the sheer number of different teams involved. It’s for when no one entirely agrees on how to do things and don’t have enough common points of reference.

A lot of communication and transparency benefits can be brought to regular Agile or Lean-Agile projects when people are encouraged to talk, share, and be empowered. If you’re ready to put in the work to enable that, you might as well stick to Lean-Agile or Agile.

But if you believe your project is of a level of complexity and scale where siloes could fast become a problem, then you should consider SAFe.

Should you have a SAFe project in mind, please feel free to contact us.

Written by Jane Orme.