What are the negatives of Development Managers as Scrum Masters?

Question

It is commonly agreed that team managers should not be scrum masters, but I am struggling to see why. For context, I am an Application Development Manager with 4 devs in a Scrum Team. I come from a Scrum Master background, and have introduced scrum to the organisation. I have built the team from scratch and made it clear that everything I do is to facilitate the team, and that they make the decisions. As a team we are very open - they even silenced me at stand-ups for a while to eliminate the 'reporting' feel we were starting to get. A lack of openness is generally the biggest argument against the manager as scrum master, but handled well, is easily overcome with the right culture.

I've been warned by experienced scrum coaches that this is a dangerous situation, and there are risks 'if things go badly'. The way I see it the 2 positions do not conflict, in both roles I have the same aim for the team and individuals. Scrum resolves conflicts within the team, which could traditionally be a managers role. The self-managing nature of sprints takes away the allocation of work a manager would traditionally do.

All I really see left to pick up as a dev manager is making sure individuals needs are met, career objectives, workplace etc. I have a weekly catch up with each team member to raise any issues, and handle any admin tasks. A lot of this relates directly to the team, or my role as scrum master anyway.

I understand in large organisations how this could be unmanageable and a separate role but for a small organisation we could certainly not justify another Scrum Master or Development Manager.

Please enlighten me as to the pitfalls of Development Managers as Scrum Masters, excluding the points I raised above and have already overcome.

Answer 1

Essentially, you have a conflict of interest. A manager's job is to meet deadlines. A scrum master's job is to ensure estimates are as accurate as possible and to work at a sustainable pace. A manager tends to want more work pulled into a sprint, and a scrum master tends to want an amount that can be realistically finished, regardless of external deadlines. Although a good manager can balance that conflict, it's much easier when the job is split between two people. Managers usually are much better suited for the product owner role.

There's nothing wrong with acting as scrum master if no one on your team is familiar with it, but your team will see benefits if you hand off that role after a few months. It's important for that role to be seen as a peer. Even non-management scrum masters often have to rotate out after a while because the team starts to treat them too much like a manager.

Answer 2

I have actually seen what happens when a "technical manager" gets too heavily involved in the day-to-day mechanics of a project, and it isn't pretty. In our case, the manager in question was not the scrum master but was trying to co-opt some of those decisions; if we hadn't actually had a separate scrum master to play defense then it would have been far more painful.

(Incidentally, this was not my manager, so I feel fairly objective on this point.)

I'll go over what I saw as the primary conflicts of interest; if you don't think that any of these apply to your situation, then maybe you can do both. But make sure you re-check these assumptions on a regular basis to make sure you're not falling into any of these traps:

1. Technical managers are typically responsible for a certain role within multiple teams. If it's only one team, then it's more of a "lead" than a "manager". This spreading-out of responsibility means less time with the team and less time with the project/product, and tends to lead to "hit and run" style management.

2. Technical managers have many other managerial duties to the business. They need to do coaching/training, performance reviews, interviews/hiring, long-term infrastructure/resource planning, and more. This can easily become a full-time job by itself and means very little remains to spend on facilitating.

3. A busy schedule can also impose itself on the team; technical managers may need (or want) to pull team members into meetings at what the team deems to be an inopportune time. It's normally the scrum master's job to manage and try to eliminate interruptions, but it's impossible to be objective about that when you have your own schedule to worry about. Scrum masters rarely need to meet separately with team members because all of those meetings are already pre-scheduled (stand-ups, retrospectives, etc.)

4. Technical managers must deal with cross-cutting project concerns and their natural impulse will be to try to standardize everything - libraries, source control, algorithms, layouts, colours, whatever. While this can actually be a good thing for the company, it ultimately leaves no one to go to bat for what the team wants to do, and they may have very good reasons for wanting to do something differently. This runs counter to the "continuous improvement" ideals underlying Scrum and similar methodologies.

5. Managers who come from an expert background in the role they manage will have their own fairly strong ideas about how the work should be done and how long it should take. This is not a bad thing as a manager, but as a scrum master it will often mean biasing team members into designs or estimates that they wouldn't otherwise have agreed on - and they probably know more than you about the problem at hand.

6. Team members will always have trouble differentiating between a request and an order. They won't tell you this and may not even realize it themselves. Even if you make it clear that you are merely asking and not telling, in their minds, you are still their manager and there are career-level risks to saying "no". This is probably the most insidious of all the problems because there's nothing you can do about it - it's their attitude and not yours that matters.

If you're sure that you're never going to fall into any of these traps, then go for it... but I repeat, make sure you frequently validate your assumptions by talking to your team (and other teams/managers!) and make sure that they're not happening in a subtle or unconscious way that maybe you don't notice.

