I'm the scrum master in my company (200+ people, several departments) and recently the head of product became my line manager. While this came rather surprising for me and feels kind of wrong, since he's pushing his own agenda into the process quite heavily, I also have no clear idea as to what department a scrum master is supposed to belong to.

In a recent discussion with our (new) head of HR, I realized that a lot of my goals and methods (at least with regards to people and team development) are 100% overlap with HR's, so I guess being 'lined' into HR might make sense. It would also make for a nice separation of concerns in my mind, as HR does not have any direct agendas when it comes to product work.

Background: I was initially hired as a software dev and only recently took on the new roll, so for the higher-ups it made sense to not structure me into dev anymore and I don't disagree with that.

  • 1
    To clarify: My biggest concern is somebody 'pulling rank' on the scrum master or trying to pressure them with other means (denying leave, raises, etc.).
    – CMW
    Aug 4, 2015 at 14:32
  • That's a very interesting question. Upvoted, Mar 30, 2017 at 10:35

9 Answers 9


Barring a "process" organization then SpoonerNZ's reply is the one I would also go with.

This is the same challenge project/ program management has faced for years. TO be able to be effective at your job, a scrum master needs to be able to talk truth to power, problems and roadblocks. They need to be able to look at the entire picture and see how it all fits or doesn't fit. This is not unlike how project mangers need to operate (I've been a project manager, scrum master and agile coach).

Having a program/project office that reports to the top of engineering (CTO, VP, etc.) is generally the best place overall. You are still part of the org that is "doing" and separated enough from the day to day politics that can impede good scrum master or project work.


Seeing as your question asks 'ideally' I would say 'Product Development', along with the rest of the development team and product owner. Realistically, this isn't a department that exists in most organisations and would probably only work on a smaller scale.

This is very much dependent on the organisational structure, but I think a Scrum Master should sit under the 'Technology' or 'IT' umbrella, rather than HR. Depending on the size and structure of the company, this could be under a head of development (if that is all there is) or a Head of Process, if there is also a Head of Dev and Head of Test.

I'm not quite sure what 'product' represents in your organisation, but if people have a good understanding of agile and product development means making a good product, rather than cramming more features; it could be the right place.

Where do the developers sit - in 'Product'? A scrum master is an inherently technical role and developers (and their managers, one would presume) are the people you will be working with. A lot of the challenges I have faced as a Scrum Master would be fairly meaningless if I tried to discuss them with a manager in HR, while a technical manager (in my case the CTO, in my last role in a larger organisation Head of Development) has a fairly good understanding.

Interaction with HR is important from a people/relationship point of view, but you could argue the same with any 'Manager' role - it doesn't mean managers should belong in HR. As an aside, I am not saying a scrum master is a manager, but does face similar challenges around people, motivation etc.

Also, you say

as HR does not have any direct agendas when it comes to product work

A Scrum Master does have an agenda when it comes to product work - you want the team to be effective, not just 'happy'. As I am sure you know, productive doesn't just mean more features, so the agenda is different from that of a more sales oriented Product Manager, but still aligns with Product Development - this is very different from the objectives of HR.

  • It so happens that our dev (including 'IT') team and product management team are grouped together into a 'Product Development' department. My point with HR was, that nobody 'above' me in HR would have any reason to 'pull rank' to override me, or pressure me into forcing their agendas. That's my main concern. I will add this to my question.
    – CMW
    Aug 4, 2015 at 14:30
  • 2
    After you have edited your question and added this comment, it sounds like your biggest fear is a bad manager. These can exist, no matter what department you are in. Certainly in my experience (in UK and NZ cultures) I've always been able to educate higher-ups into agreeing with, or at least allowing my actions - at my current role the biggest challenge to overcome was the CEO who was the 'just build more features' type guy!
    – SpoonerNZ
    Aug 4, 2015 at 19:11
  • +100 for the "Product Development" dept. I hope to live to see companies who have "Foobar Bazulator 5000" departments centered end to end around product lines.
    – RubberDuck
    Mar 30, 2017 at 10:08

Although, that right answer to question 'Scrum Master is a "management" position' is 'true' [because he manages the Scrum process], his job title may not be "manager".

According to Scrum Guide Scrum Master should:

remove impediments to the Development Team’s progress.


lead the organization in its Scrum adoption.

Scrum Master must have enough authority in organization for these activities.

It could be:

  • Formal authority, that you get according with job title. Which department can provide position with such requirements, depends only from your organization.

    It cannot be software development department in all cases. In organizations, main business of which is not related with software (banks, for example), software development department cannot be driver of changes and cannot provide ideal position for Scrum Master. HR? I don't know, I've never seen HR with enough power to change organization for Scrum.

    Also (obviously) this position should not have a lot external responsibilities (which are not related with Scrum-Mastering). Otherwise you will have no time to do Scrum-Master job.

  • Informal authority. In this case job title [and department] doesn't matter at all.

    Imagine extreme case, when your company invite Ken Schwaber (and Jeff Sutherland) to be Scrum-Master. He doesn't need any formal powers, because he has great informal authority.

  • I absolutely agree that, when it comes to authority to remove impediments, having a management title is beneficial to say the least. I'm just unclear as to where that management position should be. I'm a follower of the philosophy that a scrum master should not have any 'disciplinary' authority over either developers or product owners. To avoid trust issues. I'm equally concerned, that someone of the dev or PO camp having 'disciplinary' authority over the scrum master would pose similar issues. So by now I'm thinking: in between Head of Dev and Head of product; Head of Process? :D
    – CMW
    Aug 4, 2015 at 15:52
  • 3
    @CMW - In case, if we are talking about ideal world, I suggest to create "Director of Process Improvement" job title for small companies and "Process Improvement Department" with staff of "Process Improvement Managers" for big companies :-) Aug 4, 2015 at 16:41
  • @CMW - By the way, it's real titles, but (unfortunately) "Process" means "Business Process" (not "Development Process"). Aug 4, 2015 at 16:42
  • I'd like that :D Instant C-level! Maybe I can make this happen!
    – CMW
    Aug 5, 2015 at 8:28

