Intro to SAFe®: Scaled Agile Framework®

So you want to deliver software across multiple dev teams? You’re probably confused by all the guides comparing different Agile scaling frameworks. And confused that each of them has so much to learn - a book or two and a bunch of certifications.

Let’s focus on the current most popular framework, SAFe. Let’s get the flavour of what SAFe is all about. We’ll see why we'd use it, the key ideas and how it differs from the other frameworks.

Why use a Framework for Scaling Agile Delivery?

Running big projects is different from small projects. Especially it requires:

• Coordinating delivery across multiple teams.
• Working with multiple types of stakeholders. 
• Keeping everyone aligned with business goals. 

With just one team, everyone can talk to everyone. Coordination happens more naturally. Big projects need more alignment practices. This is where the scaling frameworks can help. 

Why SAFe®?

SAFe emphasises that achieving an optimal culture for Agile is one of the hardest challenges of scaling. Culture problems are high on the list of blockers to scaling agile. To address this it takes a holistic approach. 

SAFe is not only a project management methodology. It incorporates principles from Agile, DevOps, Lean product development and systems thinking. We can think of SAFe as a core of practices with a supporting knowledge base around them.

What is SAFe®?

Different SAFe guides describe SAFe as a methodology or as a knowledge base or as a set of templates. This can be confusing but they’re all correct. The knowledge base is used to explain the framework’s core practices and the various ways to apply them. It contains templates for different scenarios.

SAFe® Overview

There is a lot in SAFe 5.0 and this is just a brief introduction. I’ll just explain some of the most illustrative topics to give a good sense of SAFe.

Leadership

SAFe recognises that only leadership can change the system. Leaders have to be clear about the intended direction and guide change. Otherwise there can be unresolved disputes about direction or some stakeholders may not fully buy in. The upshot is that leadership is crucial to culture.

SAFe looks for leaders to coach and mentor as well as set a great example. This means: 

• Effectively communicating a vision.
• Motivating by explaining drivers.
• Building coalitions. 
• Encouraging healthy risk-taking.
• Ensuring a suitable funding structure.

There are expectations on all levels of management. SAFe sees Agile software development as part of business Agility. SAFe is not just about project management. It is aimed at full business Agile transformation situations as well as individual large programs.

ARTs (Agile Release Trains)

The Agile Release Train is a team of teams. It is a set of teams delivering services that are all part of the same product.

SAFe describes the ART as a virtual organization. This is because the ART is meant to be self-sufficient. It should have available all of the resources needed to deliver value and resources should be long-term dedicated to the ART.

SAFe values alignment between teams very highly. Teams work to a common cadence and come together regularly. There are two levels of cadence for different levels of the program:

1. Iterations at team level. These are every two weeks (basically Sprints). Each team has its own backlog and stories for the iteration.
2. Program Increments at ART level. These are every ten weeks (five Sprints). The ART has a program-level backlog and high-level allocations to teams are made for a Program Increment.

Teams work to their iterations of two weeks using either kanban or ScrumXP (teams can be free to choose). At the end of each iteration there is a demo session for the whole ART. This helps each team see progress other teams are making.

The team-level iterations are likely familiar as these map to Scrum Sprints. What takes some understanding is how the Program Increment cycles are layered on top.

Program Increment (PI) Planning

“PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe.”  SAFe PI Planning

PI Planning in SAFe occurs every five Sprints (5 Sprints = Program Increment = PI). It brings the whole program together to plan the next Increment.

SAFe stresses involving everyone in PI Planning. This is partly to build social relationships and encourage communication. It’s also about ensuring everyone can buy in on the vision. PI Planning is where the vision is agreed.

Leadership has a key role to play in PI Planning. Planning starts with a presentation of a draft vision for the next Increment. Leadership should communicate this vision, conveying the motivations and also inviting everyone to think it through. The program will collectively shape that vision over the two days of PI Planning.

Here is a sample PI Planning agenda:

This sample PI Planning agenda based on one from the SAFe PI Planning documentation.

Notice that the agenda starts with presentations of the aims for the Increment and the motivations behind those aims. Architecture is included in this as it’s important to have a plan of how the vision can be realised. At this point plans are being presented to the teams for their input.

The rest of the PI Planning is dedicated to teams breaking out to work through their parts of the plan. There’s an expectation that teams will need to coordinate here on any inter-related pieces. This process adds detail to the plan as feedback from the teams is used to revise the plan.

A confidence vote is included to ensure that concerns are raised and there is then time for reworking to address concerns. It gives every team the opportunity for input and enables teams to buy in on the plan.

This can seem like a lot of process for those more familiar with working with just individual teams. The point is that larger programs need more direction. The SAFe guide illustrates this with a quotation:

“The more alignment you have, the more autonomy you can grant. The one enables the other.” Stephen Bungay

Program Kanban

Features being delivered in a Program Increment are monitored in a Program Kanban. This could be pictured like:

The Program Kanban is maintained by Product Management and Architecture. It is used to gain visibility of progress and to ensure that no particular team becomes overloaded.

The Program Kanban is not the only way of monitoring progress. Individual teams may also have their own methods, either Scrum or Kanban. There may also be higher-level Kanbans for monitoring above the level of features. For example, monitoring Epics (which can span multiple Increments). In very large-scale implementations there may also be multiple related ARTs/Programs, monitored and run as a Portfolio.

Innovation and Planning (IP) Iteration

The first iteration (Sprint) within a Program Increment is reserved for Innovation and Planning. This ensures time is set aside for innovation and other work that does not fit neatly into delivering features. These include:

