The Scrum Master is demanding a higher velocity during the next sprint. Does the scrum development team have to listen or has the scrum master overstepped?

[featured-image single_newwindow=”false” alt=”Beat Kung | Emc2 | Flickr.com” title=”Beat Kung | Emc2 | Flickr.com”]Beat Kung | Emc2 | Flickr.com[/featured-image]

No, the scrum master has overstepped.  The scrum master is a member of the scrum team – not its manager. The Scrum Master can ask the development team to increase velocity, but cannot force it.

The Scrum Master can only ask because increasing velocity means adding more work to the sprint backlog. The development team owns the estimates and they also decide how much work they can take on during a sprint. Any increase in work – even to increase velocity – must be approved by the scrum development team.

Yes, the development team could deflate their estimates to achieve the same thing. But let’s assume that the scrum master would catch on to that scheme pretty quickly. Let’s also eliminate the possibility of increasing the length of the sprint to increase velocity. The math works, but it’s also an easy gimmick to spot.

Scrum teams are self-managing and self-organizing. The concept of force does not play well in this context.

Let’s pretend for a moment that a scrum master could demand a higher velocity from the development team. Here are possible outcomes:

  1. Decrease in quality:  A team that has an imposed metric is forced to cut corners to meet the new demands. Quality is the first thing to go in these types of situations. It becomes very easy for a team to decide that in order to meet an unrealistic date they must stop writing unit test. Or even worse, that they should stop testing all together.
  2. Increased technical debt:  A scrum team that is under the gun is not likely to make the right decisions. Over time, a series of compromises in quality and architecture will lead to increased technical debt. Ironically, additional technical debt will reduce velocity in the future as the system becomes too fragile and complex to change easily.
  3. Demoralized Team:  Scrum is a developer play. At its core is the empowerment of the development team. Self-organization and self-management remove the traditional command and control levers from software development. Add those back in by forcing an arbitrary velocity and you’ve taken away the scrum development team’s ability to own their work. And along with that their morale.

The scrum master in this example was not acting as a servant leader. Remnants of a command and control structure are still present in this situation. More likely, this is a case where the development cannot do their best work due to impediments that still exist in their organization.

If the scrum master believes that a higher velocity is possible, he/she should ask the team: What can I do to help you be faster?

[reminder]Have you worked on a scrum team with a “command and control” scrum master? How did that impact you?[/reminder]