Improving SAFe thru Professional Scrum

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?

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 Masters.

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 to 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 the impact of it in the SAFe PO/PM body of knowledge (Similarly to the discussion of the Feature/Component team continuum).

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 to 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)

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 of 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 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. Does 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 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, 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 of adjusting what features we deliver and how as long as we focus on achieving the outcomes the business is focused on.

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, 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.

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. An advice to those planning to register to an Implementing SAFe class and become SPCs — verify your SPCT knows his/her Scrum and Kanban. Check if they have a PSM1/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.

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 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…

Improving how your SAFe implementation actually delivers speed and outcomes — rather than process overhead — is a core part of how I work with scaled organizations. Explore SAFe advisory or let’s talk.