We're trying to plan for agile transformation soon, and one of the main sticking points in this is organizational structure. Management's expectation is to have a Scrum Master perform all normal functions, but tacking on hiring, firing, and performance reviews for people under his management. This would also add additional "technical ability" requirements to this position, and then basically have one Scrum Master for the team.

My concern is that it's going to create a situation in which s/he will be tempted to say how exactly something needs to be done, and people will take his/her word for it, as she/he's ultimately doing performance reviews. This undermines some of the basic agile principles.

Does this work long term? And what are the caveats I should watch out for implementing this?

  • 1
    Since this is a workplace site and not a programming site, you may want to add some links to the scrum terms you're using. It makes it easier for those not familiar with the concept to learn more about it and give insight into what definitions you plan on following.
    – JeffO
    Commented Aug 28, 2013 at 0:30
  • 1
    Hmm, would it belong on a different site then? Like PM.SE? The question is meant to be for those who are familiar with the concept and worked in an environment like that.
    – Sergey
    Commented Aug 28, 2013 at 15:27
  • @jmort253, yeah, that would probably be a good idea. Thanks!
    – Sergey
    Commented Sep 11, 2013 at 15:19
  • Could you explain 'tucking on'? Do you mean that the the Scrummaster would also perform hiring/firing/performance reviews. Commented Sep 11, 2013 at 20:39
  • @DJClayworth Yes, exactly.
    – Sergey
    Commented Sep 11, 2013 at 22:41

6 Answers 6


A manager who does the hiring, firing, performance reviews and has technical ability can still undermine the Team and force them to do things his/her way whether this person is the Scrum Master or not. For this person to take on the role of Scrum Master is just an additional burden on them.

The decision makers who chose to go the Scrum path hopefully know how it should work and the manager's manager should be doing an evaluation to make sure this person is facilitating the needs of the team and lets them do the job they were hired to do. If the manager is going to constantly "pull rank", this is a personal issue and possibly a misunderstanding of how a Scrum Team managed.

It may help to bring in an outside consultant to help with this process. Sometimes it's easier for management to grasp the "let the team manage itself concept" from an outsider than directly from a team they fear is doing it out of self-interest.


It seems like the company has decided to go this way even though you understand that this undermines some of the basic principles of Agile. So I'll stick to some of the caveats that should be watched out:

  • Missed deadlines/goals by the team should not get attributed to your hiring/firing decisions. Hiring process maybe changed to have a peer-interview session with the whole team
  • Team members should not start hiding progress/impediments/estimates depending on your displeasure/pleasure
  • Scrum master should continue to provide frequent performance feedback and coach the team
  • Team should continue to manage the daily standups (scrum master just makes sure that daily standup are done).
  • Team should not start reporting to the scrum master
  • Performance reviews should be based on evaluation done by all team members including the scrum master
  • +1 for pointing out that this is not agile. I took a stronger stance on it in my answer than you did, but think your bullets add a lot of "project smells" that the implementation has gone badly wrong.
    – Todd A. Jacobs
    Commented Sep 12, 2013 at 19:38
  • @CodeGnome How can you say "this is not agile" based on just one small aspect of a giant system? I think you're jumping to conclusions.
    – Sergey
    Commented Sep 13, 2013 at 14:52


We're trying to plan for agile transformation soon, and one of the main sticking points in this is organizational structure. Management's expectation is to have a Scrum Master perform all normal functions, but tacking on hiring, firing, and performance reviews for people under his management.

Your company is not planning on transforming anything. They are planning to rename a role, which they hope will magically endow the project with the benefits of agile processes without going through the actual hard work of re-engineering the project management process, the corporate culture, or the organizational structure. This is extremely likely to result in epic failure for the project, blame for the team, and a blot on the resume for the putative Scrum Master.

A Scrum Master Isn't a Line Manager

The Scrum Master's job is to referee the Scrum process, educate the team and the organization about Scrum, and radiate information about the project to the Product Owner and the organization at large. While it isn't impossible to give a Scrum Master managerial authority, it actively works against the self-organizing principles that Scrum is meant to encourage.

A Scrum Master's primary role is often compromised when he's asked to manage individuals rather than act as a servant-leader for the entire team. An ideal Scrum Master is a spokesperson for the team, working with the Product Owner and the stakeholders to clear obstacles; cracking the whip isn't part of that job description.

Organizational Change is Hard

A lot of organizations attempt to label themselves agile, or say they've adopted Scrum, but they never actually change the fundamental business processes that underlie their projects. Scrum is a capacity-based framework that uses time-boxes to estimate and measure progress; it is not a magic bullet that can substitute for inspired leadership.

