Part-Time vs. Full-Time Scrum Master
Being pulled between being a Scrum Master and fulfilling another role on the team usually means that only one may get done well.
Join the DZone community and get the full member experience.Join For Free
Some people think that being a Scrum Master is a part-time job and that you can also be a developer during a project or that a Product Owner can share the Scrum Master role as well. Well, the Scrum Guide does not specifically rule this scenario out, but it is not ideal and especially if you are new to Scrum, I don't recommend it. The simple reason is that the Scrum Master's role is more than just being a facilitator during the Scrum Events.
Being a developer on its own is a full time job. There are problems to solve, requirements to understand, discussions to be had. Adding on top of that the role of Scrum Master, where the Scrum Master is there to help support the team and shield the team from trouble, just adds more stress and complexity to the situation. It makes it harder to know which to concentrate more on. Even being a developer on another project still takes away from the Scrum Master duties. What happens is that one of the roles wins out. Usually (but not always) it is the development role as deadlines and pressure increases and the Scrum "stuff" gets ignored.
The same goes for sharing the role of a Product Owner, Project Manager or even just being a normal manager. Something goes wrong and you either do both jobs poorly, or one job poorly. Never both jobs well.
The thing is, the role of the Scrum Master is to make sure that the team is continuously improving, to find better ways for the team to communicate and integrate. To clear the way for the team to work and grow. To run interference and remove obstacles and impediments from that objective. They do this by focusing on the team and its needs. They are the advocate of the Scrum Process that keeps the cycle of continuous improvement and when the team deviates and reverts back to their old ways, which they will when new to Agile and Scrum, the Scrum Master's role is to bring them back. Teams will deviate; it's human nature to revert back to something you know, especially when you are under pressure, rather than to push forward into the unknown. It's the Scrum Master's role to push across the chasm to bring a team to be performance. An inexperienced Scrum Master facing two roles will likely do the same—not always, but is likely.
For a Scrum Master that shares the role of the Product Owner, there becomes a bigger problem. The two roles are in conflict. The Product Owner is trying to get the product completed as quickly and cheaply as possible. The Scrum Master is there for the welfare of the team. Which one wins out? Well, with a new Scrum Master/Product Owner new to the Agile principles and with the mindset of just get things done, then the Product Owner role wins out. You then get a Scrum Master who goes into "Command and Control" mode, trying to push the team to get things done faster. Compromises in quality are made, and in the end everyone has a bad Agile experience. Mind you, you do not have to have a Scrum Master in a dual or even triple role for this to happen, but it is more likely to happen. It can happen and does happen regardless, but that is a talk for another day.
I have made this mistake. I've been a developer and a Scrum Master at both the same time, and even though I had every intention to be a good Scrum Master, I made mistakes. Development work took priority. Then again, there were times during the same project where I would focus more on the Scrum Master role, and the development side suffered. The end result though was that neither role was done extremely well.
Every situation is different, and it is possible that a Scrum Master can take on dual or triple roles, but I would expect that to happen with a highly mature agile team. Not one who is just starting out. I also realize that there may not be a choice. There wasn't in my case. All you can do in this situation is do your best and look out for the welfare of those on the team, not just those of the customer.
Published at DZone with permission of Holger Paffrath, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.