Who should be Line Manager (appraisals, disciplinaries etc..) for Developers in a Scrum Team (if it should not be the Scrum Master)?
First I thought I would share with the community the information/sources that I have researched recently regarding a certain Scrum topic as maybe this will help someone else one day.
These relates to the classic Scrum question which has already been asked and worded in many different ways:
"Should a Scrum Master give Appraisals?"
"Can a Scrum Master be a Line Manager?"
"Should a boss be in the Scrum Team?"
The overwhelming consensus appears to answer “no” with the opinion that this is a fundamental conflict that will undermine the team.
Below are some of the key “takeaways” from each source which includes contributions from renowned and high qualified contributors to this community Ian Mitchell, Charles Bradley, Sanjay Saini.
“Positioning management as ‘beyond Scrum’ instead of facilitating Scrum Team delivery is unlikely to be helpful” - Ian Mitchell
“Scrum Master should not be responsible for performance review” - Tony Lee
“The Scrum Master is a mgmt level position, but it is not a "manager" position. In other words, the SM doesn't 'manage the team' or have HR responsibility (perf reviews etc.) over the team. Also, they are not there to "drive results" or "drive the team." - Charles Bradley
“No one in the team should report to anyone in the team. All Scrum team members can report to Line Manager but he cannot be part of the Scrum team.” - Sanjay Saini
“The ScrumMaster should not be the appraiser of individual team members” - Frank Castagna & Ravishankar N
“It does make sense for a ScrumMaster to give feedback. But when it comes to taking over (or participating in) the annual appraisal, ratings, or rankings, my answer is “No. No. No!” There’s a fundamental conflict between coaching to improve effectiveness and evaluating for ratings, rankings, raises, or promotion.” - Esther Derby
“There is a basic conflict of interest between the duties of a manager and a scrum master.” - M. DAvid Green
“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” - Aziz Shaikh
All too often the Scrum Master role is misunderstood, and considered as someone acting as the Team Boss. The so-called “servant-leader”, but actually just the boss of the team. The boss who hires and fires. The boss who decides if someone deserves a salary increase. - Barry Overeem
Now we’re at least slightly concerned with looking good for the boss, which is a different driver than accomplishing the Sprint Goals… bosses sometimes forget that invisible gun is always with them - Michael James
One of the key problems having the SM as the people manager is that the person can no longer increase transparency. In fact, due to power issues, one can be pretty sure that he is decreasing transparency. Things that might be mentioned in the Daily Scrum, for example, will not be said.
On an agile team, it's essential that the team feels genuinely free to self-organize, and that simply can't happen when there's a power imbalance in the room. Having the boss on the team--or worse, having the boss serve as the team's scrum master, is generally not a good idea- - Adam Weisbart
When organizations have peoples’ bosses on their scrums team I think they are setting their teams up for a fool's errand - Adam Weisbart
So what’s left to discuss... That’s pretty conclusive, right?
Well the reason for this post is that I am aware of an software development organization currently looking to recruit/promote into the position of Scrum Master.
This company has around 50 employees and initially when they started doing Scrum the Scrum Master position was performed by the Operations Manager. This Scrum Master was responsible for both of the two Scrum Teams.
This Manager/Scrum Master combination conflict caused the Scrum Teams to suffer in may of the ways described in the sources above.
The organization is now looking to promote a Development Team member, per team, into the position of Scrum Master, with a split workload between Scrum Master duties and Developer duties.
“Much better!” I hear you say.
However the job spec contains the following line:
“Be the line manager of the developers in your team”
"Oh dear!" I hear you now say.
On challenging the above the organization responded with comments along the lines of: “Someone needs to be Line Manager of the Developers and if it’s not the Scrum Master then who else could do this as there's no other candidates here”
So after a very long ramble we have finally come to the main question of this post.
A lot of the sources referenced above state why Scrum Master as Line Manager is a bad combination.
Not too many at all cover who else could/should do these duties.
So.. “Who should be Line Manager (appraisals, disciplinaries etc..) for Developers in a Scrum Team (if it should not be the Scrum Master)?”
For large companies there is potentially a lot more scope for answers.
However I am particularly interested in hearing thoughts regarding the small/medium sized companies.
Thank you for reading this far and being part of this great community!
I’m eagerly awaiting the opinions of all of you regarding the subjects discussed in this post...
Thanks for summing it all up with plenty of resources to rely on.
What I've seen in the organisations I worked for, each team had a Team Lead who was a Senior Engineer on that team. Scrum Master was always a separate role with no direct report to the team. On the next level you would have a Director of SE of sorts, who would be managing all Team Leads in the organisation. It makes sense in a way that you cannot expect a director have dozens of direct reports.
I would say that this can work with some 'ifs' involved. Here are the pre-requisite for this to work:
- Team Lead has to be willing to delegate and let go of decisions
- He/she should not be the only approver for any kind of work the team is doing
- He/she has to be a good communicator and able to provide positive and negative feedback to team members in appropriate way
- He/she should provide team members opportunity to speak during meetings (especially, Retrospective) and not overrule their decisions just because of disagreement
- He/she should be ready to let the team try experimenting, take risks and fail fast
Though I say that this approach may work, I do not think this is the way to go in Scrum. This is just based on my recent experience
Consider that in a Scrum Studio - a protected part of an organization where the rules of Scrum are in effect - all previous reporting relationships are held to be in abeyance. So, is it appropriate to have line management at all in a genuine Scrum Team? Might the very notion and perceived value of it need to be rethought?
Great comments so far guys.
Keep your opinions comming...
This is the exact issue I'm dealing with, who handles pay, performance reviews, and other personnel issues for scrum team members? Also for small to medium sized organizations. I really appreciate the summary of links and quotes related to this issue.
The common response in Scrum communities appears to be that it's very risky for any of the Scrum team members to do it.
And I really love how Scrum teams are setup to operate independently of any organizational hierarchy or bureaucracy.
However there is necessary work outside of what Scrum deals with. This includes what's often described as a functional manager, people manager, talent manager, or other similar categories. There is actual work in dealing with budgets, recruiting, career development, resources, strategic technology or industry shifts and so on.
So what are some ways that people recommend for making this all fit together?
Great question Reggie!
It’s exactly what I’m still dealing with at the moment.
I have passed on the above information and also the additional new references listed below.
But the organisation is still wanting the 50% / %50 split Developer/Scrum Master role to also include the following responsibilities (under the Scrum Master’s 50%):
- Appraisals (that will most likely be linked to pay raises)
- General Report (e.g. personal issues, complaints etc)
- Holiday sheet signoff
- Resource allocation (to the Scrum Team)
The consultant involved, who has a very strong background in Agile/Scrum, references that the Scrum Guide does not answer these questions, and that in this situation the Scrum Master is the best person to fulfil these responsibilities.
It has also been suggested that the role could be renamed to be “Developer / Supervisor”. With the Scrum Master responsibilities failing under the “Supervisor” part if that will help clarify things.
So as Reggie asks: “So what are some ways that people recommend for making this all fit together?”
And I’ll ask if there is anyone with any positive reactions or experiences related to the above new job responsibilities proposal?
“The Scrum Master has not authority to tell the development team or the product owner what to do their job
They weren’t given the authority to manage the other members of the Scrum Team.”
- Ken Schwaber
“But even the Scrum Master does NOT manage the Development Team.” - Anke Maerz
When you look at the responsibilities of a Scrum Master and that of a manager, it is difficult not to notice that they are very similar. So, this begs the question… should a manager be a Scrum Master? No, it is a bad idea. - Lv Yi https://less.works/less/management/manager-scrummaster.html
Common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. - Bob Galan
A Scrum Master has no command and control, no authority over people. - Gunther Verheyrn
Scrum Master does not have any monitoring or control responsibilities - Giri Saran
It boils down to accountability. If the scrum master becomes accountable for all, not just the scrum metrics of the team then they are no longer the scrum master and have transitioned to a manager using a set of techniques to manage their team.
Ha, well it seems we have consensus for keeping the Scrum Master out of performance appraisals! That said, I'm still hoping to hear a suggestion for how to make it work that is consistent with Scrum.
Ian's quote "is it appropriate to have line management at all in a genuine Scrum Team? Might the very notion and perceived value of it need to be rethought?" is a very interesting one and a useful thought experiment but I'm struggling to apply it to the challenge of annual reviews, etc. (Ian, I've learned as much from your posts as anyone in this forum so please don't mistake my observation for criticism!).
In my experience contributions from individual team members (Scrum or otherwise) are not all equal and expecting them to self-organize around their evaluations seems unlikely to survive in practice. Is there experience with peer-review driven raises/promotions? That would seem consistant with Scrum.
I'm still working to understand what would be the proper feedback loop to get performance information out of the development teams and into the hands of folks doing the evaluations.
One thought I had is to potentially leverage the techniques professional sports front offices use to identify individual performance impact in a team environment, which typically involve heavy analytics and regressions. Would it be possible (or desirable!) to evaluate the impact of individuals based on team Velocity over time for various Sprints they participate on? There are non-linearities of course, but so too in pro sports, but perhaps this is a consideration?
For me, any attempt to evaluate individual performance outside of the construct of the team runs counter to Scrum, and I try to make such harmful practices (and likely consequences) as visible as possible.
There are a few approaches though that I have seen work in a Scrum environment:
- 360 reviews is one way to gather valuable feedback regarding individual value/contribution
- Can the individual identify what they have learned? (how did they work to increase their value to the organization)
- Can the individual identify what they taught others in the team or in the organization? (how did they work to increase the value of others)
- Base a significant portion of the individual evaluation on team-based results
I hope this is helpful.
I appreciated the inherent conflict in individual performance evaluations and the principles of Scrum, so your response was very helpful to me Timothy, thank you. By way of background, I spent my first 10+ years as a developer before spending the last 10+ in presales and I'm keen to bring Scrum to my SE teams. I've been in groups that were very individually driven and rewarded as well as SE organizations with team-driven goals and largely team based evaluations. The latter definitely led to more commitment, openness, courage, focus and respect! The former frankly often encouraged the opposite.
In my group we have went through quite a few agile transitions that changed the line manager role:
- We started with component teams being called Scrum teams. The line managers were the leaders of a Scrum Team (sometimes they were the Scrum Master and sometimes someone else was the Scrum Master).
- Then we moved to the Spotify model where we have built cross-functional Scrum teams, but we still had technology teams in parallel (“squads” and "chapters" in Spotify language). The line managers where the leaders of the technology team (the "chapter").
- Then we moved to pure Scrum teams (specialists became generalists, T-shape engineers, so no more pure technology teams). At this point the line managers didn't have technology team anymore, they simply had people reporting to them. We also used self-selecting team to build the Scrum team, so they have people in different Scrum teams. At this point, we have changed their name from a "team leader" to "coach". They coach people for people-development and coach the group for engineering practices.
So we have line managers, but they don't own delivery/technology, but rather people-development and engineering-practices (through driving guilds). All of them filled their spare time with additional role, as being part of a Scrum team (the people in the Scrum team are not reporting to them).
I still struggle on how such a line manager does a performance evaluation (as he/she are not in day-to-day interaction with the people anymore), what the content of the engineer-manager weekly meeting is, how we set objectives that encourage Scrum (rather then individual behavior).
In large organizations, the question is considerably easier to answer.
For small or medium sized ones, the question can potentially be answered by looking into each setup. There is no universally applicable solution. I appreciate there are cultural differences between countries and regions, but where possible, how about initiate discussions with the people (of the Scrum teams) around "Given the [company's characteristics], where do you think you'd be best placed in terms of organizational structure?" The responses are likely going to provide the actual solution or point towards one.