Beyond agile project management
where agile software development meets the messy middle 2026-11-03 #agile
Many objections to using Scrum for software development reduce to complaints that Scrum doesn’t solve all management problems. As well as missing roles, Scrum gives teams a way to start software development, but eventually fails to support medium-term planning.
Sprint fatigue
Naming’s famous difficulty includes the risk of adopting a metaphor that brings unintended meanings. In the case of Scrum’s sport metaphors, this includes The Sprint:
Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
This conflicts with what we mean when we talk about sprints in sport, which do not feature starting a new immediately after the previous one finishes, indefinitely. Unfortunately, some people (managers) want to believe in a continuous crunch mode, without a corresponding interpretation of resting between sprints, and teams end up with sprint fatigue.
Sustainable development
Teams that escape sprint fatigue often take encouragement from the Manifesto for Agile Software Development’s ninth principle:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The team can use their retrospective to agree any improvement, which includes removing sprints from their development process. Instead of pushing a sprint backlog onto their ‘board’ every two weeks, they adopt a Kanban-style pull system that continuously feeds development.
An efficient team might systematically remove inventory waste until they have no more than a week’s work planned, at any time. However, this diminished time horizon and its corresponding increase in agility reduce the team’s sense of direction.
The messy middle
In Messy Middle, John Cutler imagines decomposing work into what he calls a ‘spectrum of work decomposition’:
1–3 hour task – to do, instruction
1–3 day story – user task, user story, workflow increment
1–3 week bigger story – experiment, leading indicator, behaviour change
1–3 month small/medium bet – customer outcome, optimisation, redesign
1–3 quarter large bet – business outcome/benefit
1–3 year foundational work – market/landscape shift
In this model, the lower end (1–3) of each time unit corresponds to different units of work at familiar scales. Cutler explains that while teams tend to know what they’ll probably work on for the coming hours, days and weeks, and maybe have shared understanding of the next few years, he calls the next few months or quarters the messy middle.
Outcome-based planning
Project management frameworks, such as Scrum, don’t handle the messy middle, because the concept of project includes a defined end, in terms of scope, goals, and total time constraints. Software development that continues ‘indefinitely’, to quote the agile manifesto, requires a different kind of planning.
Working from sprint-to-sprint or task-to-task only works as long as you haven’t finished building the first version of the product, or adding missing capabilities to a minimum viable product. Eventually, this medium-term loses definition. The messy middle needs outcome-based product management.
