One of the key roles on any scrum team is that of scrum master. The scrum master is not the project manager in the traditional sense, but fulfills the role of scrum process expert (or agile coach), guiding the team in all aspects of scrum and ensuring that the scrum framework is being followed in an effective way. The scrum master usually facilitates all of the scrum ceremonies – daily stand-ups, planning sessions and retrospectives, dealing with any impediments that the team are unable to resolve by themselves, while at the same time being a strong advocate of continuous improvement. The prevailing mindset is one of servant leader, facilitating and supporting the team, shielding them from interference and distractions. Scrum teams may quite naturally look to the scrum master as their de-facto leader.
Now whereas scrum teams are intended to be self-organized, this does not mean that team members make all decisions with minimum guidance or involvement of any kind of leadership. Teams with zero leadership will be operating with high levels of ambiguity and stress, and this, for many teams, is likely to result in high levels of conflict about goals and priorities. While the scrum master is not the boss of the team members, he or she can provide a crucial leadership role in helping a team define their goals and then meet them without directing the day-to-day work of the team.
There is nothing in the scrum framework that defines what leadership skills scrum masters need to develop. Learning the mechanics of scrum is easy – in fact you can acquire the impressive sounding title Certified Scrum Master by taking a 2-day seminar, and unfortunately this is all that many of these seminars teach.
There are a number of areas of opportunity for any scrum master to provide a kind of leadership that significantly influences the team’s performance.
- Sprint Goal Setting: Strictly speaking this is the responsibility of the Product Owner. However, many PO’s neglect this critical practice, and the team is left without the focus and prioritization needed to guide daily decision making. The scrum master needs to step in and work with the PO to ensure that the team has a clear set of goals for the sprint.
- Decision Making: An effective scrum master must go out of her way to make sure that everyone on the team is contributing through full participation in team decisions. When a critical decision is confronting the team the scrum master must push to ensure that everyone has a full understanding of the issue at hand. The silent, introvert types (and there are many in the world of software development!) need to be drawn out and encouraged to articulate their perspectives and recommendations. The more aggressive, extrovert types can be convinced to allow everyone on the team to have their views heard. The scrum master can intervene when things get personal and steer the team back to identifying all of the relevant facts and data required to converge on a decision. They can keep the team focused by asking appropriate questions. In fact most of what they say should be in the form of questions followed by words to clarify team member responses to ensure understanding by the whole team. Even if full team agreement is not reached, team members will feel more likely to support a decision and commit to a proposed solution when they feel they have had the opportunity to fully participate in the decision-making process and can see the facts and logic behind it. Sound decision making is based on commitment – even from those who disagreed with a proposed plan of action. Lack of team commitment takes a team in the opposite direction of synergy and is a major contributor to weak team performance. The scrum master as leader, though having strong convictions of her own, can work to ensure that all perspectives have been heard and that all relevant facts and data have been considered, finally asking the team to commit to a specific course of action. In the absence of consensus remember that most decisions are not irreversible, in fact in scrum its OK to experiment with new ways of doing things, and its OK to fail so long as lessons are learned and applied – that’s how teams make progress and improve. If you have strong conviction on a particular direction that the team should go, you might try the disagree and commit anyway appeal (Jeff Bezos). It might be helpful to say: ‘Look, I know we disagree on this but will you take a risk on it anyway? Disagree and Commit?”
- Conflict Resolution: Conflict may simply mean having different points of view. It’s okay, and indeed healthy, for team members to disagree about things – that’s how we get fresh ideas into the open. The scrum master’s job is to ensure that the underlying facts about an issue or some controversial proposal are fully exposed to the entire team, and to push the team to re-assess their positions in light of the facts. The goal is to ensure that conflict is confronted rather than suppressed. The scrum master needs to be able to tell the difference between passion or conviction through expression of strong feelings and avoidance of true feelings by sarcasm, ridicule and so on. These are skills that need to be learned and practiced. As the team digs into the underlying issues, new and better solutions may emerge – true synergy – people working together in an interdependent way to achieve something that no individual was alone capable of. Conflict resolution does not simply mean keeping the peace. A skilled scrum master with good facilitation skills can help a team navigate their way through tough issues and emerge with sound solutions to serious problems while strengthening relationships within the team.
- Team Self-Critique: Some teams do not like retrospectives. They may feel that it is just an opportunity to beat themselves up. Or, if pressured to do them, may simply go through the motions and come up with lists of superficial issues that if addressed would have little impact on their performance. A scrum master can make a huge difference by fostering a climate of candor and mutual trust by being openly inviting and receptive to feedback about themselves. She can work to promote the sense that feedback is intended to be non-judgmental. She can use facts and data to help the team look at their performance: The goal was 100 story-points and we achieved 70, or, the defect backlog goal was zero, we ended the sprint with 12 unresolved defects. What are the underlying causes of failure to meet these objectives, and what can we do differently in the next sprint to meet or improve on those numbers? Are team members avoiding accountability—ducking the responsibility to highlight counterproductive behavior which, again, leads to low standards of performance. It may be occasionally necessary to follow-up with a struggling team member one-on-one outside the meeting if it is felt that personal issues are affecting performance or that an individual is not comfortable sharing their feelings with the team. Open-ended questions like “What difficulties are impeding you accomplishing your tasks”? can be asked, along with suggestions for improvement and appropriate words of encouragement.
Scrum masters in their role as leaders, especially those who may have come from a traditional project management role, need to consciously cultivate skills in indirect influence – that is spend less time explaining and convincing, and more time asking questions and listening. The approach is one of getting a team to figure things out for themselves and deciding on their own plan of action. The leadership behaviors of decision-making, conflict resolution and self-critique can be conducted from a ‘servant leader’ orientation – respect for people and using every opportunity to help people develop.
Agile development has many of its roots in Toyota’s lean production system, which has 2 major pillars:
- The practice of continuous improvement
- The power of respect for people
A leader at Toyota said: “We build people before we build cars”. When people at Toyota talk about “respect for people” this really means fostering a culture where people want to improve, and providing them the tools of improvement. In that sense the 2 pillars are really one: continuous improvement through people.
Planning Poker – Team-based planning and estimating
I strongly encourage teams to make sprint planning and estimating a team-based exercise. Planning Poker is a consensus-based agile estimating and planning technique that offers a great opportunity for team-building and commitment by getting all team members to actively participate in sprint planning. The inputs to the process are a ranked set of user stories. The product owner selects the first story and describes it to the team. The team asks questions which may result in clarifications or elaboration of the intent of the story or its acceptance criteria. Each team member selects a card (a physical card or via a web-based application), typically numbered with a value 0, 1, 2, 3, 5, 8, 13…, from a deck of Planning Poker cards. These values represent the number of story points that the team member estimates for that story. Once the allowed time for the selections to be made is up, the results are displayed to the team. If all estimates are the same, then that becomes the estimate. If there are outliers then those team members share their underlying reasons and assumptions. After further discussion, the team may repeat the process taking the new facts and data into consideration. The process is repeated until consensus is achieved. Here the team has a real opportunity to practice conflict resolution and decision-making based on actual facts and data. This mindset can be developed and applied to other circumstances where conflict and team-based decision making are required.