Whom does the Scrum Master respond/report to?

I was taken aback by a simple question: "So whom does the SM respond to?". That sounded a bit like "who is the SM line manager"

My answer would be the CEO.

Also, that raise the question of how to measure the success of an SM?

Could the measurement of organizational change, for which a CEO is ultimately accountable, be involved?

I really like @Ian's answer and would love to see that happen but so far I haven't.  If @Ian, you have I am VERY jealous. 

"who is the SM line manager"

In the places I have been, the Scrum Masters usually report to a SM Manager just like Devs report to a Dev Manager. Old style hierarchy is hard to remove organizations.  Who the SM Manager reports to is usually the person who is responsible for project management. In a lot of cases that was the person who managed the PMO prior to introducing Scrum. 

When my current company decided to transition to Scrum from waterfall, I was the person here with the most experience. When they asked me how to do it, I suggested that the SMs report into the Head of Human Resources.  If you look at the jobs we do, it aligns better with HR than it does anywhere else.  

Also, that raise the question of how to measure the success of an SM?

The success of a SM is based on the success of the Scrum Team.  I would suggest that most organizations have some way of measuring the success of HR staff or managers that are responsible for team development.  Those measures could also be applied to SMs.  SMs do influence more than just their teams so the measurement should also be extended to how the team's efforts are increasing efficiency of their stakeholders, especially if those stakeholders are internal.  If they are external, you may have to resort to customer surveys to get input. 

But again, I REALLY REALLY like @Ian's answer.  

You and me both, Daniel.

However, I'm afraid that's the ideal scenario. SMs report to roles such as CTO, Head of Product, PMO, Project Manager, Product Manager, Program Director, Software Development Manager, and so on.

The PO is measured by the product performance on the market, the DEVs are measured by the built in quality, their velocity, but what is a good metric for the SM? 

Be very careful with using velocity as a gauge of Development Team performance.   Quality is a great Development Team metric, throughput/velocity not so much.   A Dev Team can increase the amount of "stuff" they're delivering, but is it truly meaningful, or is it just more "stuff"?

I find both the CEO and HR ideas interesting, because it shows the change can't be "owned" by a person (thought as Ian said, the CEO is responsible of it). For me change is a state of mind and a company culture.

In a previous product I was working on, it was a small company (<100 people, with a team of 10 developers), so I responded directly to the CTO. Old state of mind being ("we in hierachy are better than the rest of you, little developers"), I couldn't reach higher to the CFO or the CEO. The way it worked was simple : CTO asked me how it worked, I answerd, and if storm came from hierarchy, I took it on me to protect the team.

Today, I work with a large organization, and I change the way I report. I simply report to whoever I want to, or whover ask me to. There is a lot of different manager (sometimes more managers than actual developers), so if I just choose who is relevant for what, and it seems to work fine.

So, my vision is, as the different opinions seems to show, just choose who to report. It doesn't have to be one person, it depends on what you report.

 the DEVs are measured by the built in quality, their velocity, but what is a good metric for the SM

I'm sorry but anyone that uses velocity to gauge success has no idea what velocity actually is. Velocity is just a planning metric, that is it, it should never be used for anything else. If you want to say a team is graded on their CONSISTENT velocity, that is different, but far too many companies use velocity to determine success; higher velocity equals a higher performing/more successful team. Just NO.

As far as who the SM reports to, that depends on the organization. There is nothing that prescribes who the SM should report to. In smaller organizations, the SM very well could report to the CEO. In larger orgs, that is highly unlikely. The SM's at my current org report to the SM Managers. Others have reported to the PMO office. It just depends on the organization.

Lastly, how to determine the success of a SM. That's a loaded question. In my opinion, there are many different areas that you have to consider. The maturity level of the team. How is the knowledge of scrum and agile within the team; the SM is the coach after all. How well does the team work together; the SM needs to be facilitating teamwork. How does the team handle conflict; the SM is also building relationships between team members which should result in the team's ability to respectfully give and receive feedback and work through conflict. How much does the team need the SM; the ultimate goal of a SM is to work themselves out of a job by coaching their teams on self-organization.

The success of a SM is based on the success of the Scrum Team.

@Daniel Wilhite, I've experienced situations where the scrum team can make it look like a SM is not successful. I say this because, SM's don't have any authority over the scrum team and anything proposed is met with opposition. When an organization goes through a weak change exacerbated by weak/misunderstood knowledge of scrum the best scrum masters can often take a backseat. Shouldn't we as a community therefore taking caution in gauging a SM's success based on the scrum team? though in an ideal scenario, what you said is correct, i.e. you have a motivated set of individuals (scrum team).

I have always reported to a QA Manager or Development Manager.  In all cases, the management teams were on-board with our transition to the scrum framework and wanted the teams to be more successful.  There was never an issue with my reporting structure. 

