The other day, I received a mail from one participants of an introductory class on Scrum:

I am working as a development team member. We are looking for a ScrumMaster, and I want to take on this role. I agreed with my boss that I still need to contribute as a team member, and therefore will work 50% as ScrumMaster, and 50% as development team member.

While thinking this through, I got some concerns. I think it’s not a wise idea to become the ScrumMaster for the team that I am also developing in. What are your thoughts?

As an alternative we have a closely related team. I could work as a ScrumMaster there, and their ScrumMaster joins our development team. What do you think about such a solution?

Since I run into this type of question often, I found I should publish my thoughts on it for future reference.

The ideal

Some folks will complain. “The ScrumMaster job clearly is a full-time dedicated role.” I agree to that. Unfortunately not all companies are willing to invest that. A former colleague of mine blogged about 42 tasks for a ScrumMaster that could help as an indicator how much work a good ScrumMaster puts into his job.

The ScrumMaster should seek opportunities to improve the Scrum team to deliver better products faster. He needs to talk to development team for that. He needs to coach the ProductOwner. He needs to facilitate meetings, mentor team members, coach the team and individuals. He also needs to collaborate with the larger organization about organizational impediments (such as part-time ScrumMasters). He needs to help the development team remove impediments. If a ScrumMaster cannot dedicate 100% of her time to fill the role, the Scrum implementation is likely to fail providing the benefits of competitive companies.

The bottom line: if you can’t dedicate 100% of your time for the role of the ScrumMaster, don’t do it. You are likely to do a terrible job, and not fill in the role. You will be challenged between development team work and the role of the ScrumMaster. You will be part of two parties, and it will drag you down.

ScrumMaster for own team

However, corporate reality at times is terrible. So, let’s dive into the pros and cons of either of the proposed solutions for the part time ScrumMaster.

When the ScrumMaster s ScrumMastering at the same team she is also developing with, then the ScrumMaster is co-located with the team, and knows many details about what works, and can trigger the “right” difficult-to-answer questions, and coach the team to become better every Sprint based upon those insights. Since she is working with the development, she knows the elephants in the room, and she knows when the team needs team building. She is interacting with the team colleagues on a daily basis, and probably applies pair programming with everyone of them.

On the downside, facilitating the meetings can be a drag if you are involved in the contents of the meetings. Especially in the retrospective you might lose the role of the facilitator, either on purpose, or just as seen from the outside. At that point you will be ineffective as facilitator. Also, personal coaching may or may not work with team members that you interact with on a programming basis every day. For some people it’s difficult to open up in front of people they will work on the same level in the code. Be aware of that as well.

Bottom line: I would recommend to get some help (mentoring, coaching, training, …. whatever suits you) for the role as facilitator. Especially since you fill a two roles on your team, your colleagues will have a hard time to differentiate in which role you are saying what, and are likely to misinterpret it. There are some facilitation tricks that can mitigate that risk. Whatever learning suits you most, can help you become a clear facilitator, and a clear team member for your team.

ScrumMaster on another team

You are not involved in the Sprint details, and can maintain your outside perspective, providing feedback to the team members. Facilitating will be easier. If your work is similar than the work of the team you are developing for, then you can also bring up and address common problems more easily.

On the downside, you won’t be able to attend the retrospective meetings of your own team if it’s scheduled at the same time. It also depends where you consider you should sit to get the right insights. If you sit with the team where you are developer in, then you will have greater identification with the work of that team, and might oversee details regarding team building in the team you are ScrumMastering. If you sit with the team that you are ScrumMastering, you will have greater insights into their team building, but might not feel as part of the team where you are developing for.

Try to sit with both teams if your office allows that. You also need to find a buddy for meetings like the retrospective where your buddy can provide your input to that meeting as well. It will be less than optimal, since you are not in the room to help drive insights, and you will not agree on actions in those meetings, and will therefore have a lesser identification with the results. Be aware of that.

Sometimes you have to…

Actually, I can’t really answer the initial question for you. The bottom line is: don’t do anything fewer than 100%. If you cannot avoid that, then you have to pick your battles. The consultant’s answer there is “it depends”. I hope I helped you identify on what it depends, and where your strengths and weaknesses may contribute to a possible solution for you.