Improving SAFe thru Professional Scrum

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

SAFe includes Scrum – so how come many Scrum practitioners and thought leaders consider it unsafe?

The Scaled Agile Framework (SAFe™) is one of the most popular approaches to applying agile at scale out there. SAFe’s perspective is that “Nothing beats an Agile Team” and it doesn’t try to reinvent the wheel or even innovate too much when it comes to the Team level. It takes advantage of established frameworks and techniques that work well – Scrum being the first and foremost of those.

Where it starts to get interesting (unsurprisingly) is when the patterns and practices for scaling are introduced – in SAFe’s Program Level. SAFe’s premise is that in the real world one team typically isn’t enough and several teams need to work in concert to build larger systems/solutions/products. In SAFe’s Program Level, a key piece is the Agile Release Train which is considered a team of Agile teams.

When it comes to the Program level SAFe doesn’t try to reinvent either – but here it uses Scrum/Kanban as a starting point and innovates in order to deal with some specific challenges of larger programs. SAFe also deals with Larger Solutions and the Portfolio, but let’s leave those out of the scope of today’s discussion.

The above intent, together with the fact that SAFe uses the Scrum Guide as its reference to what Scrum is, are encouraging signs. So, again, why do so many Scrum practitioners, trainers, and thought leaders consider it unsafe and a Scrum-but? I hear a lot of questions and claims. Let’s try to recreate some of these discussions and along the way make some recommendations.

Looks like SAFe’s Scrum Master is a coordinator and focal point for the team – not just a servant leader and coach accountable for enacting Scrum.

Yep. SAFe’s Scrum Master is more of an Agile Team Lead. This is much easier to implement in the real world but also means it will be much harder for the team to self-organize because they have a team lead that isn’t just focused on helping them improve via Scrum but is also their focal point for Scrum of Scrums, during PI Planning, etc.

The way I look at it – this is indeed a compromise that SAFe practitioners should be aware of. And part of the journey of implementing SAFe should be to maybe start with this Scrum Master stance but evolve towards more of the classic, professional Scrum Master stance over time. To use the leadership styles model we discuss in the Leading SAFe class – the starting point is more of an orchestrating and technical expert kind of leadership stance and the goal should be to evolve towards a more serving the team and the process style over time.

The main concern I have is not that SAFe’s Scrum Master is different than how Scrum defines it. It’s that this difference isn’t made transparent – which doesn’t give practitioners the opportunity to inspect, think about it, and maybe adapt. Maybe your organization is actually better off with an Agile Team Lead than a Scrum Master. But you won’t have a chance to think about it and decide if you think you already have Scrum Master.

SAFe’s Product Owner is a proxy, not a real Product Owner. They are more similar to a team member focusing on the stories than a person accountable for optimizing the value delivered by a Product.

SAFe’s approach to product ownership is that scale is achieved by splitting the product ownership role between Product Management, which is more like the classic Scrum Product Owner, and the Product Owner, which is indeed more like a proxy or technical product owner working more closely with teams. One of the main reasons SAFe takes this path is that it’s hard for one Product Owner to deal with too many teams while balancing both outbound and inbound activities.

Large Scale Scrum and Nexus prefer to have one Product Owner for the entire product with one Product Backlog. In real life, these Product Owners are typically accountable for the value delivered by these multiple teams and rely upon a lot of assistance from the Development Teams in order to deal with the challenge of scale.

If we ignore the differences in lingo, This is quite similar to SAFe’s approach. But we can’t ignore the differences in lingo. We DO want to see Product Owners as individuals owning products and being accountable to optimizing value.

What I’ve seen in the trenches ranges from SAFe Product Owners that really own a product within the bigger solution, own a set of features, or even a specific feature that is currently being developed, all the way to technical product owners that aren’t real product owners. There’s definitely room for more discussion of this continuum and its impact of it in the SAFe PO/PM body of knowledge (Similar to the discussion of the Feature/Component team continuum).

Scrum is a simple framework that deals with complex domains. SAFe seems more of a methodology to Scrum practitioners as it has many more details and seems to try to solve all challenges in a prescribed way. SAFe’s creators seem to enjoy the fact that it is complicated since it provides an excuse for more and more training possibilities.

Well, the reality is that SAFe serves the mainstream market of practitioners that struggle to get from Scrum’s simple framework to an approach that works in their reality. Scrum simply doesn’t provide enough answers to some of the tough scaling challenges, and not everybody has the time or skills to come up with an approach that works in their context. This market needs some more guidance.

Looking at SAFe as it grows over time I see a constant struggle between the desire and drive to simplify and focus on the essentials to the desire to give more answers. Like any other product, it is tough to figure out which features/aspects to build, get rid of, simplify, and how optimize the experience. It’s hard to create the ideal scaling framework.