On a positive note, I'll add that the fact that you consider the issue important enough to actually ask the question means that you're probably pretty good at both roles. Caring about the team and not just your own career ambitions probably accounts for more than half of what good management is, in my books anyway.

...but being good at both doesn't necessarily mean you can be good at both at the same time, all the time. Be careful of that.

Answer 3

I believe the main problem is that as a manager, you have the authority to tell the team what to do. A scrum master does not have this authority outside of enforcing the principles of Scrum.

What does this mean? The manager's input will implicitly carry more weight. You might not mean it to, or want it to, but at the end of the day your team members career and paycheck depend in some way on you. And they know it. And this taints the relationship.

Can you still do it? Of course. You just need to work very hard to reinforce that you are a servant-leader and top-down won't fly.

Answer 4

This isn't religion and the rules of Scrum are not dogmatic. If there's ever been a case for a combined HR Manager/ Srum Master role, you've made a good one. Be on the lookout for those pitfalls you mentioned, but there is never going to be a single set of rules that fit every situation perfectly.

If your team is comfortable with you performing both roles, then there's no reason to shake things up just to fit with the rules of a book.

Answer 5

The biggest problem I see is the situation where the team has an issue related to you, the manager. If they are junior, or lack confidence, they may be afraid to speak up during retrospectives. This could limit the effectiveness of the retrospectives. Many people are afraid to say "I feel the manager is being unrealistic" when the manager is present.

So, maybe you excuse yourself from retrospectives to solve this problem. Now your team is doing retrospectives without a scrum master, also potentially limiting the effectiveness of the retrospective.

In either case, you're having a negative impact on the team.

Answer 6

The main problem I see is that you are sending conflicting messages to the team about the team's organization.

Below are two possible team organizations. Both can be successful. They are different. (They are not the only possible options.)

1. The team has an officially designated leader. The team leader is ultimately accountable for the teams' overall performance. The team leader may not make all decisions, but the team leader has the final say on all decisions.
2. The team is self-organized and does not have an officially designated leader. Everyone on the team is accountable for their own and the teams' overall performance. The Scrum Master facilitates the Scrum process, but is not empowered to make unilateral decisions for the team.

It sounds like your real team structure is #1, but by using the terminology and several processes from Scrum, you are implying that the structure is #2. My opinion is that #1 is not Scrum.

Below are a two suggestions for how to resolve the conflict.

1. Keep doing things as you are, but clarify that you are the team leader and you are not following Scrum 100%. It would probably help to explain that while you see the value in segregating the duties of a manager and scrum master, that is not feasible for the company.
2. Hand off the Scrum Master responsibilities, as much as you can, to someone else. Even if you still have to retain some responsibilities like clearing roadblocks and deflecting distractions from the rest of the organization, it will still help to have much of the Scrum Master work done by a peer.

Answer 7

What are the negatives of Development Managers as Scrum Masters?

Development managers are hired to:

• Solve development problems.
• Monitor and reduce technical debt.
• Grow the technical staff.

Their background and expertise predispose them to focus on technical issues.

---

On the other hand, project managers/scrum masters are hired to;

• Ensure project success.
• Assign work and triage bugs/questions to the appropriate development resources.
• Collaborate with the development team to remove all obstacles that may delay project completion.
• Relay project status to upper management.

---

• When a project or a company grows to a certain size, it is inefficient and unwise to ask a development manager to perform both duties.

• A development manager should be inclined to take "deep dives" into code and/or architecture, whereas a project manager/scrum master should always be concerned with the "50,000 foot" view of things.

• Most development managers have spent years developing code. Development issues are very familiar to them.

  • Therefore, they are most useful when they are solving technical problems.
• Project manager/scrum master roles require people who are very organized and very detailed oriented, but not super-technical.
• When you can afford to let these people specialize on the things that they are good at, the business is most efficient.
• And when you can offload scrum-related responsibilities from a development manger's plate, he/she can spend more time on technical issues and reducing technical debt.

Answer 8

I would listen to experienced scrum coaches. It is possible that you would work out just fine for 99% of the time. However when that dreaded 1% comes along and the roles conflict you have a chance to screw up not only an individual's relationship with you but the entire team's well being. And after one screw-up your role as both scrum master and manager would be undermined.

If I were you I'd identify an individual on the team who has the potential to be the scrum-master and go with him/her. I always viewed a scrum master as someone who the team trusts and who understands the process, the business and the scary technical stuff as well. If you chose a capable person, a scrum master role is not (and not even close to being) a full-time job.