The Scaled Agile Framework® (SAFe®) has been with us since 2011, providing an hierarchical big picture that helps managers and executives to see the processes, roles and responsibilities, of a scaled agile implementation. With that big picture, comes a way to see where agile teams fit into a traditional hierarchical organisation by using Agile Release Trains, Lean-Agile portfolio management, and Program Increments. There are roles for everyone, even managers and architects can be seen on SAFe Big Picture. After all, they have to go somewhere, right?
Over time, the framework has grown and evolved. It now focuses on combining both Lean and Agile practices derived from hundreds of sources to deliver value based on an agile product management approach. Nothing is new in SAFe. It’s all been created by others and is now represented as a single library of proven practices.
The difference between project management and product management is subtle, but often trips up newcomers to agile. The tendency is to approach SAFe and other agile frameworks from a project management perspective. This approach, however, works only to an extent. If you’re going to make SAFe work for you, there are some common traps to avoid.
1. It's a framework, not a methodology
Methodologies are processed based and define all of the rules, artefacts, tasks and decision-making points that are required. In essence, a methodology is a complete set of rules and processes. PRINCE2 is an example of a project management “methodology”.
Frameworks, like SAFe however, are designed to be incomplete. While this means they are lightweight and highly adaptable, they often require significant expertise to make them successful. Some frameworks, like Scrum, provide a bottom-up approach. Ultimately, there is no “agile project management methodology” — they’re all frameworks.
Scrum – one of the agile frameworks – provides a minimum set of mandatory roles, responsibilities, artefacts and events. With Scrum, practices are then added on top to help to adapt to different contexts. Elements that work well when added on top of Scrum include:
- Velocity – A measure of the amount of product backlog that can be turned into an increment of Done within a single Sprint.
- Stories – A way of writing Product Backlog items that focuses on the end-user, their needs, and what solutions will help them achieve the outcome they’re seeking to complete.
- Estimation with Story Points – Using Wideband Delphi as a way to improve the estimation of what work can fit into a Sprint.
- Kanban – A tool for optimising flow by (among other things) limiting work in-practice and using explicit rules for moving work between its key steps.
SAFe uses a top-down approach. With a library of hundreds of patterns and practices you need experience in these to know which elements to apply and when. These patterns come from places like:
- Extreme Programming (XP) – practices for software engineering such as “pairing”.
- DevOps (the practice, not the software).
- The Principles of Product Development Flow by Don Reinertsen – where the focus is to establish optimal flow of value by dropping traditional lists of thousands of “requirements” (Reinertsen would call these “queues”) and a big bang stages approach to delivery, and instead using smaller, economically sensible batches.
To facilitate choosing the right parts of the SAFe framework, SAFe comes in four flavours:
| Essential SAFe | Portfolio | Large Solution | Full |
|---|---|---|---|
| Using an Agile Release Train (ART) to support 5-12 teams to collaborate in Program Increments to collectively and collaboratively deliver an integrated increment of the product that is potentially releasable. The choice to release or not is determined by the Product Manager. | Adds a Portfolio layer to Essential SAFe. This helps manage, define, and prioritise Epics in a Portfolio Backlog that ARTs will pull from each Prigram Increment (PI). | Large Solution is used when multiple ARTs need to coordinate and integrate their solutions. This is useful for value streams that require multiple Agile Release Trains that each create separate physical or software components that then need integrating. | Adds a Portfolio layer to several Large Solution ARTs. |
Don't use SAFe if you have less than 5 teams
If you don’t have 5 teams or more, don’t use SAFe. The overhead of SAFe’s product management approach is simply too large and unnecessary. Other agile frameworks, like Nexus and Scrum @ Scale, are lighter and less complex, and work more effectively to align less than 5 teams.
2. Don't be tempted to add a Solution Train if you don't need one
There is always a temptation to see SAFe as explicitly hierarchical and reflective of the internal hierarchy of the organisation. When an organisation has existing team, middle management, program, large work stream, portfolio, and executive layers, people try and “lift and shift” these directly into SAFe.
The instinct, in particular, is to see large solutions being developed in an organisation and assuming that Large Solution SAFe is needed to manage the hierarchy.
Don't use a Solution Train when:
- ARTs don't need to integrate their solutions. One of the requirements of Solution Trains is that they create an integrated increment across all of the ARTs by the end of the PI.
- ARTS have dependencies that can't be handled through sequencing Features or Epics in the Portfolio.
- When Portfolio SAFe will solve executive's and Agile Release Train's dependencies, and reporting delivery needs.
The prioritisation of ART’s delivery can be easily managed through Portfolio SAFe. using Epics and a Portfolio Backlog.
3. Don't translate project management roles and governance into SAFe Agile product management roles
Agile product management has different roles
When people start to explore SAFe and agile more generally they come face-to-face with different sets of roles.
- Product Manager – In SAFe, Product Managers play a key role in the trio of leaders that includes architects and the Release Train Engineer. All of these people work together to lead the Agile Release Trains (ARTs) in continuously delivering value.
- Product Owner (PO) – a member of the Agile Team responsible for prioritising the team’s Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team. The PO has a significant role in maximising the value produced by the team in coordination with the Product Manager.
- Business Owner(s) – The key stakeholders who evaluate fitness for use of the ART’s products.
SAFe does not use Project Manager, Program Manager, or Delivery Manager roles. Neither does it use Project Management or Program Management Boards. It’s governance utilises Product Management governance. That’s not to say, though, that the Product Manager isn’t accountable to executives or a budgeting committee. In many organisations, Product Managers are answerable to the Head of Product, A Product Board, or even directly to the Board of Directors.
4. The RTE isn't a Delivery Manager and isn't responsible for delivery
Determining when to release value, prioritising when certain Features are delivered and when, reporting to executive on delivery, marketing, stakeholder engagement, are all the responsibility of the Product Manager in SAFe. This is the agile extension of the Product Manager role we’ve seen for decades in places like manufacturing, including pharmaceuticals.
The Release Train Engineer (RTE) in SAFe is a Chief Scrum Master. As such, the RTE is accountable for:
- The effectiveness of SAFe and agile practice across the ART to optimise flow and improve delivery capability.
- Facilitating whole of Train-level events like PI Planning, and Inspect & Adapt workshops.
- Supporting the escalation of risks, issues and impediments when teams aren’t able to solve these themselves.
- Coaching and supporting Scrum Masters to enact good agile practice.
- Coaching the Product Manager on agile product management techniques and practices.
- Coaching stakeholders to optimise the way they engage with the ART.
5. Epic Owners are not the Executive
People see the word “Epic” and immediately assume that it’s owner must the the Executive. An Epic Owner is actually a role often undertaken by Product Owners in Agile Teams.
If you’re moving out of project management methodologies into SAFe, the Business Analyst or Service Designer who currently writes the business case is the person most likely to continue in the role of Epic Owner, and is also most likely to be embedded in an existing team as its Product Owner, reporting to the Product Manager in an ART.
Epic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They collaboratively define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.
6. Product Owners don't need to come from the business
The business might the owner the product that’s being built when project management methodologies are being used. It doesn’t mean, though, that when you start with SAFe you must select Product Owners from the business.
In the early stages of moving to SAFe, the business are not likely to:
- Have the capacity or the desire to suddenly join teams.
- Know how to optimise the value their agile team delivers.
- Understand how to use Scrum’s events to inspect and adapt the work the team delivers.
- Understand how SAFe works to optimise delivery for a whole Agile Release Train
When business are engaged without having buy-in or understanding of agile product management, a number of anti-patterns occur:
- Proxy-Product Owner: Someone is nominated to be the business representative, but they have no power or authority to make decisions regarding prioritisation. Decisions are only escalated to senior managers in the business resulting in delays in creating a potentially releasable increment of Done work.
- Optimise for one business unit: As Product Owners report to managers in the business and not the Product Manager, they take their orders about what work and Features the team should do from their own managers.
- Abandon the team: When priorities in the business area emerge, the Product Owner abandons working with team to address these issues.
Evolve the relationship over time
It takes time for business stakeholders to understand how to best interact and work with agile teams. Typically, they interact in the same way they would a project relationship, and then, over time, after working closely and collaboratively, they eventually take up full-time Product Owner roles with the structure evolving to focus on Agile Product Management. Expect this to take 2-3 years.
7. Many people do their SPC and then don't keep up-to-date
Scaled Agile updates SAFe about every 18 months. It takes lessons learned from a global community of practitioners and assesses what it will keep, what it will change, and what it will drop. It’s easy to do a 2-day SPC course and think you’re an expert. It takes about 5 years to learn how to use SAFe effectively and then continuous learning to understand how to apply SAFe’s evolving and new practices.
What's been dropped in SAFe?
There’s a few key areas to be aware of:
- The RTE is no longer referred to as ‘like a program manager’. This reflects the industry perspective that the RTE is a Chief Scrum Master and not a traditional Delivery Manager-style role.
- The Value Streams used to be a big part of SAFe. They were replaced in-part with ‘Large Solution SAFe’.
- Agile Teams no longer also have Development Teams. This ‘team within a team’ concept was also officially dropped by Scrum in Nov 2020.
What's been added?
- Scrum Master and Product Owner are just ‘specialty roles’ in Agile Teams.
- Flow metrics are an important part of understanding the ART’s agile capability.
- Organising around value elevates value streams to the Portfolio.
- Participatory Budgeting (PB) describes a practice for Lean Portfolio Management (LPM) uses to allocate the total portfolio budget to its value streams.
- Guidance for applying SAFe to hardware development.
What's still missing?
- Feedback loops and value-ased metrics. SAFe uses WSJF as a mechanism to prioritise for value, but it lacks feedback loops to both assess value and understand whether more investment is needed (or less) by Product Managers to achieve the value-driven impacts they’re seeking. In SAFe, teams do demos, but don’t elicit feedback. ARTs have system demos, but don’t inspect product metrics and elicit feedback on what to do next. These acts of empiricism are strong in Scrum, but sadly missing from SAFe.
- SAFe’s own version of Scrum – ScrumXP – still creates a language and terminology issue for those familiar with Scrum. Sprints are called “Iterations”, the Daily Scrum is instead referred to as a “Stand-up”, and the Sprint Review (which SAFe refers to as the Iteration Review) is about a Demo instead of eliciting feedback and empiricism. Unfortunately, Scaled Agile isn’t interested in keeping up-to-date with Scrum.
- There are still many levels of the Definition of Done, reducing the likelihood that a single team can create a potentially releasable Increment of Done in a single Iteration – there are additional layers of governance to clear, approvals by Product Management and Solution Management, before a release can occur. This makes Done like ITIL3 instead of ITIL4.
- Product Owners tend to be more like Story writers and Team Backlog managers than actual Product Owners.
Make your SAFe practices more effective
Get expert advice on how to make your Agile Release Train work smarter based on an assessment and comparison to similar ARTS and agile programs around the world.
Conclusions
SAFe has grown and evolved a lot of the last decade. In that time, its roles, responsibilities, events and artefacts have evolved. Lean was added to help the whole system of work optimise for flow, and in version 5.1, agile product management became a major focus over assuming that agile was an extension or mechanism to deliver products.
As SAFe continues to incorporate learnings, practices and patterns from other sources, it continues to grow in complexity. Ultimately, it takes time, experience, and expertise to learn what parts go together and why, and how to ensure its successful. Doing a “lift and shift” from one organisation directly into another isn’t likely to work. That doesn’t mean “take what works” when you’ve got no real experience with SAFe. Nor does it mean heavily customise SAFe, renaming roles and adopting only the symbols of agile. Doing so simply isolates you from industry standard practice and creates a legacy burden for training and documentation.
The best way forward with SAFe is learning. Learn which version of SAFe to use and when, apply the basics, and then experiment with adding more based on context and need. Start with one ART and then launch another one with the learnings of the first one. Learn how to launch a few ARTs before adding Portfolio SAFe.
