I’ve stumbled across this scenario a number of times, both from the inside looking out, and from the outside looking in. A greenfield Scrum company is closing in on launching its maiden scrum project and management is looking to appoint a Scrum Master (SM) to the team.
The team consists of one or more developers, designers, architects/tech leads etc., all with none or limited scrum experience. For the untrained eye, a good candidate for a SM is someone familiar with the company, its customers and its way of managing projects – preferably a senior staff member. Obviously, this is the natural choice for the management as well since they’re looking for someone to “take charge” of the project and bring it home, even though this new (Scrum) way of doing projects is new to them.
There are several things that should be noted with this first observation. Sure, it may be valid to put a senior staff member in the center of action for the purpose of showing a good project face towards the rest of the company. However, there are far more subtle dangers lurking behind a decision like this.
- Facilitate, not manage. A primary role for a SM is to facilitate communication between the team members, but never to manage. This difference may be noticed during the Daily Scrum when team members adress the SM instead of the team. A tech lead, or a project key figure in general will easier be seen as manager rather than facilitator in place of for instance one of the developers.
- Facilitate, not solve. Impediments in different shapes and forms often come up during daily scrum, or in between. One of the primary missions for the SM is to make sure that these impediments are removed, but not necessarily by the SM herself. It’s easy for a key figure as SM to get to deeply involved in the solution itself, rather than make sure it’s solved by someone in the team, by someone in the organisation, or someone else entirely.
- Prioritize the team, not herself. If an impediment surfaces, it’s important that the SM prioritizes to solve it, even if that means pausing her own current sprint activities. The team is priority #1 for a SM, so that everyone else can focus on making sprint progress.
- Work for the team, not for herself. The SM must always work to improve the progress and performance of the team, regardless of the impact this has on her own sprint performance.
- People, not technology or design. System and/or graphical design discussions are crucial ingredients to successfully complete any project, in Scrum even more so. When the SM is also for instance the tech lead, it’s easy for the team members to adress the SM for technical design discussions – instead of using other members, or the entire team as opinion. The SM should focus on the people in the team, and leave the technology to “the team”, i.e. collaboration.
- Single point of failure. The SM role in itself is a crucial role to keep the team focused and on track. If this individual is coupled with additional key roles, the team becomes vulnerable to absences, either to sickness or to other teams. It’s wise to spread the team load evenly among the team members.
- You should work with what you enjoy, and you’ll to a better job. Not all people are cut to working with technology, programming or any other role for that matter. This is also very much true for a SM, whose main purpose is to provide an excellent working environment for the team and its members. A key figure within a project is likely to have a thorough knowledge and passion for the area she’s working in. For the same reason not everyone enjoys technology, it’s likely that this individual doesn’t fire on all cylinders when it comes to dealing with people and group dynamics.