Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
3  
    
Who is the Product Owner? –  Aaron Kurtzhals Oct 4 '13 at 16:14
    
@Thomas, Thanks. I had already seen these, and the main factor in these was 'pulling rank' which I have tried to outline I very much do not do. –  SpoonerNZ Oct 4 '13 at 16:37
    
@AaronKurtzhals, The Product Owner is our digital marketing manager , the teams main product is a website. It may be worth noting I was effectively the scrum coach of the whole team. –  SpoonerNZ Oct 4 '13 at 16:39
    
In my opinion anyone product owner oriented should never run the scrum. QA resources aren't a bad choice as it keeps them abreast to what is coming down the pipe. Developers are a meh choice as they have a vested interest in keeping the workload light. –  Rig Oct 8 '13 at 16:26

8 Answers 8

up vote 13 down vote accepted

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.

share|improve this answer
    
I would agree entirely if it said 'a scrum master tends to want the right amount'. –  SpoonerNZ Oct 7 '13 at 8:14

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.

share|improve this answer
    
I understand this, and feel that within our team we have overcome this - often in a retrospective decisions will be made that I don't necessarily agree with, but I have faith in the team so am happy for them to play it out. If this is the ONLY reason, I think I'm safe, hence the question looking for other reasons. –  SpoonerNZ Oct 4 '13 at 16:40
2  
I'm a dev manager who has acted as scrum master, and this is exactly the issue I had. It was way too tempting to spend the scrum telling each developer what they would do. It worked better for us to have a senior developer be scrum master. –  Steven Burnap Oct 4 '13 at 19:50

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.

share|improve this answer

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.

share|improve this answer
    
This is the most pragmatic answer +1 –  jmo21 Oct 4 '13 at 20:08

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.

share|improve this answer
    
+1: Great point about the retrospectives. –  Jim G. Oct 5 '13 at 14:59

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.
share|improve this answer

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.
share|improve this answer

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.

share|improve this answer
3  
Being a scrum master can easily be a full-time job depending on the environment you are in. Removing impediments and running interference for the team can be extremely time consuming in companies (especially large bureaucratic companies) that are not used to Agile methods. –  Matthew Flynn Oct 4 '13 at 15:48
1  
@MatthewFlynn: Good point. However... in that case, they would have enough resources to dedicate to a full-time scrummaster (I get the feeling from the post that there is resource shortage). However, I work at one of those large companies you mention and a full-time scrum master is still not always warranted. We still have them but they often get in the way of the team doing their job efficiently because they cause more trouble while trying to justify/overdo their full-time positions. –  c_maker Oct 4 '13 at 15:51
1  
Good point right back at you. I suppose it depends on the company and the individual. Not surprising, really. –  Matthew Flynn Oct 4 '13 at 15:58
1  
Thanks for the response. I am trying to identify what could cause, or be 'that dreaded 1%', because I can't see how the roles conflict once it is clear to the team I am a servant-leader. A servant leader is still a leader after all. –  SpoonerNZ Oct 4 '13 at 16:42
    
I'd also considered making our senior dev a scrum master, but then realistically I can't see much for me to do! The other option I considered was being scrum master and not manager, but the Head of IT wouldn't like the idea of the people management of the whole team falling on him. –  SpoonerNZ Oct 4 '13 at 16:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.