Anti-Pattern Name : Death Sprint
Also known as : Overheating; Institutionalized crunchtime; Nonstop featuritis
Software is released iteratively, with the time between cycles being shorter than
what the underlying development process supports. As a result, the project appears
to be a success -- it ships and has the features -- but the quality of
the product, both technically and visibly, suffers. It gets worse with every
Related anti patterns :
- Death March -- Death Sprint and Death March are opposites.
A death march project drags on forever; it seems to take an eternity before
a useful version can be shipped. At best, one or two alpha/beta versions
are released, but they are usually explicitly marked as of inferior quality.
Its failure is visible to everyone, since not a single milestone is met.
A Death Sprint looks succesful, hitting milestone upon milestone;
only the developers are aware of its shaky foundations.
- God Class -- As the pace never slows down, there is no time to
design with, or refactor to industry standard solutions. A common net result is
one or more god classes with a typical haphazard collection of random features.
Sometimes, survivors of a Death March will want to avoid getting trapped
into the same situation, by adopting the Release Early, Release Often
Other times, a team is under pressure from maintenance or sales
contracts to provide updates at negotiated, regular intervals. The
contract may require new features, not merely bugfixes.
Yet another force may be market pressure, a competitor releasing
updates with new features every few months.
What turns the good intentions into a Death Sprint is the omission
of a crucial element that distinguishes Release Early, Release Often
from Hack And Fix. This element is refactoring,
a non-stop focus, as an integral part of the development process, on minimizing the
bug count, on improving the general quality, and on incorporating new
insights in the problem back into the code and design.
Without this focus, a vicious circle develops : new
features need to be added onto a code base that is not really suited
for them. This in turn produces a code base
that is even more resistful to future changes. Inevitably, trade offs
need to be made to keep hitting the milestones; depending on the choices
made, problems can be degraded performance, reliability,
security, or general feature regression.
Since the release velocity is higher than the process velocity,
there are only two solutions : lowering the release velocity, or
increasing the process velocity.
As the vicious circle is very real, every sprinting team sooner or later needs
a hard stop -- a feature freeze to clean things up,
effectively slowing the release speed to zero.
The project is usually too big by this time
to right all wrongs. However, the team can probably anticipate the
mid-term future demands and prepare the project for those. This does not
fix the existing quality problems, but it may at least break the
circle in the next few milestones.
A more fundamental approach is to fix the development process itself.
As shown in Causes, the root problem is an adoption of a
high-speed release philosophy, without using a process supporting
A Daily Build is useless, from a quality point of view, if it is
not paired with a Zero Defect mentality. Awareness and tracking of quality
problems is pointless, when fixing those problems is postponed
until the feature tasklist is empty.
In Extreme Programming, a crucial element is refactoring, to compensate
for minimalistic up-front design. A Death Sprint has the "advantage"
that quality and reliability are already suffering in a major way,
and therefor agressive Refactoring is an attractive way to clean up. This is true even if
there are no resources or time available for unit or functional
testing. There was, after all, no properly working product before refactoring
These examples come down to recognizing, company-wide, that quality
metrics are not only important, but that optimizing for them must be
an integral part of development, not a time-permitting postprocess.