Recently a heated discussion happened between 2 senior developers. The 2 could not agree on a design. This resulted in work not beginning. I as a Scrum Master was not involved and it was not one of my teams however it was mentioned to me by a senior manager that it is something that Scrum Masters should be fixing.
You should not get involved with this at all unless the design discussion has some sort of impact on your Scrum Team or the Product Backlog. If it's unrelated to your team or its work, then it's out of scope for a Scrum Master.
However, if the work is related to the Scrum Team you're on, or the design discussion is an externality that impacts the work for the current Sprint or items on the Product Backlog, then an argument could be made that this is a process problem for the Scrum Team (of which the Scrum Master is one part) to collectively address.
When Unrelated to the Scrum Team
The Scrum Master is not the organization's therapist. You are not Deanna Troi, you are not the ship's counselor, and you are not responsible for fixing dysfunctions in other teams. If the problem is not one that impacts the team, the fact that your senior leadership wants to make it your problem may indicate that they:
- Don't have good organizational structure.
- Don't understand the Scrum framework or its roles.
- Don't have a handle on their own responsibilities as leaders.
Part of the job of the Scrum Master is to ensure that everyone in the organization is playing by the same rules when dealing with the Scrum Team. The Product Owner has some responsibilities in this regard too, but the role of referee or coach is primarily owned by the Scrum Master. So, if you're being told that you're supposed to fix problems unrelated to the Scrum Team or the project the Scrum Team is working on, you need to communicate with and educate senior leadership on where those boundaries are.
When Design Issues Are Related to a Scrum Project
First of all, the fact that "design" is not part of the cross-functional Scrum Team should be a red flag. While there are sometimes cases where resources lie outside the Scrum Team, this is never optimal.
If the "design" (whatever that means here) is more in the nature of a requirement, then it's really the Product Owner's role to ensure that the right stakeholders are involved so that the design can be turned into a Product Backlog item for the Scrum Team.
On the other hand, if the "design" is an implementation decision about something the Scrum Team is supposed to deliver, the decision should not rest outside the Scrum Team at all. The Product Backlog contains what should be delivered, and the Sprint Backlog for the current Sprint is defined by the Developers during Sprint Planning.
That means how the Developers decide to deliver the what is up to them, not to external third parties. The fact that this isn't what's happening should be another red flag that something is severely dysfunctional within the Scrum process or the organization.
Here's what you should do, in prioritized order:
Determine whether or not this "design" work is relevant to the project. Pull in the Product Owner and Developers if this isn't a self-evident answer.
If the design work is irrelevant, push back on extending your scope of responsibility that far outside the Scrum Team.
If the design work is relevant, then you should either:
- Get the Product Owner to work with the relevant stakeholders to get a consensus.
- Involve the whole Scrum Team in identifying why design decisions aren't being managed by the Scrum Team itself. That means:
- Define a plan as a team, which may include you facilitating a discussion between all the involved parties rather than just the two external developers.
- Discuss all the relevant process issues around this dysfunction during your next Sprint Retrospective, or (if warranted) ask the Product Owner to declare an early termination to the Sprint if the Sprint Goal is blocked. The later clearly communicates the cost of not properly addressing this dysfunction to the organization.
- Communicate the Scrum Team's process issues to your leadership team, along with whatever solutions the Scrum Team feels would be a good next step to try to resolve the issue.
Ensure that you work with the Scrum Team and senior management to get all the resources you need within the Scrum Team.
If that means moving design into the Scrum Team, changing how design is done, or hiring an agile coach to assist with the bigger organizational challenges are all viable options. Only your company can really tell what's appropriate here, but the current process is clearly broken.
In short, you need to stop thinking about whether this is your problem or not. You need to think about if and how this issue impacts the Scrum Team (asking them is a good start) and the broader organization.
Either way, it's not your problem to solve alone, so don't try. That way lies madness, and responsibility without authority. Don't do that to yourself, or allow it to be done to the Scrum Team.