Let’s face it: People skills is not an area in which the software development community has traditionally excelled. The very traits that can help a developer excel at technical problem solving can often make him or her challenging to work with day to day. For a lot of ScrumMasters, this is by far the trickiest part of the role. It is also by far the most important. A ScrumMaster who doesn’t work well with people, and get them working well with each other, is a ScrumMaster who is not serving the team well.
To truly master Scrum, and to realise its great benefits, you must do more than gain a detailed knowledge of the theory and best practices. You must become a master of working with people. Unfortunately, these skills are almost never taught in school or college. They can take years of hard work and experience to master.
The skills and qualities of a great ScrumMaster are too numerous to list here. However, below are five areas that I believe the ScrumMaster must nurture if the team is to be successful:
Trust
Without a culture of trust, there is no chance of success. Individuals need to feel that they can highlight issues and impediments without fear of being attacked. Only when these are being freely raised at the stand-up and during sprint retrospectives will they be dealt with in a timely manner, allowing the team to improve its velocity and productivity.
All too often, developers come from a background of having been beaten up by the project manager for not delivering. Scrum teams should be a safe environment in which people are free to talk. The ScrumMaster must encourage this and not allow finger-pointing or blaming to become a feature. A team will work best if everyone on it feels that everyone else is on their side, working toward the same goal.
Leadership
While Scrum teams may self-organize, this does not mean that they don’t need leadership. Leadership in Scrum doesn’t mean telling people what to do and making sure they do it; that’s management, and bad management at that. Leadership can come from anywhere on the team. Technical leadership, for example, can come from an experienced developer who wishes to help the team benefit from his experience. The testers may have some great ideas for how test coverage can be improved. The ScrumMaster must encourage people to bring their knowledge to the team and share it. This is inspecting and adapting in action, and the team is poorer without it.
The ScrumMaster takes the role of leading the process and fostering Agile principles. Leadership for the Scrum Master is often a case of resolving conflicts, bringing people together and helping them reach consensus. The ability to influence is much more important than being in a position to dictate. If the team doesn’t buy into a decision, however good it may be, it will not work. Coaching plays an important role here too, during the early stages. As teams mature, they should need less and less guidance on how best to get things done.
Communication
Transparency is a key aspect of any empirical process. There should be no secrets, nor should information sit with just one person. A Scrum board can help here. An outsider should be able to walk by and understand exactly the state of the sprint. She should see the sprint goal, what’s “done” (and what “done” means), what’s in progress, what impediments exist, and whether the team is on track for a successful sprint. Transparency is the best disinfectant. The ScrumMaster must facilitate a culture of openness. Bad news must not be hidden, and surprises are a no-no. This also builds trust.
There’s no substitute for face-to-face communication. A good ScrumMaster is constantly talking to the team, and to the product owner. He should encourage the team to do the same. I’ve seen issues go unresolved for days because an email was missed. Talk, talk, and then talk some more. If you want a job that involves sitting on your own and crunching the numbers, become an actuary.
Teamwork
Scrum teams are one team. They succeed together, they fail together, and they improve together. Developers are as responsible for quality as they are for delivering the code. Testers are as responsible for helping with the development as they are for finding bugs. There are no silos in a cross-functional, collaborating team.
Motivation
Ideally, Scrum teams will be self-motivated. The thrill of delivering value to the customer every few weeks will fuel this, especially if the team is moving at a sustainable pace. From time to time, however, it may be necessary to motivate certain individuals. This can be done by providing some vision of the product and how the customers will benefit from the work being done. Success breeds success. The more value is delivered and more benefits realised, the more the team will want to deliver. The more the members feel like a team, the more they will want to help each other succeed. It is that feeling of team achievement and ownership that makes people go the extra mile rather than completing their part and sitting back. Imposing unrealistic, arbitrary deadlines will not make people work harder. Letting them own the process of delivery will.
Conclusion
A detailed knowledge of the theory of Scrum and a background of technical excellence is a great start. It is necessary, but it is not sufficient. You must also gain the qualities discussed above and exhibit them on a daily basis. This is an area in which constant inspection and adaption of your own behaviour is a must. What works well? What doesn’t work so well? Read some of the myriad books out there on the so-called soft skills. Find that person who seems to have a natural affinity with others, and learn from him or her. Great leaders and communicators come from all walks of life, and they are rarely born that way. These are skills that can and must be learned if you are to truly succeed with Scrum — or any other area of life