Minimal SAFe

"It's bloated, it's big, it generates massive overhead. And it cements status quo"

I claim - this isn't SAFe as intended, it's just how it is often understood. 

In this article, I want to share my experiences on what a minimal SAFe implementation actually is.

To set context: You don't use SAFe for single teams. You use SAFe when you have multiple teams only. The mechanisms of SAFe are intended to create overarching: transparency, alignment, ability to act and quality. If you have no issues with any of these, then SAFe just isn't for you. Simple as that.

A number of assumptions are stated as if they were facts. Everything can be put to scrutiny, but this would just bloat this article.

Minimal Organization

Unlike the SAFe big picture suggests, SAFe is actually very lean on process. Take away the SAFe events, there is - nothing that wouldn't need to be done anyways.
SAFe doesn't mandate anything to be done for the sake of SAFe. Everything SAFe has to say on a process level is merely guidance for unsolved problems that you may be having. If you have no specific problems, feel free to use whatever process suits you.

Team organization

SAFe has very little to say on how teams should work. SAFe is fine with teams using XP, Kanban and Scrum - and also with Waterfall or any custom approach the teams consider effective.

Problem only happen in reverse: Teams used to semiannual releases will struggle to meet SAFe's requirement of producing and demonstrating a fully integrated System every other week.
Development teams having a good Working mode and solid Engineering Practices will find a good SAFe implementation to be nearly invisible except PI Planning and the System Demo, where they interact with others contributing towards the same goal.

Program organization

At the minimal extreme, SAFe has very little program level activity: Common goals, shared Backlog, addressing and resolving systemic issues. That's it.
Program level activity might be done in less than an hour a week, and the Program organization might just be three people: Product Management, Release Train Engineer and System Architect.
Not much overhead for 50-150 developers, if you ask me.

The reasons why Program Level activity often takes so much tend to be:

1. Organizational impediments galore
2. Teams don't collaborate properly
3. Mindset and behaviour in Program Level isn't Lean-Agile

All three reasons should constantly trigger the question, "How can we do things differently so that we (as a Program Team) need to do less work?"

Minimal Roles

SAFe has three "Specialist" Roles that aren't shared with other frameworks. Does that necessarily add head count and complexity?

Product Management

If you have one product and multiple teams, you need to be able to deliver a single, Integrated, Working Product - so the work of each team should contributes to a single Whole.

Someone needs to define what the Product is. SAFe calls this "Product Management" The requirements of Product Management are:

1. A single Product Vision
2. A prioritized Backlog of unharnessed Value
3. Aligning priorities with the organizational strategy
4. An common plan aligning the indivdual team goals
5. Taking responsibility when this plan is in danger

The function can be assumed by the only Product Owner, one of multiple Product Owners or even all of them.
If we have 4-6 teams and a single Product Owner who also assumes Product Management responsibilities, SAFe might hint that this PO may have too little time for each team but it's still SAFe.

If you want to have a single PO who also assumes PM responsibility, that's still SAFe. No overhead needed.

System Architect

The role of the System Architect is probably the most disputed in SAFe. Let's forget the label for a minute and just say, "It's generally a good idea if you have someone whom you know you can ask if there are technical issues that are bigger than the team".
Does that someone need to decide what the architecture looks like, do they need to actively propose a solution? Let's be flexible.
Maybe that someone just feels responsible for rallying architecture-focused developers from the team on a common architectural goal - a community spokesperson who has the backing from other developers to represent them in order to prevent time-consuming, low-value large discussion groups.

Rather than asking, "Should we have a System Architect?", I would like to ask: "What happens if we have multiple teams and nobody who takes responsibility to bring developers together, nobody who can speak with the Product Owner about Technology in a language they understand?"

If that somebody is a senior developer part of a team, that's still SAFe. No overhead needed.

Release Train Engineer

Self-Organization is a great thing, until developers realize that multi-team collaboration often leads to overarching conflicts and local optimization.
Someone should make sure that global optimization happens, teams talk to each other, global issues become visible and systemic issues get addressed at system level.

This "someone" may well be a Scrum Master or a line manager - the important portion is that the RTE is able to take a neutral perspective, doesn't go into the work when big picture reflection is needed and has the standing in and backing of the organization to pull the big levers for change.

If someone is already doing this, you have found your Release Train Engineer. No overhead needed.

