Hcfyk

One of the main roles for a Scrum Master is to remove impediments for the team, such that the development can progress.

This is, in my undertanding, to ensure that the development team can focus on where they excel - development. This way much of the red-tape (*ahem*, meetings, *ahem*) that slows down development should, as I understand, be dealt by the Scrum Master.*

Still, let's assume a scenario where mid development, the team is blocked because requires a design decision from an external architect. The lack of this decision is blocking the progress on this task. At this stage, I see two options:

• The Scrum Master understands the problem and discuss the options (potentially suggested by the engineers) and discuss aspects with the architects


• The Scrum Master acknowledges the blocker and points the engineers to discuss with the architects

I believe that a Scrum Master can only truly remove impediments (and thus, becoming a proper Scrum Master) by having such background, but I failed to find evidences that this assumption is correct. Am I missing something?

* ps.: I appreciate a meeting is in most of the cases a a byproduct of other underlying problems, such as poor refinement, poor planning. Consider this as a (joking) example but please don't focus too much on it.

Am I missing something?

I think you are missing the main point of "impediment", that is a blocker that the team is not equipped to handle themselves. The Scrum Master is not supposed to be a better developer than the developers or a better architect than the architect.

The Scrum Master's job is to make sure the architecture decision is made. By lobbying for more time for the architect to come to a solution. Or by creating an environment (read moderated meeting) so the developers and architect can talk.

The Scrum Master has no benefit from a background as a developer apart from better communication due to common terms used.

My personal opinion is that it might even benefit from not having too much development knowledge, because we all know that a programmer cannot just walk away from a programming problem without trying to think about a solution. I prefer a Scrum Master that will walk away from programming problems and leave them to the programmers and does their own job properly instead.

TL;DR

While domain knowledge is always useful, the Scrum Master is not expected to be a domain expert beyond the Scrum framework and organizational processes. Scrum framework expertise is essential to being a facilitator and process referee. Organizational process expertise is essential to facilitating the team's progress in the face of organizational or process impediments.

Interpreting the "Remove Impediments" Guidance

The Scrum Guide entry for the Scrum Master role actually says:

Removing impediments to the Development Team’s progress

In my experience, this is often misunderstood. The Scrum Master isn't really responsible for solving the problem directly; rather, he or she leverages the Scrum Master's roles as facilitator and process referee to address the various impediments to progress that the team is facing.

Another way to say this is that the Scrum Master enables the team to be self-organizing, identify process impediments, and support the team's efforts to address those impediments. This isn't really a "momma bear taking care of her cubs" task. It's more of a coaching and facilitation task.

How This Applies to Your Example

[T]he team is blocked because requires a design decision from an external architect. The lack of this decision is blocking the progress on this task. At this stage, I see two options:

• The Scrum Master understands the problem and discuss the options (potentially suggested by the engineers) and discuss aspects with the architects


• The Scrum Master acknowledges the blocker and points the engineers to discuss with the architects

Neither one of these options is ideal. In the first option, the Scrum Master is acting alone, rather than facilitating, coaching, or empowering the Development Team. In the second, the Scrum Master is taking a hands-off approach rather than facilitating the discussion.

In the real world, both of these are actually viable. I wouldn't dismiss either of them out of hand in all contexts. However, a more framework-appropriate solution is generally to address the process issues, and to facilitate learning and self-actualization within the team. For example, I'd suggest the following:

1. The Scrum Master involves the team in identifying the blockers (in this case, the need for an external design decision).


2. 
   

   The Scrum Master involves the team in identifying solutions at both the process level (during the Sprint Retrospective) and at the immediate blocker level.

   
   
   

   This two-level approach is critical. Even if the team gets the design decision approved or resolved this time around, the fact that the team is dependent on external resources is a fundamental process problem that should be addressed by the Scrum Team with organizational management, and should be taken into account during Sprint Planning and Backlog Refinement.

   
   


3. 
   

   The Scrum Master facilitates a meeting between the Development Team and the architect.

   
   
   
   
   
   • "Facilitate" may mean coordinating the meeting, or simply pointing the Development Team to the resource they need to collaborate with.
   
   
   • "Facilitate" also means being present at the meeting, to ensure that there's a meeting referee and to gently steer the meeting towards a productive outcome.
   
   
   • "Facilitate" may also mean knowing the paths of escalation, should that be necessary.
   
   
   
   



4. The Scrum Master works with the organization to escalate issues that the Scrum Team can't resolve.



5. The Scrum Master works with the Product Owner to facilitate whole-team discussions about early termination when the Sprint Goal is at risk because of a blocker.

As you can see, at each step the Scrum Master is facilitating the Development or Scrum Team's actions, rather than simply handling it directly. As a member of the Scrum Team, it may be appropriate for the Scrum Master to perform tasks on behalf of the Development Team in some circumstances, but care must be taken to place the power into the hands of the whole team rather than the role of Scrum Master.

Conclusion

There's definitely a lot of things a Scrum Master can and should do to help the team. However, it's rarely beneficial for the Scrum Master to take either a hands-off approach or take unilateral action. The former isn't terribly helpful to less-mature teams, and the latter doesn't provide any learning or growth opportunities for the Development Team.

As a general rule, I'd extend the Scrum Master's core role as a facilitator and process referee to the task of removing impediments. Support the Scrum Team's efforts to solve its own problems by giving them the tools to do it, and then support them through that effort. That's the best way I know to help teams grow in maturity and process efficiency!