Beyond how SAFe is defined, there’s also how people perceive it. And yes lots of practitioners prefer to see it as a Methodology rather than a framework. As someone teaching SAFe Program Consultants, I try to discuss it in my classes. (See a recent blog post I wrote about this)

SAFe’s Sprints are 3 months long and are planned in detail – How is that Agile?

Well, let’s unpack this. SAFe has a cadence at the Team and Program levels. The team-level cadence is called Iterations but other than that different name is almost identical to the Scrum Sprint. It is 2 weeks long, the goal is to deliver a potentially releasable increment of working software, There’s Iteration Planning, Daily Standup (which is essentially Daily Scrum), Iteration Review, and Retrospective.

I’m guessing the confusion kicks in when people look at the Program Increment. That’s typically 8-12 weeks long and includes multiple Iterations (4-6 typically). Why don’t we just have a Program Increment that is at the same length as the team-level increment? Because from an economic perspective the transaction/coordination costs for running the whole program on a 2-week cycle don’t make sense. Think about having big room planning with 100 practitioners every two weeks. Kind of hard.

Why do we even need this big room planning in the first place? Now that’s another question. In situations where teams do have some dependencies, when we need a longer horizon of business planning and we do want to involve everyone in having discussions about what is valuable, realistic, and converge on plans, big room planning comes to the rescue. Do we have to have these discussions every two weeks? probably not.

So the approach SAFe takes is to look at each one of the program-level activities and consider both the coordination cost/overhead as well as the holding cost or cost of delay and come up with the right frequency. For example, while Program Increment Planning happens only at the Program Increment cadence, System Demo, which is similar to the Sprint Review but at the program level, happens on the iteration cadence so every two weeks typically. Why? Because the cost of delayed empiric feedback is very high and we understand we live in an uncertain environment, we assume variability and we want to preserve the option to adjust course throughout the PI.

This is similar to the Scrum Planning Onion. Teams and Agile Release Trains plan at the Daily, Iteration, and Program Increment levels. The deeper in the onion we are the more detailed we plan, but the shorter our planning horizon. So in Program Increment (PI) Planning we should plan for a longer horizon but at a much lower level of detail. Do a lot of SAFe practitioners plan the PI in too much detail, not leaving enough room for uncertainty and learning once we get to the Iteration and Daily planning levels? Oh yes. Do a lot of Scrum practitioners do the same thing for the Sprint not leaving enough room for uncertainty and learning throughout the Sprint?

Like the Sprint Goal guides the Dev Team in case they want to consider changing the Sprint Backlog, PI objectives help teams adjust course throughout the PI if it helps them achieve their objectives.

Bottom line, SAFe’s Program Increment and the way you plan it can be closer to “following a plan” or an agile basis for “responding to change”. I certainly see it and teach it as the latter.

SAFe focuses on predictability much more than it does on empiricism and value discovery

SAFe actually tries to balance business agility with predictability. Both of those are important to the typical enterprise-scale technology organization.

SAFe includes mechanisms such as PI Planning, Roadmaps, forecasts, PI Objectives, and confidence votes to provide predictability. It includes Stretch PI Objectives, The Innovation, and Planning iteration, and specific recommendations on how to plan in order to maximize predictability in face of variability and uncertainty.

It also includes System Demos, Continuous Integration, Minimum Viable Products, and others in order to deal better with uncertainty.

And there’s no assumption that predictability will be absolute. A program/ART that achieves 80% predictability is considered within a reasonable range. And this predictability is measured in achieving outcomes, not delivering stories or points. This supports agility in adjusting what features we deliver and how as long we focus on achieving the outcomes the business is focused on.

SAFe allows you to defer integration and hardening to the end of the Program Increment

Not really. SAFe used to have a Hardening iteration but it’s been decommissioned for years now. The Innovation and Planning iteration is the place to take a breather, and do some innovation activities that work better when you can clear your head and focus on them (Which doesn’t mean by the way that innovation isn’t allowed or needed throughout the PI), reflect on the current PI and plan for the next PI. integration and hardening is part of the definition of Done that each team strives for within every 2-week iteration. The System Demo that happens every 2 weeks is an opportunity to review the whole integrated system increment, get transparency for where you are, and inspect and adapt the plan for the rest of the PI accordingly.

What you could do about this as a SAFe practitioner/trainer

I wish more SAFe practitioners would dive deeper into the Scrum world as a step in their life-long learning journey. A self-respecting SPC should also have enough knowledge and experience with Scrum to pass at least some of the Scrum.org assessments. The same applies to people training SPCs. They should have a very strong experience with Scrum and Kanban. Advice to those planning to register for an Implementing SAFe class and become SPCs – verify your SPCT knows his/her Scrum and Kanban. Check if they have a PSM 1/2/3.

On an ongoing implementation, one useful thing you could do is run a workshop reflecting on the Scrum Guide and what are some key gaps to consider addressing. I’ve done this in one of my larger financial tech clients and it was a pivot point in the implementation. We looked specifically at the Scrum Master and Product Owner roles identified a lot of gaps and changed our perspective about these roles.