Having been on numerous Agile teams, mostly Scrum, I have heard this question quite a few times. It seems like it has to do with trying to avoid conflicts of interest for one reason or another. It is difficult to pick just one answer because Scrum Master has an official definition and a lot of actual usage definitions which change the intended alignment of the position:

  • If Scrum Master really means "Team Lead" or "Project Lead" or "Architect" or some kind of management position that directs what the team does then it should fit that part of your organization that manages day to day work. Something like that under the IT umbrella would be common. (Yes, I called Architects managers and I'm sticking to that.)
  • If it means something like "Agile Coach" or "Usually Absent non-developing team member of some generic kind who usually runs the Agile meetings" it might make sense under HR or I think someone else said "Process" or "Methodology".
  • If it means something like the Scrum definition (which is kinda like the worlds most helpful secretary - don't tell anyone its a secret) then I would say they fit where the secretaries (er... admins?) do in your organization. Frankly, this is the best kind of Scrum Master to have in my opinion.
  • If it means something like "Agile Enforcer" or "Guardian of Our Agile Commandments" (and it often does) then it probably is never going to fit anywhere and something else needs fixing before you will benefit by figuring out where to put this position in the org chart. You could try putting them in with the security concerns in you organization. That would be most likely to align with this definition of Scrum Master.
  • If they have one or more "other responsibilities" like they are also the PM, PO, Team Lead or even a developer then I would just use that "other title" to place them in the organization because that is most often what they will really be doing most of the time in my experience.

No matter what, I think it makes sense to pick appropriate leadership for the Scrum Masters for lots of reasons. I'm not sure that keeping them entirely neutral is helpful unless you want them to be a mediator of some kind. It would be ideal in my opinion to decide what the position means to your organization and then put it with like concerns, whatever they are. Day-to-day, the org chart should matter less than whether they become full team members and share a sense of camaraderie and accomplishment with their team.


I think the SM should be in two teams:

  • if there's a COO / Operations Management team, they should be there (they can also help the rest of the company on their process with agile tools and methods)

  • if Tech is sort of an independent department, the SM should be part of the management / leadership of the tech team. They have the biggest knowledge of the team and need to know what the leaders are up to to represent the interests of the teams.


Honestly, any part of the org that values transparency and honesty, will shield you from politics/pressure and agendas, and understands what an SM is there to do - question, challenge, and grow the teams. I'd prefer that over something that "made sense" contextually, i.e. closer to product, or HR, or whatever. :)


A successful product needs leadership along 4 dimensions

  • Business - (product strategy, roadmap, marketing, sales)

  • UX

  • Tech

  • Delivery

The corresponding roles are Product Manager (owner), UX lead, Tech lead and Delivery lead (this last one is closest to Scrum Master). One could argue that none of the last three should report to the product manager but rather to a VP of UX, Dev & Project Mgmt. respectively. However, this often degenerates to a unworkable matrix org.

I think it is okay to have the Product Manager as line manager as long as there are other mechanisms in place (e.g. decision records) that discourage the Product Manager from disregarding input from the other leads.

Full Disclosure: I am the author of the work referenced in the link.


I just couldn't disagree more with reporting up through either the Product or Technology organizations. At some point, there is a likelihood that the leadership of one of those organizations is going to be inclined to protect and defend their teams first, rather than seeking first to understand why/how/what problems may exist. As soon as that happens, it is no longer safe for a SM to elevate issues and we start to break down.

Operations is perhaps the most obvious structure to report into.


In most of the cases Scrum Masters are replacement for Team Leads, which belong to the line organisation. When developers are promoted to leads they join the line organisation, if they are promoted to product managers, they join project or product.

Therefore Scrum Masters - in most of the cases - are members of the line organisation.

  • That (scrum masters replacing team leads) is specifically what I seek to avoid.
    – CMW
    Aug 4, 2015 at 14:28
  • I understand that, and I have seen this several times during the last 10 years, but I pretty certain that you cannot avoid it. When I talk to an SM in the same position as you are in, I tell them not to fight with the title, because the administration details are connected to it, and that won't change. Have a proper work description, and behave different and the title won't matter much.
    – Zsolt
    Aug 4, 2015 at 14:32
  • 1
    I disagree with this entirely and have never seen it anywhere I have experienced. Why stop your best developers from being a developer? I was a pretty sub-par developer, and like to think I am a pretty good scrum master.
    – SpoonerNZ
    Aug 4, 2015 at 19:15

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.