Even if you have learned that there is no project manager on a Scrum project, that does not mean that there is no management, or especially, leadership on a Scrum project. This misconception was corrected in a discussion by Mike Cohn posted Aug 25, 2009 on InformIT. You can find that article at www.informit.com/articles/article.aspx?p=1382538.
Unlike the traditional command and control environment, management responsibility is now split among the three different components of the Scrum team: the ScrumMaster, the development team and the product owner. Although the ScrumMaster and the product owner do not directly manage the team, they are responsible for project reporting to the management of the business. This is true, according to Ken Schwaber in Agile Project Management with Scrum, even if we no longer report by tasks on a Scrum project but only by requirements.
Anyone can be considered a leader on a Scrum project as long as that person has some influence over the team. To the surprise of some purists and our delight, in his blog, Mike Cohn mentioned product owner, ScrumMaster, and even functional manager, as examples of leaders who can influence the direction and success of a Scrum project, and we wholeheartedly agree with him. See his blog at http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team.
But to paraphrase what Mike Cohn wrote on his blog, there is more to leading a self-organizing team than buying food or letting the team do what they want. Leaders on a Scrum project should influence teams in an indirect way, and that is what we address in this chapter.
Last but not least, people often compare management with leadership as if they were opposing one another. We think they complete one another rather than oppose, and this is why we think of them as being two halves of a round circle, as illustrated in Figure 11.1. No side is better than the other, and they are often intertwined.
Like Peter Ducker, the late management guru, said, “strategy without execution is only a vision.” We would say leadership without management is like having a strategy without being able to execute it.
Applied to Scrum, this means that the ScrumMaster and the product owner should not hesitate, even with a self-organizing team, to exercise their leadership and management skills in talking to the development team, should they feel that the project is not progressing as it should or the team is not performing as it should.
Things become more interesting when you realize that they have to exercise these skills with subtlety, and indirectly, both with the team and with people outside of the team, but who can influence the team’s performance (Figure 11.2).
What Figure 11.2 conveys is that there are two sides to the product owner and the ScrumMaster’s project management and team leadership roles: one facing internally toward the team and the other facing the external world.
Traditionally, people took the position that the ScrumMaster should protect the team from disturbances coming from outside of the team, including from the product owner who may come to the team, during the sprint, to ask them to take care of some new requests.
However, with practice, it has become clear that there are instances where the product owner is not the business manager of a business unit but someone who has to work with different business units and who has to resolve sometimes conflicting priority between these units.
This is to say that the product owner may need, in some cases, to push back the different business units, in order to protect the team, when it comes to new requests these business units may want to introduce in the middle of a sprint. This is when the product owner truly acts as a servant-leader, assisted in this role by the ScrumMaster, trying to protect the team from outside disturbances.
Even though our discussion that follows is somewhat different from the CDE (Container, Difference, Exchange) discussion on how to lead a self-organizing team in Mike Cohn’s excellent book, “Succeeding with Agile Using Scrum” it does share a common premise with Mike Cohn’s book in that the Scrum project team requires quite a bit of management and leadership to work, contrary to popular beliefs.
To better understand the management and leadership role of both the product owner and the ScrumMaster, let’s review the internally facing side, as shown in the quadrant of servant-leadership in Figure 11.3, and see what their different aspects are and what the product owner and ScrumMaster could or should do to help improve the team’s progress toward the project goals.
Vision: This is what the product owner role is most known for—being responsible for the product vision, goals, and business requirements. By asking probing questions, the ScrumMaster can help the product owner formulate his or her vision and identify the product goals more clearly. Having a clear product vision will help the product owner answer any questions the team may have regarding business requirements and the product direction.
Supporting: This is something both the product owner and the ScrumMaster are there to provide. Normally, the ScrumMaster’s most known role is to help remove impediments and assist the team in understanding the Scrum process, but removing impediments is something the product owner could and should also help with when it comes, for example as indicated above, in resisting business people’s pressure to have team members work on a new item that was not planned for the current sprint.
Guiding: By this, we mean the ability for the ScrumMaster and the product owner, two of the three types of leaders Mike Cohn referred to in his book, to exert a positive influence on the team, either to promote more collaboration or a better performance.
Mentoring: Whenever possible, the ScrumMaster and the product owner should not hesitate to share with the team what they know in order to help team members become even better at what they do, especially when the product owner and ScrumMaster happen to be experts themselves in those areas.
Coaching: One of the least practiced aspects of management and leadership in the traditional command and control environment, coaching is a technique the product owner or ScrumMaster could and should often use to unleash a team member’s potential.
Now that we have reviewed the different aspects of the internally facing side of team leadership, let’s turn our attention to the externally facing responsibility of the ScrumMaster and the product owner and see what they should and could do to help the team with the external environment, namely with the team’s direct management and with other outside stakeholders. On top of what the product owner and the ScrumMaster can do to support, guide, and coach the team, there is something else, which is as important or even more important, they should do to provide the team with the most critical condition for great teamwork: namely, the job safety factor as mentioned in Chapter 10.
Figure 11.4 captures this kind of intervention the ScrumMaster and the product owner should do, for instance, with the team members’ functional managers by explaining to them what Scrum is and why team members should not be punished for refusing to work on any ad hoc issues that could interfere with their sprint work.
Coaching for Superior Performance: The GROW Model
A well-known technique for coaching, one of the preferred techniques used by servant-leaders to enhance a team member’s performance, is known as the GROW model (which stands for Goal, Reality, Options, and Will). This technique can be used by anyone and requires no special training. It is known to provide a very structured and effective approach for employees and managers to establish goals and identify ways to work toward achieving them.
Every coach has his own way to coach but what follows is an example of how a coaching session can be structured using the GROW model, which we extended with a new stage (Results) in order to provide an opportunity for continuous improvement.
Goal Establishing: First, help your team member define his goals. To do this, you can use the same SMART technique that was discussed in Chapter 4, “A Visual Requirements Gathering for the Product Backlog.” With SMART (Specific, Measurable, Achievable, Realistic, and Timebased) the goal can be achieved within a given timeframe.
Examine (Current) Reality: Next, ask your team member to describe his Reality, meaning the current reality he lives in. This is an important step. Too often people try to solve a problem without fully considering their starting point, and, therefore, often miss some of the information they need to solve the problem effectively. As the Chinese proverb goes, if you do not know where you are, no map can ever help you know how to get to where you want to go. As your team member tells you about his Current Reality, the solution to his problem will begin to emerge.
Explore the Options: Once you and your team member have established the Goals and explored the (Current) Reality, it’s time to explore what is possible—meaning, all the possible options you have for solving the problem. Resist the temptation to do this by yourself. Instead, help your team member generate on his own as many good options as possible, and discuss them with your team.
Let your team member do most of the talking and offer ideas first. Then suggest your ideas.
Establish the Will: By examining the current Reality and exploring the Options, your team member will now have a good idea of how he can achieve his Goal.
That’s great but it may not be enough, so your final step as coach is to get your team member to commit to some specific actions. In so doing, you will help the team member establish his or her will and motivation to improve.
Review Results (extended by us): By reviewing the results he achieves against the established goals, you and your team member will be able to identify gaps and what needs to be done to improve his performance.
For a useful example of the GROW model, imagine that you plan to make a trip.
First, you start with a map to visualize where your team wants to go (Goals) and identify where your team currently is (Current Reality). Then you explore various ways (Options) your team can make the trip. Finally, you will help ensure that your team is committed to making the trip (Wills) and is prepared for all the conditions and obstacles they may encounter on their way. As they progress on their road toward the destination (the established goals), you should remember to review their achievements (Results) regularly in order to identify gaps and actions they may need to take to put themselves back on the right track until they reach the final destination (Goals).
Traits of a Caring Leader and Manager
Before moving further ahead, let’s say that in order to be a good leader or a true manager, we think you should be:
Honest: Honest means that you should say what you do and do what you say. This also means that when you make a mistake, you will not hesitate to admit it. Because no one is perfect, people will not hold a grudge against if you sincerely admit your mistakes; on the contrary, they will respect you more for your honesty. And if people respect you, they will be more likely to follow you than someone they do not respect.
Open: One of the most important character traits of a leader is to be open to people’s ideas and opinions. Do not shut down any suggestion coming from the team or from people around you without first reviewing its merits.
Authentic: This means that you should not try to behave in a way that is not true to your values and beliefs. In other words, you do not try to play games by pretending to be someone you are not.
Available: We are all busy in corporate environments, but as a leader people expect you to be available to give them advice, listen to their concerns, and to give them feedback or clarification about something they do not understand well. So, adjust your calendar if you have to, but try to make yourself available to sit down with team members for at least a short talk before you find out if their issues or concerns would warrant any further clarification or meeting. As a servant-leader, you should keep your door open as much as possible to signal that even though you may be busy as a leader, you are always available to support the team.
Caring about others: In a society where success and promotion are key words, it may be hard to ask you to care about others. But when you think about it, it is ultimately your success that you are taking care of when you help your team members succeed at what they do. So, when worse comes to worst, do try to think of taking care of the people you work with. That can only help you become even more successful. But if you are also a true servant leader who cares about people without always thinking about your own benefits, then that can enhance your image as a leader and a good human being.
The fact that the Scrum development team is self-organizing does not mean that there is no project management or leadership on a Scrum project, as is often the misconception.
Unlike the traditional command and control environment, the management responsibility is now split among the three components of the Scrum team: the ScrumMaster, the development team, and the product owner.
As far as leadership goes, anyone can be a leader as long as she has some influence over the team, but the people who we think can exert a lot of positive leadership over the team are mainly the product owner and the ScrumMaster, two of the three main types of what Mike Cohn referred to as leaders in his book, Succeeding with Agile using Scrum.
In order to sum up the different aspects of leadership along with techniques, which the product owner and the ScrumMaster could use, a quadrant of servant-leadership was presented, which has five components, namely vision, support, guide, mentoring, and coaching.
While most of these leadership aspects are somewhat well known, coaching is still relatively new, at least in software development. This is the reason we went into more detail on coaching in this chapter and, in particular, on the GROW model, which we extended with a new stage (Results) to provide an opportunity for continuous improvement as a support for the idea of continuous improvement in Agile.
To round out our discussion on management and leadership, you were also reminded in this chapter that the product owner and ScrumMaster should possess the following qualities to be good leaders and managers: (1) honesty, (2) openness, (3) authenticity, (4) availability, and (5) caring (about others).