Interview answers for a Scrum Master applying to a SAFe org

Question

I've noticed interviewers in SAFe organisations ask different questions. I'm guessing that they also want different answers to the Agile and Scrum type of answers e.g. "help the team figure it out".

e.g. What do you do when an item is not going to be delivered in the sprint? In Scrum the answer might be; tell the PO of the risk, inform the Stakeholders, identify impediments and resolve. In SAFe I'm betting that the answer could be different, but what is it? I'm feeling that it's more of a managerial answer like, get the team to double down and get the item to done..........

Answer 1

Disclaimer: I believe this question is borderline ontopic for PM.SE, as it's strongly oriented towards career recommendation.

Scaled work need scaled alignment

When a company needs to scale, it does so because of a problem to be addressed. You have to understand the scaled process in use to understand what are the differences and the motivations behind it to have a proper answer.

In your example you mention SAFe, and in this case the expectation is potentially to have this reported at SoS (Scrum of Scrums) meeting so that other teams that may depend on your work will be advised and then react accordingly.

Answer 2

When Impact is Limited to the Agile Team

Whether or not you like SAFe, it's no different than any other scaled Scrum implementation from the perspective of the Agile Team (they are not actually "Scrum" Teams). You have to ask yourself the same basic questions:

1. Does the work item affect the iteration's current goal?
2. Does the work item affect the Program Increment's goal?
3. If it's essential, do you have sufficient slack in the remaining iterations within the Program Increment to get it done in a different iteration?
4. Will failure to deliver the work item this iteration impact dependencies for your team or other teams during the next PI iteration, or the overall deliverable for the Program Increment?

If it doesn't affect anyone outside your team, it's up to the Agile Team to decide what to do with it. However, if the work item is a dependency for another Agile Team, then at the very least the Release Train Engineer ought to be consulted.

Dependency Mapping in SAFe

One artifact of PI Planning is the dependency board that visualizes the dependencies between Agile Teams and PI iterations. Here's an example taken directly from the online documentation:

If you're trying to mentally map this to Scrum, the only real difference is that you aren't committing to a single Sprint Goal at the end of a single Sprint. You're collaborating across four iterations and multiple Agile Teams to deliver a coherent Program Increment. So, you always need to consider the coordination between Agile Teams and the impact across the Agile Release Train when something slips.

Coordinated decision-making like this doesn't have a simple answer, so your best bet is to keep the Release Train Engineer informed, and then involve other teams and stakeholders as necessary if the issue is actually material. If "embiggening the widget" isn't really critical path for the PI, then the Product Owner and the rest of the Agile Team can address it without involving the whole ART.

Keep Transparency in Mind and Perspective

Just remember that one of the pillars of agility is transparency, so the goal here isn't to sweep anything under the rug. The team should just ensure that the incomplete work item actually matters to the Program Increment or other Agile Teams before going to DEFCON 1 over a minor non-event.

So, discuss within the Agile Team. Escalate to the Scrum of Scrums, Release Train Engineer, and other stakeholders as needed if there's a genuine problem with PI-level impact. At that point, it's a Release Train issue rather than just an Agile Team issue, so the whole ART needs to be part of the inspect-and-adapt process of determining the best way to proceed under the circumstances.