Why do you want to measure a team’s performance in SAFe?
Why do you think SAFe does not explicitly point to a team performance measure?
SAFe leans (ha! pun intended) quite heavily on the ideas of W Edward Deming.
His 14 points for management from “Out of the Crisis!” are highly valid.
Here’s some of those 14 points (from this link : https://deming.org/explore/fourteen-points/)
“10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
11a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
11b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.”
So – perhaps worry less about KPIs, metrics and performance targets and more about growing leadership at all levels within the organisation?
The empirical evidence for this comes from the DevOps movement, as stated in the book “Accelerate! The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” by Forsgren, Humble and Kim.
They
(a) provide 4 metrics (the DORA metrics) at the organisational (ie ART) level that correlate with high performance, and
(b) point to Ron Westrum’s notion of a “generative” culture, in which
– teams own performance, and raise the bar al the time
– the team’s job is to identify systemic problems across the organisation
– management’s job is to address those systemic issues
– this is done in respectful partnership
TLDR; The evidence suggests that individual and team level OKRs and performance metrics are worse-than-useless, in that they degrade organisational performance. Organisation-scale metrics that teams and leadership collaborate to address are better. Read “Accelerate!” and “Out of the Crisis!”
–

I guess I’d suggest that you need to stop looking for solutions to push onto your team in your context, and start making the problems highly visible to the team.

When they can see the problems, as a team, you can start to experiment on potential solutions. And that’s what we want – teams that experiment and solve their own problems, not “heroic” Scrum-Masters-As-Consultants addressing the surface symptoms.

Using a good Kanban method board is maybe one starting point for this.

– get the team together and map the value stream you have, from an idea right the way through to completed, deployed software in the hands of the users

– identify every stage gate, hand-off, discussion point and so on.

– build this into a Kanban board; look at the Kanban Method for ways to do this. Each stage needs it’s own column. Each column should be split into “Doing” and “Done”; if you prefer you can split into “waiting to be worked on” and “being worked on”

– when work is stuck because someone is doing something else, then block that work

Then you can start to look at why the team is burning out…..

In terms of one-week Sprints….

The Sprint Cadence is a wrapper for when you want to explore product-market fit with stakeholder and customers. One question might be “should we end-of-life this product now?” for example. A week seems a very short cycle to be able to obtain meaningful business intelligence about the evolution of the market, customers, technology, legal frameworks, what your competition is doing and therefore how you need to inspect and adapt.

So – sure, potentially longer Sprints are an experiment you could run, but I’d tend to make the work visible first, and focus on why everyone is so busy and yet stuff is not being completed…

I’ve not come across this model, but you can make a Sprint any length you like.

At a point, however, the Sprint cadence is really focused on the product-market fit

The Sprint Goal aims to be fulfilling an enduring market need, and at the Sprint Review we’re inspecting both the product AND the external factors influencing the competitive market.

Should we end-of-life this product and move to something else is a key question to ask, even if the market is an internal one. Are people moving to “shadow IT” for their solution? Has the technological landscape shifted?

So – for sure you can do 2 day Sprints and have a high energy hack-a-thon type environment, but if the Sprint Review falls into the “demo-day dysfunction” with a lot of back-slapping and no hard, externally facing empirical data, you’ll fall into the same sunk-cost fallacy as a waterfall product…

There’s different scaling patterns you can adopt; some of those are frameworks (eg SAFe, LeSS, Nexus Scrum) but you can also adopt whatever works in your context.

At a point, my experience is an awful lot of the “at scale” stuff deals with exposing where the scaling approach has problems, which usually boil down to

– conflicting priorities between teams
– too much work-in-progress across the organisation as a whole
– teams not organised around a value stream
– teams cannot work independently of each other

In a new transformation that’s often compounded by Conway’s Law – the architecture of the system is defined by the old organisational and team structures, so when you rearrange that there tends to be an awful lot of cross-team dependencies which grind things into mud.

SAFe has the Scrum-of-Scrums within a given value stream (ART) really just to try and deal with Conway’s Law as you start to shift, and holds up Team Topologies as your destination – that is to say a shift from highlighting and *trying* to manage dependencies between teams (or team-of-teams which SAFe calls ARTs) until you realise this isn’t working and start to refactor the architecture so teams can work independently.

Nexus Scrum has senior engineering staff working 50% on the “Nexus Team” that handles any integration work across team boundaries and ensures that things are resolved as a way of “cutting out the middle person” (ie the Scrum Masters) from the integration problem, again as you try to shift away from “dependency hell”

As for metrics, the only ones that really matter are the “DevOps” metrics of

– deployment frequency
– cycle time for new work (lead time for changes)
– change failure rate
– mean time to recovery after a failure

The key thing is that those metrics are there for the teams, so that they can shape how they improve, and highlight systemic issues for management that need to be addressed….