Who should determine capacity of the Development Team? Scrum Master or Development Team?

More recently, I am questioning this practice because I feel that this something the Development Teams can do on their own because they ideally should be self-organizing.

Have you questioned this practice with the people who are coaching it, bearing in mind what the Scrum Guide says? What is their reasoning?

This strikes me as the "Scrum Master as a Secretary" anti-pattern. A Scrum Master, or any agile coach really, is many things to a team - Barry Overeem describes 8 "stances" - being the secretary, note taker, or admin is not one of them. That doesn't necessarily mean that the Scrum Master can't do these things, at least temporarily or as a method of teaching, but my concern is that being too hands-on and doing things that the Development Team should be doing is not only harmful to the self-organization and growth of the Development Team, but limits the ability of the Scrum Master to carry out work that shouldn't be done by the Development Team or Product Owner and to scale with an organization.

Have you questioned this practice with the people who are coaching it, bearing in mind what the Scrum Guide says? What is their reasoning?

@Ian Mitchell, No, I haven't questioned their reasoning because whenever I've questioned some other things I've often kinda been told off. I'm fairly new to the team too, so I am not trying to touch a raw nerve.

I am obviously assuming, it is because they want the Scrum Masters to do something that they can relate to from their previous roles. If they teach that Scrum Master's primarily to observe, coach and uphold scrum, in many people's view it almost translates to the Scrum Master really has nothing to do and so Scrum Masters are taught that they need to do certain questionable practices (the Scrum Masters being coached don't know its questionable).

However, in your opinion am I right as far as what I wrote in my original post? I am essentially seeking confirmation and to see if others have come across this practice in their experiences.

I want to further add that it could also be due to the fact that they don't trust that the Development Team members would actually proactively do this everytime, so let the Scrum Master take the initiative, update JIRA etc. This sentence may open another can of worms which I am already aware of as I type, but thought I'd put this point as well.

Steve, I agree with your reasoning, and the questions/advice provided in response.

The only thing I would add is a response to a statement made in your original post:

I have no objections to a Scrum Master initially teaching a new Scrum Team how to calculate capacity by taking the lead, and also stepping in if he/she observes that the Development Team is doing something wrong.

As a Scrum Master, you should avoid situations where you feel the need to "step in" if you see the team doing something wrong.   This is another Scrum Master anti-pattern (Scrum Master as Hero).



Sometimes, allowing the team to fail is the best possible course.

As a Scrum Master, you should avoid situations where you feel the need to "step in" if you see the team doing something wrong.   This is another Scrum Master anti-pattern (Scrum Master as Hero).

Sometimes, allowing the team to fail is the best possible course.

@Timothy Baffa, I agree, the context I was implying was, a Scrum Master should step in at the appropriate time, not as soon as the issue presents itself (i.e. Scrum Master as Hero). I don't think as a Scrum Master we'd want the Scrum Team to assume they are doing something right and continue doing that or continue to fail indefinitely? They may not necessarily fail but may fail by assuming that they are right and not knowing that they are wrong.

I want to further add that it could also be due to the fact that they don't trust that the Development Team members would actually proactively do this everytime

Agility is built around trust.

Consider one of the Principles behind the Agile Manifesto:

Build projects around motivated individuals. 

Give them the environment and support they need, 

and trust them to get the job done.

Or the Scrum Guide:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.

Or even back to the roots in The Toyota Way, you'll find calls to grow people who live the philosophy, developing people who follow the philosophy, and respect not just for the employees but across the entire network. One of the key principles in The Toyota Way is that anyone can "stop the line" to fix problems and get quality right. This requires an immense amount of trust in people. And there are more examples, too.

Trust is necessary to give up the traditional command-and-control approaches and embrace lean and agile.

Build projects around motivated individuals. 

Give them the environment and support they need, 

and trust them to get the job done.

@Thomas Owens, I don't disagree with this principle or with anything that you've said but what I believe we all must accept to a certain degree is that change is a difficult thing for many. Many are getting on-board not necessarily because they are motivated but because they want to survive (and keep their jobs). I've seen, and heard stories of really bad decisions being taken because of misunderstood and misinterpretated versions of Agile. I think people are in fear than really motivated.

Agile works, Scrum works, I believe in it, but its not necessary that it will be successful everywhere and with everyone.

I don't disagree with this principle or with anything that you've said but what I believe we all must accept to a certain degree is that change is a difficult thing for many. Many are getting on-board not necessarily because they are motivated but because they want to survive (and keep their jobs). I've seen, and heard stories of really bad decisions being taken because of misunderstood and misinterpretated versions of Agile. I think people are in fear than really motivated.

Change is very difficult. But it's even more difficult in an environment filled with fear and without trust. Truly implementing lean and agile methods is a huge shift in how organizations function. And in today's world, you need to be highly adaptive or you risk failing to organizations that are. It's important to overcome these problems in order to be successful, but not all organizations are capable of achieving this.

I haven't questioned their reasoning because whenever I've questioned some other things I've often kinda been told off.

If a Development Team can't even make the capacity assessment described in the Scrum Guide, what are the chances that team members will be able to collaborate and solve a complex problem?

If I was in your situation, I think I would be saying to the coaches: "Please help me. Help me to understand."

I've used failure as a way to learn the importance of at least some basic capacity assessments. I chose not to facilitate a capacity discussion during Sprint Planning because it felt like prying teeth to get the Development Team to actively participate. The team ended up greatly over forecasting the work they could get done during the Sprint because of training, time off, etc. 

When we dug into this during the retrospective the team discovered the impact of not taking into account at least the big ticket items that may impact their time. After adding a retrospective action item to the Sprint Backlog the team had an increased sense of ownership around their capacity assessment and we could improve from there. 

 Steve, since your management is calling it a Scrum Master duty you may be in for an uphill battle. You don't want the team to think you're 'pawning off your work', however, I believe there's definitely an impact to self organization there. If your management is saying that teams should be self organizing perhaps you can start the conversation there. 

I don't think as a Scrum Master we'd want the Scrum Team to assume they are doing something right and continue doing that or continue to fail indefinitely? They may not necessarily fail but may fail by assuming that they are right and not knowing that they are wrong.

Steve, this is a very fine line that Scrum Masters have to walk.   I would be careful labeling something that a team does as "wrong" (or feeling the need to "step in"), since the practice may indeed be acceptable to the team if they are achieving good results from it.

I would argue too that allowing a team to fail (and experience the pain associated with it) creates the right conditions for change.

this is a very fine line that Scrum Masters have to walk.  I would be careful labeling something that a team does as "wrong" (or feeling the need to "step in"), since the practice may indeed be acceptable to the team if they are achieving good results from it.

@Timothy Baffa, Consider the team chooses to skip or even completely avoid a daily scrum, they are all in agreement to proceed this way and irrespective they are able to achieve good results.  Personally speaking, I've got no problem if a Development Team chooses to do this, though I'd accept that, at that moment they are no longer practicing Scrum. I do not want to force them to do this as well. Also, this is an event for the Development Team, so perhaps it shouldn't matter to a Scrum Master as well, right?

Consider the team chooses to skip or even completely avoid a daily scrum, they are all in agreement to proceed this way and irrespective they are able to achieve good results.  Personally speaking, I've got no problem if a Development Team chooses to do this, though I'd accept that, at that moment they are no longer practicing Scrum. I do not want to force them to do this as well. Also, this is an event for the Development Team, so perhaps it shouldn't matter to a Scrum Master as well, right?

Considering Daily Scrum is a key inspect and adapt event for dev team. If not Daily Scrum , then how is the team inspecting their work & progress towards their Goal ? 

Considering Daily Scrum is a key inspect and adapt event for dev team. If not Daily Scrum , then how is the team inspecting their work & progress towards their Goal ?

Harshal, I think that's a great question to challenge the development team with if they wanted to forego the Daily Scrum. It's possible they've found better ways of inspecting their progress for their context but if not, they're missing out on a very key inspect and adapt event.