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?

  • 1
    Does this answer your question? Who is responsible for getting developers in the same team to work together? Commented Oct 21, 2022 at 7:42
  • No it doesn't. I asked 2 different questions because they are 2 different scenarios. Would HR get involved in software design issues? Commented Oct 21, 2022 at 7:53
  • 2
    @learnerplates First, please ask one "question" per question. That (should be) addressed in our help section. If not, please bring that up on meta. Asking multiple questions at once muddies the waters and makes it harder to provide canonical answers.
    – Todd A. Jacobs
    Commented Oct 23, 2022 at 22:20
  • 2
    @learnerplates TL;DR: Focus and context matter; you might need more in future questions. Unless you provide sufficient details about your organizational structure and use good markup to make your core question clear, some answers may be answering parts of the question that are less important than the parts you really care about. None of this is meant as criticism; you're asking a good question here and I just want to help your future contributions be even stronger and lead to better answers for you and other visitors.
    – Todd A. Jacobs
    Commented Oct 23, 2022 at 22:22

4 Answers 4


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.

  • I like it. There are no working agreements or even culture guidelines in the org. View it as an impediment like any other is a good idea. This particular case was not known at the time by any scrum master but senior manager was informed somehow. I wonder what the manager should have done when they were informed Commented Oct 21, 2022 at 8:06
  • 1
    @learnerplates, it should not matter through which way you learn about the existence of an impediment. Commented Oct 21, 2022 at 8:10
  • 2
    That facilitation might go as far as inviting another subject-matter expert, if you have one. With the agreement of both of the developers, of course. Commented Oct 21, 2022 at 8:39

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."

  • 2
    I think a story spike is a good idea, and may solve the immediate problem. I just think that there's a larger underlying issue. That said, your succinct answer may be what's needed to get past the immediate problem without having to address the larger dysfunction right away.
    – Todd A. Jacobs
    Commented Oct 23, 2022 at 22:14


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:

  1. Don't have good organizational structure.
  2. Don't understand the Scrum framework or its roles.
  3. 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:

  1. 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.

  2. If the design work is irrelevant, push back on extending your scope of responsibility that far outside the Scrum Team.

  3. 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.
  4. 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.

  • 1
    I completely missed the "not one of my teams" in the question! You're absolutely right to highlight that. Commented Oct 23, 2022 at 12:18

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!

  1. Product owner to take decision on what goes in product backlog
  2. Validate the backlog with SCRUM team in backlog refinement meeting
  3. validated stories with prioritization are putten into sprints
  4. Stories completed and verified
  5. Reviewed with release in spring review
  6. take reviews/feedback in Sprint retrospective meeting
  7. repeat
  • 1
    I sort of agree with a lot of what you've said, but implementation is a decision for the Developers, not for anyone outside the Scrum Team.
    – Todd A. Jacobs
    Commented Oct 23, 2022 at 22:13
  • In my opinion, it's sole responsibility of 'Product Owner', and he is part of the Scrum team. Others contribute but 'make it or break it' is owned by Product ownner/Manager only... But yes, its debatable. User Experience, Test, Dev, DevOPs, Scrum master, Product owner - you can't have everyone agreeing to everything everytime.
    – Aditya
    Commented Oct 25, 2022 at 17:39
  • 1
    The Product Owner is responsible for "what" through the Product Backlog. The Developers are responsible for "how" as they see fit and document within the Sprint Backlog. This distinction is spelled out pretty well in the 2020 Scrum Guide.
    – Todd A. Jacobs
    Commented Oct 25, 2022 at 17:55
  • glad I posted this comment then, I need to educate myself more. :)
    – Aditya
    Commented Oct 26, 2022 at 9:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.