Recent Twitter conversations inspire me to pull out some of my concerns with SAFe and talk about them. (UPDATED with suggestions)
SAFe isn't as good as it could be.
Nothing is as good as it could be, of course. SAFe, however, has wonderful materials, with a growing array of proponents and trainers that rival Khufu. The level of investment in it makes clear that it can afford to be better. Given that it can afford to be better, it's fair to ask it to be.
Consider this to be me, asking. I'll put suggestions in italics.
SAFe does allow for improvement. This is unrealistic in its present form.
We're assured, repeatedly, that SAFe is always undergoing improvement, and that SAFe proponents expect SAFe installations to improve what they do. I have not seen evidence of the first, and I think the presentation of SAFe militates strongly against changing on the ground.
Provide more ways to improve toward Agile explicitly in SAFe. Point to directions where Agile-focused improvement may be desirable. Others of the ideas in this article are examples.
SAFe emphasizes top-down.
The structure and teaching of SAFe is relentlessly top down. All the important stuff is figured out up in Portfolio. All the features are figured out up in Program. Now you guys Build and Test that.
This focus will appeal greatly to corporations, many of whom believe that the people on top know more about what should be done, and how it should be done, than the people doing the work.
This thinking is, however, directly in conflict with the ideas of Agile, and of much of modern management theory. Responsibility and authority are best pushed downward in organizations. SAFe has little or no such focus.
Focus first on pushing authority and responsibility away from top management, leaving them only with the minimum required to do a good job.
SAFe leans the wrong way with "alignment".
SAFe gives the impression that the things it recommends are the place to be. In my somewhat experienced and thoughtful opinion, the things it recommends are, at best, "remedial" places to pass through on your way to better places to be. It offers stopgaps as if they were final answers.
SAFe says "train everyone". It values "alignment", which means, or will be interpreted as, "everyone do this". On the ground, I expect that we will not see much evolution from SAFe to something better.
Truth is, even simple Scrum teams often do not evolve very far. Much of this is due, in my opinion, to management dictating that Scrum must be used. (There are other causes as well.) SAFe is more likely to result in management imposing structure and teams being unable to move in better directions. If they try, they're likely to be hit with the Alignment Ball Bat.
Recognize that alignment is one tool of value, and an inferior one in many cases. Agile principles value diversity in large and small scale, and bring about alignment through common goals and vision. SAFe should follow this style.
Team structure works against Agility.
SAFe's so-called "ScrumXP" teams are called "cross-functional define-build-test" teams. There is lip service to cross-functional structure but teams are described as being made up of developers and testers. Defining seems to be embodied in the Product Owner. Scrum at its best has Product Owners bring problems to the team and the team solves them.
Focus on truly cross-functional teams and on pushing more and more responsibility to the team.
You are large, therefore scale.
SAFe appeals to the simplistic thinking of large organizations to the effect that they need to standardize things, and that because they are large, they are different. It does not offer tests for where an organization really needs "scaling", nor does it even acknowledge that a large part of your organization probably doesn't need it at all.
Much of the work of an organization is already done by a single team. These teams do not need SAFe. Much more could be done by a single team. The best thing to do in such a case is probably to form that team. Again, such a team would not need SAFe. The greatest bulk of remaining work could be done by Feature Teams, although most large organizations seem to create Component Teams instead. Feature Teams do not need much from SAFe.
Focus more on transforming the organization toward more Agile structures, and far less on aligning everyone in lock-step.
You need Release Train.
Release Train is an example of a remedial practice presented as an ultimate solution. The need for Release Train is a result of work being partitioned across teams in such a way as to need coordination to put it back together. SAFe does not push hard to eliminate the problem: it just gives a way to accommodate it.
SAFe does allow, and kind of recommend continuous release. Its practices push for alignment and away from continuous.
Explicitly present Agile Release Train as remedial and focus, primarily, on continuous integration and continuous release.
Build on cadence, release on demand conflicts with Release Train.
SAFe training spends a huge amount of time on the "Agile Release Train", which is a five-iteration period. The final iteration is HIP (Hardening, Innovation, Planning). The focus of the release train is to get everything in the plan done in those five iterations. This will focus delivery on that interval.
It's clear that delivering value sooner is better than delivering it later. SAFe gives some lip service to this with its "build on cadence, release on demand" mantra, but its training and focus push toward synchronizing, not continuous delivery.
Focus more on continuous delivery and treat Agile Release Train as the remedial practice it is. It should also be much more explicit that the need for hardening is a need for improvement.
Dependencies are normal mode.
SAFe assumes that you'll have dependencies in your plan. The solution, apparently, is to put things up on the board and string red threads between them, and send cards to other teams telling them that you're depending on them. All this is done in the Amazing Two Day Mass Meeting. (Perhaps that's not its official name.)
Dependencies are not "normal mode". They are impediments. They should be removed. Eliminate them by eliminating component teams and going to Feature Teams. Feature Teams are well known.
Emphasize Feature Teams and other dependency reducing structures as the target arrangement, rather than leave them to a mass meeting.
Everything needs to be done this way.
Much of the work of any company can be done by single cross-functional teams. No need for mass planning, release trains or much at all of the SAFe mechanism. Maybe SAFe acknowledges this fact, but it certainly doesn't drive toward that situation, nor even recommend that first you slice out everything that doesn't need SAFe and apply SAFe to the rest. On the contrary, "Everyone must be trained in SAFe."
Focus first on removing the need for alignment, and only then worry about aligning what's left.
Program level planning is Big Planning Up Front.
There is a new plan every five iterations, before the next Release Train. In preparation for this, the Program Level Product Managers and the Product Owners from the Team Level work during the current train to make a plan for the next train (the next Potentially Shippable Increment).
All this planning is done with little or no feedback from the developers, as far as I can tell. The assumption seems to be that this plan will be bad and resolved by an all-hands meeting. Ten weeks of feature planning fixed by a two day meeting?
First, pull all possible projects out of the fixed planning and release train cycle. For those that remain, do distributed continuous planning rather than big bang planning.
Top-down feature distribution is the way to go.
SAFe's program level planning assumes that product plans need to be created and coordinated by special designated Product Managers and Product Owners. In fact, the most effective teams we know of involve intense collaboration, not between managers and other managers, but between Product Owners and their teams. SAFe could treat centralized planning as a stopgap and push toward decentralization. It does not.
Teach decentralization and continuous planning and release. Eliminate synchronization where it's not necessary. Provide for it in a remedial fashion where it is.
A two-day all hands meeting can resolve everything we screwed up in the last ten weeks.
It's expected that all hands -- literally all hands -- will attend a two-day meeting where work will be shifted around, dependencies identified, and team plans created for the next ten weeks.
Two days of a hundred or so people meeting will not likely unwind the mistakes that will inevitably be created by the preceding ten weeks of planning without development feedback. SAFe could drive toward continuous planning. Because it is so focused on a long cadence, it does not do so.
Continuous planning for the bulk of the work. Less top-down driving by plans, more by vision and expression of needs.
This isn't going to happen.
When you read the observations and suggestions above, it becomes clear that these things are unlikely to happen. SAFe's strength is that it appeals to large organizations who are not Agile. It confirms that the Big Guys know the stuff and that all that's needed is for the Little Guys to rush around doing what they're told.
SAFe tells corporate dinosaurs that those little mammals downstairs are nothing to worry about. Agile, on the other hand, thinks mammals are the answer.
The SAFe designers and proponents would likely acknowledge many of these concerns. I know that some of them do. And they'll say yes, but inside SAFe there are all these Agile principles and ideas and welcoming of improvement. Once we're inside, Agile can pervade the organization over time, as they learn.
Mmm, yeah. And my body converts my diet of gumdrops and cookies into lean muscle and clean arteries.
Still, I am sure that the creators and proponents of SAFe are not cynical evil people. They sincerely think that their product will help. And it will help, to a degree. I think it could be a better product and help more. I think it could be presented differently and help more. It's up to them to decide what to do. We all get to sell what we want to sell.
But, but, but, we mean well!
Response to these concerns is mostly of these forms:
But, but ... SAFe is better than nothing.
That it is. But it falls short of recommending approaches and practices that are no harder to do and generally thought to be better. SAFe may be better than nothing. It's not as good as it could be.
But, but ... SAFe can't have everything in it.
True, it can't. That being the case, why not have the best things, not second best?
But, but ... People can improve SAFe. We even told them so.
True, they could, and you did. History suggests that, too often, this will not happen. SAFe does not include a well-described ongoing approach to moving beyond SAFe. Because SAFe is so prescriptive, this is sorely needed.
But, but ... Scrum isn't perfect either.
Tu quoque. I'm working on that one, too. SAFe's just a sideline for me.
But, but ... you just don't understand.
I took the course. I read the material. I talk with people using and pushing SAFe. I think hard about this stuff. I'm in the top half percent of IQ. If I'm getting it wrong, and I might be, then a lot of other people probably are as well.
But, but ... Pick your own excuse.
It's still an excuse. There's no good excuse for not being as good as you can be. Of course, none of us is. It's still an excuse.
Bottom Line: SAFe isn't Safe.
SAFe often chooses second- or third-best approaches. Its top-down philosophy pushes against organizations moving beyond it. It has no need to have done so. It would likely sell as well if it were better. I offer these items as things to work on. I'd even help.