Sprints – Give me a break

An iteration in Scrum is called a sprint ...
Scrum is at least six years older than the agile manifesto ... The Agile manifesto’s principle 8states that “[everybody] should be able to maintain a constant pace indefinitely.”...

How does this compute?

Sprints are related to Scrum

First of all let's re-iterate a well-known fact that often gets overlooked anyway: Scrum is not agile. WHAT? Of course Scrum is an agile Method! But that relationship has a direction. Speaking in terms of set theory what I am getting at is the fact that Scrum is just a Subset of "Agile." Looking at the history of Agile, Scrum is just one of the contributing methodologies that were instrumental in defining "Agile" (via the Agile Manifesto). And in Scrum – if you have read the old book by Schwaber and Beedle – the Idea of the Sprint was "to be able to work un-interrupted towards an agreed upon goal" (paraphrased). With these bounding conditions it makes sense to talk about a sprint, where you look neither left nor right, but focus only on the problem at hand. As long as you are sure that you are able to deliver a “potentially shippable product increment” at the end of the sprint (and not some loosely related artifacts that might be welded together in an upcoming future sprint).
But the metaphor only goes so far – the way I understood it from Ken back in 2005 and try to live it these days – sprinting here mostly refers to the focus on the sprint goal, not to the total exhaustion one would deem acceptable for winning the gold medal at a 100m sprint at the Olympic Games.

Sustainable pace is related to XP

The principle of “sustainable pace” comes – almost verbatim – from eXtreme Programming's definition of this XP "Rule" of set(ting) a sustainable pace. Here the focus actually was on not exhausting ones resources. And no, a resource in this context is not a human being, but a persons mental and physical energy reserves and such – just in the same way a marathon runner uses the phrase “at 35k I just had no resources left.”

All models are wrong - but some are useful!

"Sprint" is a Token, a word that identifies an artifact in the Scrum framework. It happens to be a metaphor as well. Metaphors only translate into different domains so far. As pointed out by the aforementioned quote some models are useful. And to me the Sprint-model is useful with regard to the focus on the next goal, not with regard to the total exhaustion of ones resources.

Your mileage may vary of course, but I think that decomposing the different aspects of the metaphor helps a lot in deciding how to live those aspects in your concrete situation.

So long,
    Michael

Scrum-But or Inspect and Adapt?

For a couple of years now I have heard people condemning projects as “Scrum-But”, mostly without even looking at the projects. And sometimes even without any reference to what they consider to be a scrum-but.

“but” what?

As you probably can imagine after my last two posts, I am especially suspicious if people do that without looking into the scrum guide. I keep experiencing people proclaiming something is a scrum-but because of all kinds of misconceptions. Sometimes “they don't have 2 week iterations” (the scrum guide calls for “a time-box of one month or less”) or because “they don't use Unit-Tests” (the scrum-guide states that “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.”)

While it might be preferable to have shorter timeboxes (as the agile manifesto clearly states: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” [emphasis added] ) and that it is much easier to have a thoroughly tested product if one does have automated tests including unit tests, this is more about common sense (or agile experience) – but definitely not part of scrum.

Apart from the fact that more often than not, the same people carry the battle cry of the agile credo inspect and adapt as a default answer to most everything, there is a certain irony in the fact that nowadays we seem to have a kind of method police around scrum while the first value pair of the preamble to the agile manifesto reads “Individuals and interactions over processes and tools.”

If you do it, do it right

Oh, and don’t get me wrong. If you want to call it scrum: go by the book. But by the right one!
And remember that “Scrum is a framework for developing and sustaining complex products.“). And while on a programming level the “Instantiation of such a [software] framework consists of composing and subclassing the existing classes.”) the fact of the matter is that the same is true for a process framework – you have to define the specifics for your environment to be able to use it!

So – how do you shape your process?

till next time
  Michael Mahlberg