What you could do about this as a Professional Scrum practitioner/trainer

As an SPC Trainer (SPCT) and a Scrum.org Professional Scrum Trainer (PST) I’m committed to helping people understand and implement SAFe safely. It isn’t the only scaling approach I work with, but a lot of people seek me out when they do want to implement SAFe but want to keep to the true spirit of Agile/Scrum.

I’m glad to see more and more of my colleagues in the professional Scrum.org community that are interested in working towards a better understanding of Scrum Theory, Values, Events, Roles, and Artifacts in the SAFe world. After all, that’s what it means to be a community that shows respect, openness, and courage.

Since SAFe is so prevalent, I think this is a huge opportunity to improve the profession of software delivery.

I’m excited! I see another bridge on the horizon…

This article was originally posted on the Scrum.org blog

Subscribe for Email Updates:

Categories:

Tags:

Engineering Practices
Kanban Game
SAFe Release Planning
ALM Tools
Rapid RTC
Sprint Iteration
ATDD vs. BDD
lean agile change management
Agile Delivery
Nexus vs SAFe
agileisrael
Value Streams
Agile Project Management
Operational Value Stream
Jira
Acceptance Test-Driven Development
AI
Elastic Leadership
Agile Development
LPM
Continuous Planning
Agile Exercises
Release Train Engineer
Process Improvement
Lean-Agile Software Development
Games and Exercises
Introduction to ATDD
speed @ scale
DevOps
Agile Product Ownership
Coaching Agile Teams
IT Operations
Agile Techniques
Continuous Improvement
Software Development Estimation
Slides
Development Value Streams
Accelerate Value Delivery At Scale
Managing Projects
Tools
Risk Management in Kanban
PI Planning
Kanban Basics
Agile Assembly Architecture
Scrum Guide
Lean Software Development
Test Driven Development
Legacy Enterprise
Introduction to Test Driven Development
Agile Project
Agile Risk Management
Nexus and Kanban
speed at scale
Lean Startup
Scrum Primer
Perfection Game
Scrum Master Role
RTE
Story Slicing
Self-organization
Kanban Kickstart Example
Nexus and SAFe
Agile Mindset
Product Management
Artificial Intelligence
RSA
Iterative Incremental Development
Scrum.org
Systems Thinking
RTE Role
Agile and DevOps Journey
Business Agility
Professional Scrum Product Owner
Agile in the Enterprise
EOS®
System Archetypes
The Agile Coach
Hybrid Work
Entrepreneurial Operating System®
Scrum Values
Product Ownership
predictability
Releases Using Lean
Kanban 101
Agile India
Built-In Quality
Principles of Lean-Agile Leadership
Change Management
BDD
Achieve Business Agility
Amdocs
Continuous Delivery
Continuous Deployment
Jira Cloud
Nexus Integration Team
ATDD
Lean Agile Organization
Video
Scaled Agile Framework
Scrum
Professional Scrum Master
Lean Budgeting
Professional Scrum with Kanban
Agile Program
Spotify
Jira Plans
Scrum Master
System Team
Covid19
Agile for Embedded Systems
GanttBan
Webinar
Code
Lean-Agile Budgeting
Limiting Work in Progress
WIP
Planning
An Appreciative Retrospective
Risk Management on Agile Projects
Nexus
Manage Budget Creation
Lean and Agile Principles and Practices
Certified SAFe
Effective Agile Retrospectives
LeSS
Presentation
POPM
Agile Israel Events
Atlassian
Atlaassian
Agile Games and Exercises
SAFe DevOps
Pomodoro Technique
Certification
Agile Release Planning
AI Artificial Intelligence
ScrumMaster Tales
TDD
Lean and Agile Techniques
SAFe
Tips
System Integration Environments
Implementing SAFe
AgileSparks
Program Increment
Scrum and XP
Scrum With Kanban
Agile Israel
Advanced Roadmaps
Agile Outsourcing
PI Objectives
Software Development
Daily Scrum
Continuous Integration
Agile Contracts Best Practices
Kaizen Workshop
Kaizen
Agile Product Development
Lean Agile
Reading List
Jira admin
NIT
ARTs
Lean Agile Basics
Agile Testing Practices
Agile Games
Sprint Retrospectives
LAB
What Is Kanban
Applying Agile Methodology
Large Scale Scrum
Agility
Managing Risk on Agile Projects
Quality Assurance
Kanban
SPC
SA
Lean Agile Leadership
QA
The Kanban Method
Legacy Code
Agile Basics
ROI
A Kanban System for Software Engineering
Implementation of Lean and Agile
Enterprise DevOps
Sprint Planning
Agile Release Management
Agile
Portfolio for Jira
Lean Risk Management
Risk-aware Product Development
ART Success
Agile Marketing
Lean Agile Management
Agile Community
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart