Uncharted Waters

May 8 2018   9:28PM GMT

Do you need SAFe, the Scaled Agile Framework?

Matt Heusser Matt Heusser Profile: Matt Heusser


Essential SAFeOver the past year, every large company I’ve been working with has been doing some variant of the Scaled Agile Framework, or SAFe.

Yet many of the individual teams I work with don’t see benefit from SAFe. The pertinent questions seem to be: What problems does SAFe Solve – and do you have those problems?

The Problems SAFe Solves

Imagine your organization has teams of teams — at least eight teams of ten people each, plus overhead, plus business customers. That is close to a hundred people. These people need to be working on the same program; a single application or set of related applications so tightly coupled that releases need to be coordinated. The teams need to develop applications that have dependencies and integration points. It will be possible for each team to do good work as they understand the assignment, but the integration of the two could cause failure.

The solution to this is the Agile Release Train, or ART. The whole extended team begins with a big-room planning event – ideally three days in length. Leadership spends the first organizing, and the rest of the technical staff spend the last two building a shared mental understanding of what they will build, along with a shared commitment to get it done. After planning, the teams work in sprints, perhaps four, each of two weeks long. If integration has to be manual, the teams have an integration sprint, follow

Where I’ve Seen SAFe Misused

The organizations I’ve been working with are real enterprises. They have hundreds, some of them  thousands of people in the IT department. SAFe, the Scaled Agile Framework, has won the brand war. It is what peer company executives are implementing.

But let’s take a step back and talk about how the teams are organized.

One group I talked to had thirteen developers. Thirteen. Total. Add product owners and related roles, and we are talking about sixteen people. Another was much smaller, consisting of five groups of five or six people each, including business customers. Each of these teams owned a particular piece of functionality — support for a group of applications, or mobile development.

The thing is, those are all individual teams. There was no reason that all the developers in the company needed to deploy on the same release schedule — once every eight weeks. Flow theory would tell us it is better to dribble out changes, and support, a bit at a time, rather than overwhelm operations with a batch of changes roughly every-other month.

Nor did the teams need to deploy every-other month. In older versions of the “release train” and “program increment” concepts, the last sprint or so was a hardening sprint. That wasn’t for bug fixing, but instead to coordinate integration of large components that had to be fully developed in order to do manual integration testing. The examples about were completely independent groups; there was no integration to test. For that matter, the most recent guidance from Scaled Agile, Inc, suggests that while team develop on a cadence (all on the same program increment) that they decouple that from releases.

Not SAFe but Scrum … Or Something Equally Effective

Scrum, not SAFeThe teams I’m talking about could develop and deploy every two weeks (or better!) They could do planning every two weeks, and a retrospective every two weeks. They could embed the person defining the work on a daily, multiple-hours-a-day basis with the people doing it, hearing and solving problems as they occur. They could interleave testing and development concurrently throughout the sprint, instead of having a week of development and a week of testing – or worse, a design sprint, a development sprint, a testing sprint, and a fixing sprint.

But they don’t.

Instead, they go to an eight week waterfall-like process called a “Program Increment”, with a single, one to two hour “PI Planning” event at the beginning. They don’t have retrospectives … you see, they are “doing SAFe.”

These teams don’t need SAFe. They need to work together as an effective, self-organizing team — and maybe talk to a few people outside the team every once in awhile.

They could use Scrum — if they could actually do Scrum well.

Which is the rub. Because many of the teams that try to “do Scrum” end up failing to do the hard stuff.

So if you’re trying to “Scale” your team of fifteen people use some huge enterprise framework, take a step back. See if you just need to Save The Scrum.

SAFe solves certain big problems …

… but do you have those problems?

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • AgileSecptic
    What a load of b*ll*cks
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: