Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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.
I'm unsure where Scrum Mastering finishes. Is the Scrum Master responsible for getting decisions on design discussions? Who is responsible?
If the working agreements within the company state that those two developers need to agree on the design, then it is the responsibility of those two developers to come to an agreement.
If not having the agreement is an impediment to the work being started in a timely manner, then the scrum master may become involved in their capacity as "impediment remover". What the scrum master could do is facilitate and moderate the discussion between the developers in order to get them to agree on a design.
That facilitation could even go as far as inviting a subject-matter expert into the discussion or proposing to run a time-boxed experiment (a spike) on one or more of the proposals.
One thing worth considering is running an experiment.
If you can't reach consensus, then an experiment can help unblock things.
For example:
"Sarah and Bob we haven't been able to reach agreement on an approach. Perhaps we should try an experiment of Sarah's approach? We can then evaluate it after a fixed time. When we evaluate it we will take into consideration the concerns Bob has mentioned in this discussion."
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.
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:
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.
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:
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.
Is the Design in question here is tech design of the solution to be implemented or it is about user experience or it is an Graphical user interface. If the Product owner has approved it as a valid requirement, no matter how bad the design is. Next action is to estimate, prioritize and implement the requirement.
In my opinion, take opinion of both developers and involve them in stories definition and product backlog meeting. Define the rules for valid stories and requirements in product roadmap/backlog with Product Owner. If there is no agreement, have an impediment remover either by having product owner, sponsor or someone to approve the design.
If requirement is clear and story approved, no matter what bad/good design is it goes in product. There is no right/wrong answer in many conditions, one has to weigh the options, do cost-benefit analysis or some other methods to enable decision making. Not necessary one will have agreement in all things - all the time, plan for it!
