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 finish with a sprint on the final meters if needed. I agree the pace is already very high throughout the entire 1000 meter race (even the marathons) but they are still far away from the maximum possibilities of a pure sprinter. Long distance runners are certainly maintaining a slower overall pace compared to 100 or 200 meter sprinters.
The Tour de France for example, contains a sprinting competition within the overall tour as well. They are nested within segments with the individual episodes. The goal of the organizers here is to keep the pace of the teams on a certain level. But keep in mind, that the athletes winning the green jersey are not the same ones winning the yellow jersey. Sprinting is related to an explosion of energy for a very short period of time and the pace may be held over the entire distance of an event like in a 100m race. A sprint may also be needed to achieve tactical maneuvers in longer races, but they are, from a race strategy's perspective risky if launched too early and frequently. But one thing is for sure, nobody sprints a long-distance race like a marathon. What happens to the body in sprint situations is that the muscles demand the highest dose of oxygen to perform, and the blood-stream can't deliver. In these situations the body signals a deficit and forces us to breathe deeper and faster to support this increased demand of oxygen. But the volume of pumping oxygen into our lungs is limited. Eventually the muscles get sore and the athlete has to stop or decrease the original pace to be able to continue the race altogether. From a body's survival perspective, sprinting is meant to escape.
Another interesting fact about the original marathon story is the enthusiasm which carried the runner to the town of Athens. Remember, he died shortly after he had delivered his message. No question, this runner was highly motivated and went to the limits, but agile organizations don't want to be so wasteful with their talent. It requires very motivated teams when transitioning to agile. Hyper-motivation may however turn negative over the course of the remaining project. Many organizations adopting agile practicesare not looking for a quick fix, but for a longer lasting positive impact.
Although the runner on the left side has just completed a long-distance race, he looks happier than the sprinter who ran a much shorter distance. Who of the two do you think is more likely to add on a few more meters to run?
Let's see how this affects software projects and organizations using agile processes. We assume that software projects have a scope which requires projects to be longer than 4 weeks in length. Therefore they cannot be seen as a series of sprints in an athletic sense, but need to be seen as time-boxes or mile-markers for long-distance racing. That relates to checking the heart-beat or time at certain points and relating it to the distance in the race.
When we pass those markers, we check, make adjustments and continue in a consistent fashion.
Sprinting and Intervals
If we take the analogy to sprinting literally, we would ask our project team to sprint 100m, take a one second break and try to sprint another 100m in the same pace. We would give the team then another second to rest and so forth. Caused by the extremely short recovery time, the project team cannot fully recover from the previous sprint. The pace of the subsequent 100 meter sprints will gradually get slower. The morale and the quality of the execution will decrease as a result of it. In sports, that is similar to interval training which is exhaustive and for many athletes a drill. Interesting in the terms of the analogy to agile, these drills are often planned and executed under the supervision of coaches. Only a few extremely disciplined athletes are self-managed and motivated enough to perform interval training on their own without external facilitation. That is not in-line with our idea of self-managed teams.
In the same way an athlete would become sloppier in the execution of the sprint over time, an agile team would introduce defects and workarounds to keep the pace as high as possible. Eventually the execution will be so limited, that the team won't be able to sustain the pace either. At that point, the team is burned-out, the technical debt high and the team morale low. Even though the team had an amazing start, it fell behind only after a few iterations. Although we hope our agile team is self-managed and will push-back and manage the expectations, an agile coach could shield and protect a project team new to agile development against outside intrusion and interest.
So, even if we decide to sprint the first few iterations, the team eventually reaches a level of fatigue. Over time, executives may notice that agile development does not work, because they compare the pictures before with the situation after the adoption of agile development. They notice a lower morale which may impact the pace of delivery. As a result, the teams try to keep up with the pace, which requires adjusting the quality parameters, but that will negatively impact the morale again. A vicious circle has been created, which will bring the team closer to hitting the wall.
In reality the problem lies in the over-emphasis of sprinting instead of continuous "incrementing". Runner's actually have aterm for this, called the "steady state" in which a runner feels to be in agood rhythm which could be carried over a long period of time.
Steady state: a level of metabolism, usually during exercise when the oxygen consumption satisfies the energy expenditure and the individual is performing in an aerobic state.
Finding and increasing the steady state, which requires training and experience, will result in little to no interruption between the iterations. That will turn into faster and consistent project delivery. Therefore, it is much more important to incorporate the increments from previous iterations into the overall project strategy. We cannot ignore what happened during the previous iteration, it is part of the history of the project. Therefore an agile project is a series of increments rather than simply time-boxes, but the times-boxes are needed to monitor the progress, quality and morale.
So when we look at organizational agility, we need to measure not only the velocity of the team in early iterations, but also the subsequent iterations making sure we burn-down instead of burning out. To recognize that a team did not find its steady state yet, executives need to visit more metrics than simply velocity. Quality and morale are as important as speed. Quality could be as simple as tracking the open defects, and the morale could be collected as an average vote of the team collected during the retrospective. Especially longer projects will benefit from a moderate but consistent pace in early iterations. Although, "sprinting" may sound like a great motivational pun, it will only carry us for a short period of time. We may hit the wall at the half-way point, as many marathon runners do.
As illustrated above, projects and organizations need to find their steady state in which teams feel comfortable delivering in a consistent model rather than a few quick successes. These projects may be slower in the beginning than projects that sprint, but will have the better endurance and finish early. Isn't that our ultimate goal anyway?
Like runners, teams must have an overall vision and strategy for the race. Each iteration may contain its unique challenges such as environmental factors (e.g. hills, bridges, weather) but also team-based ups and downs. World class runners use these environmental and personal factors to their advantage and include it into their race strategy.
Although many organizations are going full force and are very committed to agile principles they will need to keep an eye on consistency and continuity in the project delivery model. If they are striving for more than a few successful sprints with quick and flashy results, the analogy may not be always appropriate. The interactive industry we are part of provides compelling reasons for faster, higher and further, but it is as important to keep a fresh new look at our surroundings as well. A tunnel vision, a lack of quality and a low morale would not help building the products customers like to see in the future.
We incorporate this learning process into our strategy and adjust. For example, we have learned that many agile projects tend to over-commit and under-deliver in early iterations. Beside the very initial iterations, they do however under-deliver in quality and morale. I am seeking a more moderate approach and focus on under-committing but over-delivering in all parameters equally. Ultimately we would like to find oursteady state and simply "commit" and "deliver".
Next Steps
It is not about replacing the word sprint with iteration or not. It is about managing the expectations of what this term means in your organization. On the one side, a sprint may convey the wrong message in an organization among executives and the team alike. It requires, however, little explanation because everyone knows a sprint is short. It could simply mean, we are "fast", but it could also mean "over-time" or "aggressive schedules". Explaining iterative-incremental may not be as intuitive as the notion of a sprint but if you are looking for a long-term and lasting agile impact, perhaps the marathon analogy helps you find your steady state. If you have good reasons to sprint, consider a longer recovery time in between iterations and projects.
Last but not least, here are few things you may consider. Marathon runners get better with age and experience, they pick-up food and refreshments on their way, communicate with others while running and have great memories to share.
About the Author
Jochen (Joe) Krebs (www.jochenkrebs.com) is the author of the book Agile Portfolio Management and has written several articles about project management and requirements engineering. He is frequently invited to speak at conferences, chapters and organizations. At AOL, Joe is responsible for the successful adoption of agile development as the Director of Program Management.
He founded and spear heads the local chapter of the APLN (Agile Project Leadership Network) in New York City. He is affiliated with the New York University (NYU) where he offers courses related to project management and provides mentoring services. Relevant only in the context of this article, he is a licensed triathlon trainer and has completed several marathons and triathlons. During those events, he did hit the wall in numerous occasions and learned important lessons from it.