Minimal SAFe Events

Probably the second biggest complaint about SAFe except role mania is meeting madness. So let's address why these meetings exist and what's the minimal overhead.

PI Planning

The 2-days PI Planning with all of its content is one of the main "fear factors" for agile teams who have gotten used to lean, agile planning. Here's the deal: Nobody said the PIP needs to be 2 days. And nobody says it must have a 10-point, 16-hour agenda. Those are just suggestions.

What is essential is that teams consider not only their own next iteration, but about:

• Their mid- and long-term goal
• Their recent progress towards their goal
• Their next short- and mid-term goals
• Their mutual contribution towards each other

So, let's again, ask in reverse: "What happens if teams working on a common product don't do these things?" 

The PI Planning is not optional. What is, indeed, open to discussion are the questions of "How" and "How long". 

Is the PI Planning an additional event on top of other events teams have? Indeed. This is the one meeting that many teams fail to have, and it's also the reason why so many organizations fail to make the jump from multiple disjoint, erratic Scrum islands towards a "Team of Teams" which is aligned on a common goal. 

The PI Planning's default is 2 days per 3 months, which is just about 3.5% of development time. If reduced to one day, that number shrinks below 2%. A bearable amount of meeting to see the big picture, synchronize, align, sort out some misgivings and whatever else may be better done in person than via e-mail.

System Demo

How SAFe's System Demo is conducted is very flexible. It can be highly interactive, it can be an upfront show by Product Management or it can be each team having a "science fair" showing their work. What's not optional, however, is to produce an integrated system increment. The Demo only reveals if the produced increment is indeed, both usable and valuable.

"The facts are friendly, every bit of evidence one can acquire, in an area, leads one much closer to what is truth" - Carl Rogers

The System Demo generates these friendly facts, and there's nothing worse than either not seeing the outcomes within their big picture or holding fast to the fixed belief that somehow, things magically will work out.

A System Demo can take anywhere from half an hour to a few hours (with preference given to the shorter timespan) and the more often Demos happen and the more people are involved, the higher the level of transparency. Demos are never a waste - if they are used as a learning and feedback opportunity.

Systemic Inspect+Adapt

This event is where the Release Train Engineer, management and Scrum Masters try to find solutions to systemic problems encountered in the PI. 

To not go into too much detail, if you're not getting at least a tenfold Return on Invest between spent time versus solved problems, you're doing it wrong.

The Systemic I+A is another element oftentimes missing in Scrum implementations - a group of people having a dedicated slot in the calendar where impediments outside an individual team's sphere of control are addressed and resolved.

While the meeting itself may be invisible to developers, they are cordially invited to contribute known impediments - and to provide feedback on the effectiveness of solutions.

Scrum of Scrums

In frequent intervals, teams should synchronize around the questions, "Are we on track?", "Are we impedited?" and "Do we need help from someone?" - this meeting can be conducted by anyone, although the Scrum Masters should possess this information, so what's better than letting them align?

A SoS for a dozen teams can be over within 5 seconds if everyone says "We're doing great", and it can be done in a minute if the outcome is "We need to get together" or "We're challenged, but working on it with <others>". At least the communication should happen so that others know if they can chime in.

Once you have a communication channel where people can deal with issues bigger than one team, SAFe's minimum requirement is met.

SoS, like a Daily Scrum, can be over in a minute and should be over within 15 minutes. It shouldn't affect developers' schedule at all.

PO Sync

As soon as you have multiple Product Owners, they need to align frequently. Synchronization on a product level should happen at least once per iteration. That sync can happen before, as part of, or after, the Review (which is in SAFe terminology is called Demo).

If your Product is aligned around a shared goal and common goal, you meet the need of the PO Sync.

