With more and more scrum'ing and sprinting going on in agile development, let's reflect on the analogy made between Scrum and sports before we take a look at what misunderstandings it may cause within organizations transitioning to agile development practices, in particular Scrum.
Long Distance Running and Agility
A marathon is one very exhausting long-distance running event. The race is roughly 42km (26miles) long and has its origin in ancient Greece. In 490 BC, a Greek messenger delivered the news of the victory over the Persians in the battle of Marathon. According to the story, he ran from the battlefield in Marathon to Athens, announced the victory and died immediately after. The marathon distance became part of the Olympic program and eventually more mainstream with the offering of large city marathons in recent years. You might ask what does this long-distance running event have in common with agile development? In a nutshell, agile focuses too often on speed and "sprinting" and less on a sustainable pace in harmony with a 40 hour work week. Agile projects are in reality more like marathons rather than sprints. The analogy has a twist.
For example, when organizations invest into agile developments, they usually expect higher productivity, an increase in return-of-investment or faster speed to market. These values are often sold by agile consultancies and product vendors to establish a business case to organizations. This is a fair deal, because statistics prove that agility is directly linked to these benefits. But if an organization has tunnel vision on speed and ignores other parameters, serious damage can be done to the organizational morale, quality and eventually even the speed itself. For example, if the sprint (speed) goals are met, but quality of the deliverable and the team morale have suffered, the project is out of balance. The lack of quality will increase the technical debt and the morale will impact even the speed itself. Treating quality and team morale on the same level as speed, the project can be assessed holistically. These phenomena can be directly linked to long-distance running when runners experience the syndrome of "hitting the wall". That syndrome is often a result of too high of a pace in earlier stages of the race and an issue we want to prevent on an organizational level. So, let the games begin:
Iterations, Sprints and Increments
Agile is based on iterative-incremental development, a technique in which a long project schedule is broken down into smaller time-boxes (iterations). Certain requirements are dedicated to an iteration and turned around as software at the end of the time-box, which is usually between 2-6 weeks in length. The "mini-releases" at the end of the iterations will build and integrate with the release from the predecessor. The progression and growth of a system in this fashion is also called incremental development. These releases may be made public (launches) or used for internal checkpoints, to close the feedback loop with stakeholders.
Scrum for example is a term borrowed from Rugby to describe a specific tactical approach in a rugby play. In addition what is known as an iteration is called a "sprint" in Scrum. The word "increment" has been de-emphasized in the midst of all the terminology adjustments. So, when we craft analogies to athleticism we need to make sure we communicate and interpret them on an organizational level consistently. Many executives however do know sports better than Scrum which may cause misunderstandings. By simply referring to "sprints" instead of iterative-incremental development we may have created a huge problem. Let's see why:
No runner sprints the marathon, not even short segments of it. Although, the marathon is an extreme example, the same is true for other long-distance endurance races such as 10K, 5K and 1,000 meter races. Yes, even 1000 meter races are tactically divided into several smaller segments, and may