Does Scrum protect your team from burning out?

Scrum… and beyond, episode 1

I believe something is missing in the Scrum Guide. It has to do with anti-patterns like:

A manager pushes the team to increase velocity with 10% every quarter. ‘Because Scrum leads to higher efficiency’. The team doesn’t see other ways to improve, be more efficient. So the team is working overtime more and more.

When they make a Sprint the manager congratules everyone but the team is totally worn down. When they don’t make a Sprint they hear ‘try harder’. It’s a death march.

I have seen this multiple times. This should be a red flag. Or at least warning lights should be flashing.

If this is familiar to you and is it something you see as undesirable, ask yourself if this is applicable:

“No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” — SG

If the answer is ‘yes’: that’s great! Work with the Scrum Team to improve on this situation!

If the answer is ‘no’: this is bad. One of the important prerequisites of Scrum is not being met. This is an impediment. The Scrum Master could bring it to the organization to cause a change which allows the Development Team to self-organize.

The response of the organization depends upon how they read Scrum though.

Sustainable Pace

As I said, I miss a vital aspect in the Scrum Guide: Sustainable Pace.

Sustainable Pace is an important part of Extreme Programming (XP):

“A sustainable pace helps you plan your releases and iterations and keeps you from getting into a death march.” — XP

Sustainable Development is one of the principles behind the Agile Manifesto:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — Principle of the Agile Manifesto for Software Development

Sustainable Pace means that people perform at their best when they are well rested and don’t run the risk of burning out. This includes:

  • Working no more than 40 hours a week.
  • Working overtime can happen, but only occasionally.
  • Short development cycles with frequent releases should take away the typical project crunch time.
  • The collaborative way of working within the team drives the need to recharge at weekends.

The Scrum Guide doesn’t mention sustainable pace. Is this an omission?

Sustainable Pace vs Self-Organization

The Scrum Guide says:

“Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” — SG

This statement and all the other statements on self-organization within the Scrum Guide focus on delivery, efficiency and effectiveness; productivity.

Here is a quote, mentioning a Scrum Master’s responsibility:

“Causing change that increases the productivity of the Scrum Team.” — SG

Again a focus on productivity.

These statements from the Scrum Guide can be misinterpreted as: to force/persuade the team to “go the extra mile”, sacrifice sustainable pace.

Requests for efficiency and effectiveness often are a downplayed version of ‘working longer hours’.

Back to my example: the manager gives the team the goal to increase efficiency with 10% per quarter and lets the team self-organize to achieve this. They feel pressured to worked longer hours as they see no other way. Scrum by the book?

I don’t believe this is the intention of the Scrum. I also believe that anyone that truly understands Scrum will agree with me. But Scrum is poorly understood and poorly implemented more often than not. This is why I like to see the following added to the Scrum Guide:

“The Development Team should work in a sustainable pace which the team can maintain indefinitely”.

One sentence that makes all the difference.

Do you agree with me? Vote for this suggestion here:

Join us on Slack!

We run a Serious Scrum channel on Slack. You’re all invited. Feel free to connect with us on Slack to share your thoughts. Also if you are interested in publishing in Serious Scrum.

Thank you for taking your time to read seriously.

My twitter profile is