Whenever I think about developing software at a sustainable pace, my right foot flares with pain.

In 2014 I picked up an injury by running too many miles and not sufficiently resting following exercise. Rest periods are when the body heals and adapts. Too much activity without rest leads to injury.

Working at a sustainable pace is a key principle of the Agile Manifesto:

"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Indefinitely is the operative word. "Crunch" periods of late-night feature development and bug-fixing close to a fixed release date aren't sustainable. People will burn themselves out from the stress, and then the company loses their expertise when they leave. Code that is difficult to reason about, modify and verify becomes increasingly expensive to change. Friction slows down the flow of value to the customer and revenue to the business. Sustainable development is a crucial economic factor in the ongoing success of a product.

I've been thinking about how Scrum promotes working at a sustainable pace. The first thing that struck me was the terminology around time-boxed iterations, which Scrum calls "Sprints".

Physiologically speaking, sprinting isn't sustainable. High-intensity (anaerobic) activities cause a buildup of lactic acid and lead to muscle failure.

Given this, why was the term Sprint chosen? As per the Scrum Guide, a team sprints, and then it sprints again and again:

"A new Sprint starts immediately after the conclusion of the previous Sprint."

Jeff Sutherland, co-creator of Scrum, in his book "Scrum: The Art of Doing Twice the Work in Half the Time", explains that:

"We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were."

Sprints in Scrum contain high-intensity bursts of focus and periods of reflection. Although "intensity" and working "all out" do not appear in the Scrum Guide, the author's intent is clear enough.

Reflection

Scrum's periods of reflection are the Sprint Planning, Sprint Refinement and Sprint Retrospective events.

During Sprint Planning, the team collaboratively define the Sprint Goal - the thing to intensely focus on achieving during the next time box. The Developers then plan how they will work to accomplish this. Sprint Planning promotes sustainable development in two ways:

  1. By decomposing items into smaller chunks of work of a day or less in size, progress towards the goal can be meaningfully inspected and adapted during the Daily Scrum.
  2. Developers have the discretion of defining 'how' the work is done, removing the ability for others to force work (and working conditions) upon the team.

Whilst the Sprint Review focuses on inspecting and adapting the product for future Sprints, the Sprint Retrospective focuses on the process aspect - the "quality and effectiveness". Retrospectives offer a forum to raise concerns around sustainable development, for instance, whether quality has decreased (accidentally or deliberately),

The Scrum Framework has a reflect-do rhythm, but is that enough to enable working at a sustainable pace? I don't think so.

Purposefully Incomplete

Scrum describes itself as a "purposefully incomplete" framework of empirical process control, differentiating itself from prescriptive methodology by "only defining the parts required to implement Scrum theory".

Purposeful incompleteness is a blessing and a curse - the Scrum Framework alone cannot enable sustainable development. Constructive ambiguity is at play here. What's missing?

Scrum Requires Strong Technical Foundations

Technical excellence is missing from the Scrum Guide, but reading between the lines, it's assumed and expected.

Developers should be "Holding each other accountable as professionals" - '90s corporate speak for maintaining standards. Regarding quality, Scrum sets an expectation it doesn't decrease during an iteration, instilled through the Definition of Done and refined through the Retrospective.

On-the-ground technical practices, such as Test-Driven Development, refactoring, Continuous Integration, and Trunk-Based Development, aren't explicitly mentioned. Scrum has applicability beyond software and, as a framework, doesn't prescribe methods.

Sustainable Development is on You

Scrum cannot guarantee or ensure that a sustainable pace is maintained. It provides opportunities to reflect on the process and sets rough expectations on quality and professionalism.

I come back to the Sprint Planning section of the Scrum Guide:

"How this (the work) is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value."

What quality means and how the team does the work is entirely on them - that means it's for the team to work out how to work sustainably. If refactoring or maintenance is needed to support a feature, the Developers can establish it as part of their Sprint Planning. They don't need permission from a Product Owner, and it doesn't need prioritising by commercial.

If you, as I do, feel this is an unsatisfying conclusion, then reflect on why that is. There's the Scrum Guide, what it says and expects, and the contrasting experience of Scrum in practice - what Ron Jeffries calls "Dark Scrum" and the issues described in Ryan Ripley and Todd Miller's book "Fixing Your Scrum". As members of the software development industry, our challenge is to be active participants in product development.

We shouldn't be looking to Scrum to answer how we work at a sustainable pace, but ask how we can use the opportunities available within the Scrum Framework to enable sustainable ways of working.