Should a "Delivery Manager" be allowed to participate in retrospectives.
After adopting a "customized" version of SAFe, the company I work for has eliminated all but 10 scrum masters from an IT organization with over 80 teams. Instead, most teams now have a "Delivery Manager".
According to HR's description of the role, it appears to be a flexible role based on the responsibilities of a typical HR line manager but with a list of conditional responsibilities depending on what kind of team is being managed. For development teams, the expectation is that those responsibilities include those of a scrum master.
I know this is frowned upon for a variety of reasons but it is what it is. The decision was handed down from the C-Suite so there's little point in a software developer arguing with the CTO.
I'm more concerned with working with/around the system as it currently exists, which brings me to my main question: Given that the SM is usually the facilitator of retrospectives but HR managers participating in retros is considered an anti-pattern, what should be done when both are the same person?
If it helps to give context, the other scrum events all suffer from the exact sort of disfunction you would expect from an HR manager's participation.
The retro doesn't appear to be on the delivery manager's agenda so I was planning on scheduling it without his involvement but I wanted to get some feedback first.
Why not ask senior executives for their advice on this, since they appear to be the fount of organizational wisdom concerning how agile practices ought to be applied?
Your own immediate responsibility may be towards transparency. You should make it clear that Scrum is not being implemented. The misuse of Scrum terminology usually leads to confusion, and disappointment when expected outcomes are not achieved.
The retro doesn't appear to be on the delivery manager's agenda
In lieu of this, perhaps a relevant question to the Delivery Manager is what their plan for improvement is?
And as Ian noted, Scrum is certainly not being practiced if the Scrum Team is not being presented with an opportunity to inspect and adapt. That should be made as transparent as possible to all relevant parties.
Tough situation, and I agree with Ian and Timothy's comments.
You might also try casually bringing up the topic of "continuous improvement" with anyone who will listen (developers as well as these new managers). Inspecting and adapting is supposed to be a key part of SAFe anyway (although it tends to get pushed to the end of a long iteration), so the more you can enlist people in the mindset of continuous improvement, the more you can get people asking, "Well, how do we do that?" To which you have a ready answer in the time-honored Sprint Retrospective. It may be that the more you imply that "Everyone knows it's something we *should* be doing" while offering the tools and facilitation skills to get it up and running, the more the managers will feel obligated to work it in (or perhaps some cheeky developers will take up the cause).
You could also come up with a mental list of responses to common concerns about the retro, e.g., "We don't have time for that!" (You don't have time to NOT retrospect and improve!)
Or maybe it's finding ways to get some teams to start going out for lunch every other Friday or just take a coffee break together -- anything to facilitate the psychological safety and openness that form the basis for retrospectives.
With eighty teams I'm sure the success rate will depend heavily on the personality of these delivery managers and which ones you can engage. Based purely on human nature, I'm sure some managers will indeed take a command & control approach that will prevent openness or effective retrospecting. Maybe start with the other Scrum Masters and try to build a coalition of Scrum Masters, then open-minded delivery managers, then developers and even leadership who understand the value of continuous improvement and are looking for ways to build that sort of culture. Maybe it starts with just a single team where a sprint retrospective takes root, and they can be a model for other teams, and so on. Culture change doesn't happen overnight.