Adopting agile practices and frameworks is certainly a laudable objective. However, it takes more than a change of title and a new business card to restructure the role of Project Manager to Scrum Master. It also requires pervasive changes to the organization (especially among the stakeholders) in order to embrace the iterative development model. It also requires behavioral changes at the stakeholder and management levels to support the one project, one Product Owner model necessary for effective Sprint Planning.

Management Needs to Change, Too

Scrum isn't something that only development teams do. Adopting Scrum requires executives, stakeholders, and managers to change, too. The psychological shift from 100% utilization of individual team members to team-based capacity planning may ultimately defeat an organization that refuses to change its metrics or its management style.

For Scrum to be successful, senior management needs to make fundamental changes, too. If the "agile transformation" stops at the organizational boundaries of the development team, the Scrum implementation will not succeed.

  • 1
    So, you are saying that scrum master is a bad idea for this role. But what works well? Who is suited to perform these functions in an agile team environment?
    – Sergey
    Commented Sep 13, 2013 at 14:50
  • 1
    @Serge No one within the team handles those functions. They are extrinsic to the project. HR, middle managers, and departmental directors are some examples of organizational roles that can handle personnel issues; they just aren't members of the Scrum team. In other words, they're "chickens" instead of "pigs."
    – Todd A. Jacobs
    Commented Sep 16, 2013 at 14:59
  • What would a "Manager" base his decision on, if he does not interact with the team? In a regular setting, manager assigns tasks, works with people, etc. All this goes away on a scrum team.
    – Sergey
    Commented Sep 20, 2013 at 1:43
  • @Serge That's certainly an interesting question, but it represents "scope creep" of your original question. Please feel free to ask it as a separate question.
    – Todd A. Jacobs
    Commented Sep 20, 2013 at 14:44

I am an Application Development Manager in this position, and it works excellently for my team. The main thing is the difference in mindset from traditional management. I have the benefit of building the team from the ground up so made it very clear from the start that I am here to help them, and they make decisions more than I do. At first it took some time for the team to truly believe they make the decisions and are fully in control but after a few retrospectives, genuinely listening and making changes THEY decide, they are now willing to bring up anything for discussion.

This worked so successfully that we even had a small stint where the team decided I was silent in stand-ups, to prevent them from talking to me rather than each other. It only lasted a few stand ups, but did help them focus on discussing issues rather than reporting to me.

If you give the team ownership, they will take responsibility.

  • 1
    I would also like to add I only see this as the case in a small software team. I think if a company has multiple scrum teams, it is sensible to have a separate development manager overseeing all developers. In my current workplace, there would be no way to justify a Development Manager as well as a Scrum Master, and I don't think the IT director would be receptive to the idea of the dev team reporting to him instead of me.
    – SpoonerNZ
    Commented Oct 3, 2013 at 9:05

There is an excellent post published http://www.sitepoint.com/managers-make-terrible-scrum-masters/. I encourage to read it all. Here are some quotes from there to bring the point:

There is a basic conflict of interest between the duties of a manager and a scrum master.

A manager sits at the top of the pyramid in a team’s hierarchy, while an agile approach is all about fostering a networked environment of open communication, in which team members rely on each other rather than on the top-down rules of the organization.


The hierarchical nature of management helps to position a team inside a larger organization, but it operates best if it is kept separate from the networked process of agile.


Building and curating the team is the primary duty of the manager.


We had this situation; we also had a situation as a PO being also SM. They didn't help the teams at all and didn't bring any improvement. Nothing happened.

The problem is that the functional manager has an agenda. The PO has an agenda.

-The SM's agenda is different and has a different focus. Many time the SM has to argue with the functional manager to get benefits for the team or bring changes which are beneficial for the team (but maybe not so much for the manager). It's practically impossible for the functional manager to become objective enough to "serve lead" the team. Especially when they have performance targets to fulfil.

  • The SM is many times in conflict with the PO. The PO will push for estimations, more work done and will want sometimes to assign tasks to devs they know can perform best. The SM stays in the way of all that and sometimes protects the team in case the PO is abusive. So there is absolutely no way a PO can be objective enough to be a SM.

Ideally the Scrum Master is only a Scrum Master. Can also be a Coach but that's about it. They can be in the leadership / executive board to influence decision making for the company, but always keeping the Servant Leader hat.The moment you give him/her a management function, you break the entire concept of Scrum Master, the way the team relates to the person, the way the person influences the team, the trust the team has in the person.

TL;DR: no, a functional manager has a different agenda and is not objective to fulfil the role of Scrum Master, while the team doesn't trust or relates to a SM who's also the boss.

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.