This becomes redundant in a Single-Person construct as people tend to be aligned with themselves (and if not, you have other issues that SAFe can't address, anyways).

The PO Sync takes as much time as it takes to keep the product aligned.  This can be anywhere from a few minutes to a couple hours. It should happen unbeknowest to anyone who is not part of Product Ownership of Product Management.

Minimal Plan

"But Michael, SAFe is still Big Upfront Design with quarterly releases", may be the biggest complaint. I claim: "Not if you're doing it right!"

What SAFe mandates in PI Planning is sharing a midterm vision, taking a good look at upcoming features - defining and aligning common goals. There's a massive leeway in what this means. 

Argue as much as you want, developers want to know if they'll be developing websites or washing machines 2 months down the line.  And business also needs to know if they're investing into software or tomatoes. 

We're not talking whether we will color that button red or green eight weeks down the line. That would be a complete misunderstanding of SAFe's PI Planning.

Business Context

What's the Big Goal, the headline for the next three months? Where do we want to be?

"Go Live", "Hit 1 Million Customers", "Serverless", "Seamless Integration" - that's the Program goal for the next quarter, the "Business Context". 

Additional fodder might be market reception or user feedback, but that's just the details.

If you need font size 6 to describe the goal on a single Slide, you're definitely over-engineering.

Features

Features are not containers of stories. They are hypotheses of business value, which we either obtain or not. If we don't know how we want to generate value - how do we know that we do? SAFe isn't about nerdgasm, it's about sustaining and growing a business!

How many features should we have? Well - a minimum of one. Otherwise, that would mean "We have no idea how to create value within the next three months!". If we have 50 features, we're also doing something wrong, because that translates to, "We don't know what's important." 

A set of 5-10 features may already be more than plenty for a couple months. 

How upfront do features need to be? Given that a value hypothesis can become invalid or be replaced with a different hypothesis at any time, there's definitely an argument that overplanning can lead to waste. 

Usually, feature waste is caused by poorly defined or overly specific features.

If your feature is, "ACME Corp. platform integration- transaction volume $3m per month", then there is sufficient leeway in the details to not have to replan when something doesn't work as intended or the value is obtained in a different way that we initially assumed. 

Stories

Why do we plan stories in advance? To get a common understanding of what we're up to, which problem(s) we're solving and whether that's even feasible within the time we have.

Many people don't realize: SAFe doesn't prescribe defining all user stories in PI-Planning to fill 6 iterations. Instead, SAFe operates with a fuzzy planning horizon: We plan 80% of our capacity for Iteration 1, 60% for Iteration 2, 40% for Iteration 3, 20% for Iteration 4 as "Commitment", that is, with work which has high predictability, necessity and value. In terms of fully planned Iterations, that's  just 2 full Iterations - the same planning horizon Scrum would encourage, except taking into account that uncertainty increases over time and it may be a while until we can replan face to face.

The remaining time in a PI is "Stretch", that is, we create an understanding based on today's information, what is the most plausible thing to do. Depending on how flexible demand in your organization is, Stretch can contain anything from "We'll keep it open for stuff we don't know about today" over "We would do these things if nothing more important shows up" all the way to "We have lower priority things that still need to be done eventually, so let's plan them now - if it doesn't get done, we'll replan later."

Stories are specific user problems - not individual tasks. SAFe specifically discourages planning tasks upfront, as this may distract people from focusing on the value at hand.

Objectives

The big mistake many teams make is that they use Business Objectives as mirrors of features or containers of pre-planned stories. Objectives are a strategic tool to help align both within the team and around the team. It's not even necessary to have a new objective for each iteration, but it's essential to have a goal. You start with a mid-term goal and break it down into achievable steps, ideally 1-2 iterations - but 3 can also be fine. And you shouldn't focus on team specific objectives , your objectives should be collaborative, otherwise you're doing it wrong.

Why do we need objectives? To see if we did go where we wanted to be, and to help others align with us without needing to drill into minute details of each story. 

Minimal SAFe Plan

Summing up the entire section on Planning - SAFe suggests that you should have:

• A business goal to move towards in the next couple months.
• A clear understanding of how you want to produce value.
• A decent understanding of the upcoming user problems you want to solve that fill 2 Iterations.
• Aligned objectives that enable frequent success validation.
• Enough flexibility to allow that at least half of your plan can go wrong or change.

If you have all these elements, you have a SAFe plan.

Being Minimally SAFe

You are Minimally SAFe when:

All those points are reasonable - and SAFe provides means and mechanisms to attain them.

How much effort do you need to invest into those? That depends on where you're coming from. 

If you couldn't achieve these things in the past - it might be a long journey.
If you've set the right levers already - very little.

The cost of Minimal SAFe

If you're already agile on a team level, SAFe might just require 2-3% developer capacity and roughly 5% from Product Owners and Scrum Masters on top of what each single team would invest.

Now, compare this to the cost that would be incurred if any of the above four items are not met.