When I start working with a team, all impediments popping up are circling around the questions of what Scrum is, how it works and how it can be applied in the specific contexts encountered. For example, a distributed team might ask the question of how to conduct an efficient Daily Scrum. The questions vary, but they are always similar. They form the "base" of the pyramid.
Often starting simultaneously, I as a Scrum Master have to forge a Team out of individuals. So while learning Scrum, they also learn to trust each other and to act responsibly as a team. This team level stuff forms the 2nd layer of impediments.
Once the team is working together reasonably well and has understood Scrum, impediments often shift towards technology. Questions like, "Hey, we want to deliver every two weeks, but we do not have automated regression tests" or, "we need continuous integration facilities if we want to work together with these other teams" are usually coming up then. While I personally don't have a clue how to set these up, I still can coach the team to manage this themselves or escalate it throughout the organization. This is the third level of the pyramid and the first level visibly reaching out to other parts of the organization.
Once technology works well, the impediment focus shifts toward adjacent teams / functions / departments. Basically, the team now can truly deliver "Done" product every Sprint but the rest of the organization can't. So while the Development Team delivers every two weeks, requirements might take eight weeks to reach the team and QA might need another six weeks to put something into production. Understandably, the Dev Team then starts to ask why they should deliver so frequently if the others don't - and good Product Owners ask why the realization of value is deferred that long. So at this level the Scrum Master starts to work along the value chain of creating the product (usually something along the lines of ideation - innovation - requirements elicitation - Product Backlog refinement - product creation (usually already fixed at this point) - quality assurance (if it still has elements separated from product creation) - integration (with several teams or big products) - releasing). Individual cases vary of course, but this is roughly how it works.
Once the whole value chain is optimized, usually other process issues, affecting the whole organization, are hurting. Most often budgeting, career paths, compensation, portfolio management, etc. are focused on. Here, the Scrum Master has to fully act as a change agent throughout the whole organization.
Certainly no impediment is "solved" by the sole competence of the Scrum Master. Instead, he/she coaches the involved and affected parties to find their own solutions and to inspect these regularly. These parties change naturally when moving up through the pyramid of impediments. An excellent Scrum Master can handle them all. If you don't have one, use a team of Scrum Masters with different skills (maybe you have one team forming expert and one change agent working hand-in-hand while facilitating their respective Scrum Teams and influencing the organization...) to supplement each other. Be aware that all "levels" of the pyramid will stay relevant throughout the whole lifecycle of your product/team and one will often "fall back" on a lower level for a time. This is normal. Of course you cannot work on the organizational level if the team is back to "storming" again - you then have to address this impediment first. However, the time being spent on higher level issues increases with time and the maturity of the team.
While all models are wrong, some are helpful. Maybe this one supports you when you are looking for a Scrum Master, evaluating your Scrum implementation or being asked, what the "Scrum Master does all day".