• Innovation and exploration e.g. PoCs, forming new ideas
• Infrastructure and tooling or release activities
• Education and documentation
• Follow-ups to PI planning, backlog refinement, prioritization etc.

The IP Iteration also acts as an estimation buffer, though it should not be regularly relied upon for that purpose.

Architectural Runway

SAFe does not advocate Big Design Up-front. It also does not advocate leaving the architecture to only evolve out of what teams do. It tries to strike a balance.

The problem with not doing any central architecture is that individual teams are not best positioned for medium-term planning that spans the system. Teams have remits on particular areas. It’s difficult for teams to get a wider view on the whole system.

The architecture function is intended to set a direction that anticipates future business needs. It also plays an important facilitation role. Architecture can help teams to collaborate by guiding teams on which one does which part and how to go about it.

SAFe’s vision of architecture is not of an ‘Ivory Tower’ Architect removed from the practice on the ground. The aim is to provide “just enough” architectural planning to set a coordinated direction but not too much as it should avoid becoming restrictive.

Critical Success Factors for SAFe®

SAFe provides a knowledge base to guide practitioners. There is a lot of information and the knowledge base refreshing asks the question “how closely does an organization need to follow various SAFe practices to get the desired result?” It suggests ten critical success factors for essential SAFe.

We’ve covered already that teams should be self-sufficient and aligned to value (2), synchronized across the ART (3) through PI Planning (4). We’ve not touched much on customer centricity (5), which is about practices to understand the customer and how the solution addresses their needs. We’ve also not touched on DevOps but SAFe recommends releasing often to respond to feedback and has suggestions for achieving this.

We’ve talked about the whole-ART demo sessions (6) in each iteration. The demo is actually part of an Inspect and Adapt event (7) which also includes looking at progress metrics and a retrospective.

We’ve looked at the Innovation and Planning Iteration (8) and how it is used for exploratory and supporting work. We’ve also looked at Architectural Runway (9) and how it provides “just enough” architectural planning to set a coordinated direction. Direction-setting is a core responsibility of Leadership (10), who have the influence necessary to align teams and ensure buy-in.

Underpinning all of this is the SAFe® Lean-Agile Principles (1). In fact the Principles are realised through the practices. These are (with my explanations):

1. Take an economic view = understanding that delivery involves trade-offs
2. Apply systems thinking = looking holistically both at the solution and the delivery setup
3. Assume variability; preserve options = being flexible and avoiding too much Big Up-front Design
4. Build incrementally with fast, integrated learning cycles = releasing often
5. Base milestones on objective evaluation of working systems = assessing results
6. Visualise and limit WIP, reduce batch sizes, and manage queue lengths = avoiding any teams becoming overwhelmed
7. Apply cadence, synchronise with cross-domain planning = PI Planning on common cadence
8. Unlock the intrinsic motivation of knowledge workers = providing autonomy within a clear direction and encouraging learning and experimentation
9. Decentralize decision-making = only strategic decision-making should be centralized to ensure empowerment
10. Organise around value = prefer feature teams aligned to distinct areas of business value where possible

SAFe® in the Wild

There has been criticism of SAFe. The biggest is that it centralises too much and this invites command-and-control management. Agile Manifesto signatory Ron Jeffries warns that “SAFe will be installed in a fashion that won't just fail to support Agile, but that will suppress it.”

Part of the criticism is that SAFe risks being overused. Certainly one should not centralise where one does not have to. The overheads of SAFe do not make sense unless the program is large enough to need them. The minimum ART size should be 50 people in SAFe.

Undoubtedly there is a risk that SAFe can be applied in a way that becomes top-down. The concern is not so much with SAFe itself as with how it is likely to be employed. I will not take a stance on this other than to note that there is a general problem for the industry here. Scrum has also been subject to corruption in practice.

There are other scaling frameworks available (LeSS, Scrum@Scale, Nexus, DAD etc.). Some are notably more lightweight. For example, many other scaling frameworks do not require the whole program together and instead prefer teams to send representatives to program-wide meetings.

There are also criticisms out there of the whole space of Agile frameworks. My intention here is not to give any recommendations, just to empower readers to be able to find out more (and I've written more on this elsewhere).

Next Steps with Scaling Agile

There are a lot of Agile scaling frameworks and comparing all of them is a big job. There are guides that do this ,if that’s what you’re looking for.

The SAFe documentation at scaledagileframework.com can take some getting used to.  The SAFe Big Picture Configurations presents four configurations of SAFe. Essential SAFe, Portfolio SAFe, Large Solution SAFe and Full SAFe. These are tailored to different sizes of implementations. Most of what we’ve discussed is Essential SAFe. You have to learn how to click around to the bits that you want, or know enough to be able to search for what you want online.

If you’re looking to find out more about SAFe, then SAFe Distilled is the natural book to go to. It will certainly give you the background to use the documentation and see where to go next.

Image Credits

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc

Title image of Bear by Alexas_Fotos on pixabay.

Kanban image uses Postit Notes by Alexandra_Koch from pixabay.

Critical Success Factors image uses various images from thenounproject. Building by kareemov, Person by Alex Berkowitz, Agile by BomSymbols, Team by Unstashable, Synchronization by Prosymbols, Customer by Lars Meiertoberens, Training by LUTFI GANI AL ACHMAD, Adapt by Phạm Thanh Lộc, Research data by HLD, Brainstorming by Adrien Coquet, Binoculars by Luis Prado, Weightlifter by Brad Avison.

Clock in Critical Success Factors by OpenClipart-vectors on pixabay.