Scrum Master in the organization

Question

I'm wondering how to set up the organization with Scrum Masters. I would prefer to see real examples of where the scrum masters are located in the organization's hierarchy and how report-to / chain-of-command issues are handled.

we are service company. We have one agile project done for agile customer where team manager of developers fulfills the role of delivery responsible. So far we had matrix organization where scrum masters were assigned to the project management team consisting of people working for other projects (not agile), but this was causing that they did not have much contact with agile culture in their PM team and goals were not always aligned with project.

How should we structure Scrum Masters within our organization?

Answer 1

In my current company the scrum masters report to our head of product development. They have a desk in one of our team areas, though they are unfortunately responsible for several teams. They spend a good chunk of their time going from team to team rather than working at their desk. Having one scrum master be responsible for 4-5 teams does not work very well at all.

Back when our company was better organized each scrum master worked with only two teams and that seemed to work fairly well.

Answer 2

In our organization (80+ developer, 10 scrum teams), the scrum masters are part of the scrum teams. Scrum masters are responsible for only one team, and are also developer/QA in it's team.

Our scrum masters responsibility is an overall team responsibility, that is keep the team alignment in sync with overall Product Manager alignments. Scrum masters also work as a filter between the PM/outside world and developers, making sure the individual developers can focus on their day to day work, instead of being pestered with all kind of requests. They also have the responsibility of communicating what is going on in the team, and warn about possible delays.

This works fairly well for us, and the scrum masters are also kept free to do a lot of development work, meaning not to much noise towards them either. One of the reasons it works for us though, at least I believe, is that we have a culture where we trust the developers 100%, which means the scrum teams basically runs themselves without much work from PM.