How mistreating SAFe limits the Scrum Master’s accountabilities
I gotta get this off my chest. I don’t have anything again scaling Scrum. Scaling any development effort might be a very useful thing to do when it would solve your problem faster, without losing any levels of quality. There are so many different scaling frameworks that have started to divert from Scrum itself, some might say, that accountabilities and such start to fade into something different as well. In this article, I’m discussing this with SAFe as an example. Don’t take this as a bashing of SAFe, just as my observation.
And that’s where my problem lies. I have never experienced a situation where SAFe actually helped an organization get to its desired outcomes faster. One of the things holding organizations with SAFe back is the limited efficacy of their Scrum Masters.
Where a Scrum Master should be working with the entire extended organization of a Scrum Team, I have never experienced a SAFe organization that had Scrum Masters work truly beyond the borders of the Scrum Team. Even when it might be unintended, SAFe tends to instill a sense of hierarchy that just maps existing roles to a fancy new name. Here’s my observation.
Top-down mapping makes top-down hierarchy
Just having a quick look at the framework itself, shows us that the basic approach (maybe subconsciously) displays hierarchy in itself.
For the sake of ease, I took the first mapping of the SAFe framework on their website. Again, I’m not saying Scaled Agile Institute(SAI) means it this way or that has ever been intended that way, I’m just sharing my view on this.
The framework reads like any classic business approach. Organization levels first, management in the middle, and way down low the people doing the work. If you want a change to be very clear and apparent, don’t plot it to a traditional structure.
I feel that just turning this picture upside down and enlarging the portion that Agile Teams take up in the entire framework already would make a large change in interpretation. This is not based on any experiment so far though.
It’s the same thing with Human Resources. We need to treat people like people. In 99 out of 100 cases, your first contact when applying for a job is with… Human Resources. Yet we wonder what makes it so hard to differentiate people from actual resources like a chair, keyboard, or desk.
RTE’s are Super Scrum Masters
What?! Nowhere in the framework is this mentioned. This is, however, my experience. Scrum Master report directly to Release Train Engineers. Scrum Masters are the lesser experienced RTE’s and the latter is the career path for SMs. This creates a barrier between the rest of the organization and the Scrum Masters, as I see stakeholders and management approach RTE/Product Management/System Architect first with any kind of questions, before consulting teams. The effect is either upholding or instilling a bridge between stakeholders and teams.
When reading through the list of accountabilities for RTE’s, most of them could easily be done by Scrum Masters. But the part that strikes me most is this:
SAFe doesn’t prescribe a reporting structure, but the RTE and STE typically report to the development organization or an APMO, which, in SAFe, is considered a part of Lean Portfolio Management. For enterprises with existing PMO organizations, a program manager often plays this role.
What do you think will happen when people read this? “Ah, I guess it’s best practices to have this reporting line”. Teams report to RTEs, RTEs to LPM, and so on. Doesn’t really feel like anything has changed. If you don’t want your kids to burn the place down, don’t give them a blowtorch to play with. Also there I have to add I have never actually run that experiment. Might also be one of the reasons my place didn’t burn down yet.
Scrum Masters are being put into a box
Within that box, they can be as self-organizing as they want, but it’s a very limited box. Let’s revisit what Scrum Masters are supposed to do according to the Scrum Guide:
The Scrum Master serves the organization in several ways, including:
- Leading, training, and coaching the organization in its Scrum adoption;
- Planning and advising Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
- Removing barriers between stakeholders and Scrum Teams.
Now let’s check who is accountable for these in SAFe in practice:
- External agile coaches, the agile core community, the Agile PMO, basically anyone who’s not a Scrum Master teaches, leads and coaches;
- Same for Scrum implementations. As we’re discussing SAFe here, it mostly out of the SMs hands and often external consultancies are brought in to help set up SAFe implementations;
- Stakeholders are directed, or even worse; expected, to go to the Product Manager first. In terminal stages, those requests need to go through the triage (System Architect, PM, RTE), before heading anywhere else. Empiricism dies a slow and painful death. Helping employees enact an empirical approach by the SM will raise eyebrows within the new SAFe environment;
- Removing barriers is actually a lot harder now as there is a new excuse; “we’re doing SAFe now, so we have a new process. Before a barrier is removed, three new ones will arise.
As you might understand, Scrum Masters are forced to not go beyond the realm of teams.
Complexity is not lowered with more complexity
The Scrum framework is made easy to understand with a reason; to remove all the fuss and bring back the focus on its purpose: deliver value. The framework with its accountabilities, events, artifacts, and commitments is basically stripped clean of anything unnecessary.
See, fairly easy to understand. Yet people and organizations already struggle to reap the full benefits and employ this little framework as it is intended. Let’s take the extreme example of the Full SAFe layout.
Now, while we already struggle doing Scrum right, let’s introduce a million other things that will bring back all the fuss Scrum intended to remove to make things a lot harder again.
What I experienced out in the field, is that this raises thus much confusion and questions, and the benefits SAFe wants to provide, are rarely met.
Think before you act
The same thought pattern I see coming back over and over again; we skip out on the question what is our problem really? Making this step 1 and only when having a proper understanding of that, moving on to what might be the best solution. I am absolutely convinced that 7 out of 10 scaling efforts are made more complex than they should be.
As I described in this article, Scrum Masters are swimming against the current. Hands tied behind their backs. I’m sincerely hoping you’re having a better experience than I am and I’d love to learn about it. But don’t underestimate the effect this practice has on trust and empiricism. Be better.
