Or the related question “why do we need a Scrum Master?”
To me this question results from the approach to people that feels that “if you are not busy coding then you are not adding value”.
To many being a Scrum Master is seen as a pretty simple role - they setup and facilitate some meetings, and do other busy work like that (eg update the tool where the team status and burn-down information is).
There is a misunderstanding about the roll of the Scrum Master if this is what you think a Scrum Master is. Scrum is a different way of delivery product / projects and the role of the Scrum Master is a critical part of that. Organizations often implement Scrum by putting “Scrummy” terminology over the things they do today to get something done. This is the cargo cult approach to doing Scrum. The thinking therefore goes “in the past we needed someone to setup meeting, facilitate, make sure the tools were up to date, report status the the powers - the Scrum Master is that role in Scrum”. This misses the point. Scrum is a different way of working. When properly implemented the Scrum Master role is critical to the functioning of Scrum and it a much different role to that of secretary and facilitator.
The basic role of the Scrum Master is described in What is the Role of a Scrum Master?. To me the most import focus for the Scrum Master are also the ones that are the least respected or understood:
Why is impediment removal important? This is how a team actually “works smarter, not harder”. An impediment is “anything that slows you down”. There are two ways to fundamentally increase how fast a speed boat can go:
Impediment removal is about “removing the anchors”. Most impediments that the team cannot address directly will require working the organization which will take a significant amount of time.
How do you justify “coaching”? Doesn't it take capacity away from the team and so means the team accomplishes less. I think the answer to this is “yes” provided you think the development of value is a function purely of how much time you spend on it. But it isn't. People, when coding for example, spend perhaps 90% of their time thinking about the problem and reading the code and so on and only about 10% of their time actually typing on a keyboard. This is the reason that practices like “pair programming” do not drain productivity, but rather often improve performance. The point here is that there is a lot of things going on when a team is working on something that, unless someone is paying attention, the team will not be able to figure out how to improve, since they are focussed on a particular problem they are solving.
Both of these roles of the Scrum Master, done well, have a multiplier effect on the productivity of the team. Imagine that through the efforts of a Scrum Master in removing a particular impediment to the team (say got the hardware for the new test environment) or as a result of coaching (helped establish pair programming in the team) meant that there is a 1% improvement in the ability of the team to deliver value. Here's the thing - that 1% is cumulative. Any time there is similar work, that 1% accrues and accrues. Now lets find another improvement. Another 1/2% improvement. Now it accrues as well.
To put it simply it won't take long for these improvements to result in a significant improvement in the capability of the team to deliver. This is part of how a team becomes “more than the sum of its parts” and many pundits quote things like 2X, 3X and 5X improvements. Think about it this way, by “reducing” the capacity of the team by one person (to establish a Scrum Master role), the overall team performance increase in multiples. That sounds like a pretty good investment to me. See How Do Small Incremental Changes Result in Big Improvements? for more details on this type of thinking.
To me I find it interesting that we are working to set up high performance teams, teams where the output is more than the sum of the individuals on the team but do not see a need for coaching. Now consider a sports team. How many successful sports teams do you know of that do not have a coach? Here's the thing. A coach on a sports team does not just worry about skills of the players but also worries about how they work together to meet their goal, on how to get better game by game, and so on so that the result is a team that transcends the capabilities of the individuals that make it up. In the same way, if we want a software team to be successful (more than the sum of it parts) then we also need to worry about more than just setting up meetings and keeping the tool up to date, and that is where the Scrum Master steps in.