Problem with scrum master and developer role?

Question

Can the scrum master be a programmer on the team and take the role of scrum master just for now?

As is done in the time you must make a plan?

Answer 1

Technically yes, they can. Unlike Jesse, I don't have any preset preference whether the roles should or should not be mixed. I would more look at the context and current team's needs and then decide whether you need have your Scrum Master (SM) full time or not.

• If the team is new with Scrum an experienced person acting as SM is: one, a very good idea and two, will have a lot of work coaching and mentoring the team. In this case I'd probably tend more into exclusive SM role.

• However, if we take the same situation but have no one experienced is Scrum you may want to reconsider. I mean there will be as many questions as in previous case although inexperienced SM can be way less helpful, rendering the idea to have him as an SM full-time not so wise. In this case I'd likely have the roles of SM and developer mixed and look for some support from outside of the team.

• If the team is mature and they are fluent with Scrum there's usually significantly less work for Scrum Master, which means there will be probably quite a lot of spare time between different SM's tasks. In this case I'd either have a single SM working for more teams or assign SM other tasks, e.g. development.

• If the team is small, e.g. of 4 people, you probably don't need SM full-time even if people aren't experienced in Scrum. There just isn't enough work for such person. In this case I'd act depending on the context: I might use experienced SM in different teams or have them working on development. If my SM is inexperienced I'd probably have them working on development.

• As team grows there's also more work for SM. Naturally coaching and mentoring tasks scales up with the number of people. Also bigger team usually means bigger throughput which means longer meetings (planning, retros) to facilitate and more time needed to prepare to such meetings. With a bigger team you may end up needing SM closer to full-time. Note: Scrum teams (most teams really) don't scale up well beyond 7-8 people so you may prefer to have two smaller teams and a single SM working for both.

In every case remember: some experimentation will definitely be helpful. Start with one approach, see how it works and don't be afraid to change it or tweak it to see whether another setup isn't better. You will also notice that situation changes over time and you should adapt to it on organizational level, which means you might want to change your approach over time.

Answer 2

Yes, this is possible, however ideally I personally believe the scrum master role should be a dedicated role per sprint. If developers want to pass around the role of Scrum Master on the team that is fine.

If you want to "dual role", there some some pitfalls to be aware of:

• Don't let your development duties take precedent over scrum master duties. As the scrum master it is your responsibility to ensure that your team's hurdles & road blocks are being removed. Don't neglect that because your busy constructing software.

• Don't over commit the team within a sprint. As you are the scrum master be aware that you are the teams facilitator and may get busy over the course of the sprint and "neglect" a dev story that you picked up.

• Don't let the fact that you are the scrum master, take precedent in team discussion and planning sessions. Just because you are wearing two hats doesn't mean you have "two votes" on a team discussion

Answer 3

Yes, there is nothing to prevent a programmer from being the scrum master.

When one of the programmers on the team taks on this role it is important for them to have a good appreciation for the amount of time that they will be committing to the role.

If they are doing it full time it is important that they don't assign any tasks to themselves.

If they try to do a 50/50 split give them the time to find out if they are allocating enough time to themselves to do their development tasks. A good way of checking this is to have regular post-mortems after each sprint.