Scrum Sprint for Quality: The Hare and the Agile Tortoise

The Hare and the Tortoise (or The Tortoise and the Hare, since that is what people told me it was called when I was young) is a fable attributed to Aesop, an ancient Greek storyteller. For those of you who are not familiar with it, a hare challenges a tortoise to a race. The hare, in his overconfidence, decides to take a nap when he gets close to the finish line. The tortoise plods along, eventually passing the hare, and wins the race. The moral of the story is: slow and steady wins the race. Not really what you think of when you consider agility, right? Especially with a book titled, “Scrum: The Art of Doing Twice the Work in Half the Time” being among the most popular introductions to Scrum in publication. The iteration cycle in Scrum is referred to as a Sprint. Does that mean we should be Hares and not Tortoises?

Sprints in Scrum methodology are not meant to be a race. In the January 1986 Harvard Business Review article “The New New Product Development Game,” Hirotaka Takeuchi and Ikujiro Nonaka (credited for creating the product development process Scrum is based on) wrote that the “’relay race’ approach to product development… may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today’s competitive requirements.” According to the Scrum Guide, a Scrum Sprint is a time-boxed (less than one month) iterative event in which a “potentially releasable product increment is created.” In order for a “potentially releasable product increment” to exist, it needs to be architecturally cohesive and have passed the QA process. One of the Twelve Principles behind the Agile Manifesto states it as, “Continuous attention to technical excellence and good design enhances agility.” I can’t tell you how many times I have heard leadership tell teams to ignore QA in order to meet a deadline. THAT IS NOT AGILE! Agile development focuses on quality (working software), even over speed. Slow and steady wins the race.

Another important principle states, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” How long can you run at full speed? At one point in my life I got the running bug and started off with short daily runs that became progressively longer. I ran 5Ks (3.1 miles) and 10Ks (6.2 miles), eventually working my way up to a full marathon (26.22 miles). I got better and better at running over time, and could run the shorter distances significantly faster than when I first started. Even though the time that I could run a single mile improved by 1:30 per mile, I could not sustain that pace for longer distances, and the longer the distance, the slower the pace. There was a “constant pace” that I could run almost indefinitely. Most activities in life are similar. It is possible to “burn the candle at both ends” for a short time to force a quick delivery, but that is not sustainable and eventually leads to burn out.

Notice that even though the Tortoise was slower, he had the tenacity to get to the finish line before the Hare. He methodically worked his way to the end. For a Scrum Team, that includes keeping everyone busy throughout the Scrum Sprint. Shifting Testing Left is critical to increasing speed and saving money, while encouraging the whole team to own quality. Quality issues that aren’t found during development can be exponentially more expensive to fix than if they are discovered early in the process. Some experts set the number at 64X or even 100X. Rushing to the finish line, only to have to go back because customers are unhappy due to the product not doing what it is supposed to is just like the Hare stopping to take a nap. Slow and steady wins the race.

Esse quam videri,

John