@Steve, you are absolutely correct and unfortunately I have been the SM you are describing. But in that case I was lucky enough to be given an opportunity to defend myself (yeah not scrum at all but I wasn't about to say no). I was able to show how the work I had done coaching the team had provided benefit and illustrate that there was still a lot of work to be done. I was also able to show how outside "forces" continued to change and I was actually spending more time trying to protect the team than I was able to spend helping the team. 

I did state an ideal situation. But I do point out this statement

I would suggest that most organizations have some way of measuring the success of HR staff or managers that are responsible for team development.

That assumption is made and would apply to the SM as well.  Is an HR Recruiter held accountable if there is a large attrition rate? No, they are held accountable for the impact they have to minimize the problems that occur from that attrition. Is a Staff Manager held accountable for a staff member that is comfortable with their current career status and doesn't want to invest in their own career development?  No, because you can't force that.  But the Manager would be held accountable for ensuring that individual's abilities are being utilized in ways that best provide benefit to the company.  So, can a non-performing team make a SM look bad?  Sure.  But if that SM is doing their best and some benefit can be seen from their interactions with the team, then I would call that a moderately successful SM. Maybe not extremely successful but I wouldn't say that the SM failed either. 

I am eager to see response from Ian saying in how many organizations he has seen that scrum master is reporting to CEO directly ? Say that we are talking about organization having few hundred of employees in R&D department.

I am eager to see response from Ian saying in how many organizations he has seen that scrum master is reporting to CEO directly ? Say that we are talking about organization having few hundred of employees in R&D department.

A direct, accessible relationship between CEO and Scrum Master is something I always coach. It is possible to manage the relationship by exception. The degree to which an organization actually changes to support such a quality of professional empowerment is another matter. Some are further along than others. None that I have seen, of the size you indicate and with a separate department for R&D, have ever done it well.

Thank you for this answer. Can we say that scrum is not working in big organization ? From our agile guru I received following information "SCRUM started aiming at Single customer, single project and single co-located team as the basis". I also received links: 

Some such example frameworks are SAFe (https://www.scaledagileframework.com/) , LeSS (https://less.works/), Nexus (https://www.scrum.org/resources/nexus-guide)

I had no time to read them yet. Does it mean that we are using ScrumBut ? This shortcut I understand as excuses for not using scrum. I prefer to use ButScrum, which put focus on good think which is scrum.

I have problem with openess within the team, but for this I will ask next question.

Can we say that scrum is not working in big organization?

How did you get here? Scrum can potentially work in any setup. If a large organization has lots of small products, they may use individual scrum teams (1-2 per product). If however, they've got huge products, scaling may (will?) be required, so Nexus may be considered when several teams are needed to work on a product.

From our agile guru I received following information "SCRUM started aiming at Single customer, single project and single co-located team as the basis"

Two topics here. 

First, don't be impressed or intimidated by "gurus", whether self proclaimed or not. I'm usually bemused when seeing descriptions such as "Serial Entrepreneur", "Ajax Ninja", "Scrum Visionary", "Agile Evangelist", "DevOps Sensei", "Lean Guru", etc.

Second, I'd say his interpretation is incorrect, and here's why:

• I don't recall ever reading or hearing any restriction in terms of to what/whom Scrum's aimed at.
• Scrum covers products, not projects
• There is no such thing as a "basis": The framework is very simple: from your reading of the Scrum Guide, would you say there are restrictions in terms of a single team? A colocated team? A single "project"?

We have 5 teams working on one product. We started working in this configuration this year. However the product is few years old and it has components which are even 20 years old - inherited from other companies, projects, departments. Ian said "None that I have seen, of the size you indicate and with a separate department for R&D, have ever done it well". From this I concluded that in big organization scrum is not doing well.

I will meet this "guru", "ninja" or "yoda" :) :) in March. I can share my thoughts here after that meeting. However I do not want to say too much. If I criticize too much my organization, I may be first be sure that I will find the other job.

Good to hear that scrum is good for everything. The problem is that not all my colleagues share my enthusiasm for scrum. I can announce them "good news about scrum". Still there is no guarantee that they convert. My managers are saying that it is OK to have three standups per week. I was the only one in the team who wanted daily standups.

Marek, I can see your intentions are good (noble even). May I suggest that, when proposing a change you point out how current status is detrimental given a series of factors, and why switching would bring benefits by addressing the issues? That is, perform an analysis, point out the flaws and give examples, then show why the change would help alleviate the troubles.

Let others see the data (analysis) and engage in a conversation. 

Don't try to force change. People will fight back and they'll likely win and you've just lost momentum (and initiative). Rather, try to find "allies" and go slowly, one step at a time. Remember change is an ongoing process that needs..... you guessed right... time. How much time? That's another topic :)

"Let others see the data (analysis) and engage in a conversation."

More like lots of conversations :) 

Scrum has had success at my current company.  We currently have 13 Scrum Teams working on approximately 5 products.  The thing that helps us is that even though we are working in the same products, each team is working on completely separate initiatives so that the coordination is minimal.  So, yes Scrum can work in large organizations.  And yes Scrum does need scaling at times as evident by the creation of Nexus by Ken Schwaber. 

As @Eugene said the more conversations that occur based on empirical evidence the better your organization will be at determining what/how to do.  And it helps others appreciate Scrum more as they learn more about it.