By Mike Cohn
The selection of a new Scrum team's ScrumMaster can impact the success or failure of the team's Scrum adoption. Choose the wrong person and the team could face the uphill struggle of trying to become self-organizing while under the thumb of a command-and-control style manager. Choose the right person—matching the skills of the new ScrumMaster with the initial needs of the team—and the team will have an incredible headstart in adopting Scrum.
I had intended to use this short column to provide some guidance on how to select an appropriate ScrumMaster. In preparing to do so, however, I realized that a much more fundamental question needs to be answered first: Who should choose a team’s ScrumMaster? Should it be the team members themselves? Should it instead be a departmental manager? The Project Management Office? Maybe the Product Owner should choose the ScrumMaster with whom they think they can work best?
I’d like to answer that, in all cases, the team members should choose their own ScrumMaster. Unfortunately, that's not always possible. Whether the team should choose their own ScrumMaster is dependent largely on how far along in their adoption of Scrum the team is. In many cases when a team first adopts Scrum there are many parts of it they are unsure of. There are many parts they will struggle with and will be tempted to omit or weaken. New teams often, for example, are tempted to conduct their daily scrums less often than daily. They aren't used to working closely with others and have not ventured far beyond their individual roles. Taking a team at this level and saying, “you’re self-organizing so you figure out who your ScrumMaster is” often leads to disaster.
Instead, these very new teams often benefit from a telling style of leadership. They need to be told that they will produce software that is working and “done” at the end of each sprint, that they will meet daily, that potentially shippable means tested, and so on. I’m not implying that they are told this in some heavy-handed, command-and-control way. Rather, my point is that the team needs a leader/ScrumMaster who will tell them it’s not acceptable at this point in their Scrum adoption for them to experiment with the fundamental, generative rules of Scrum. These teams probably aren’t ready to choose their first ScrumMaster.
By contrast, consider a team in which individuals are comfortable working with each other; where each team member may have a defined functional role but where each is comfortable and capable of stepping beyond that role for the good of the team; and where team members have a greater willingness to stick to the rules at first. A team such as this would likely bristle at being assigned a ScrumMaster.
So, who should select a team's ScrumMaster? My default position is that the decision should be left up to the team. However, a caveat to that position is to first make sure the team is up for the initial challenges of adopting Scrum. Don’t make it harder for them by piling this decision on them if they won’t have a framework for making the right decision or if the decision will be taken away from the whole team by one overly aggressive member who sees the role of ScrumMaster as a ticket to increased authority, greater power, and a seat on the corporate jet.
When the team isn’t in a position to choose their first ScrumMaster, my fallback position is that the decision belongs to the departmental manager whose neck will most be on the line for the success of the project. I prefer to avoid having the product owner select the ScrumMaster because that has the possibility of eroding the beneficial tension that should exist between a good ScrumMaster/product owner pair.
In a future column, I’ll provide some practical advice that can be used to help select the best ScrumMaster, whether that decision is being made by the team members themselves or by a departmental manager outside the team.
