Iteration or Sprint: Sometimes, Words Matter
It’s probably a little pedantic to argue about terminology used for a time-boxed process to deliver software, but hear me out.
For most teams following an Agile process, that time-box is called a Sprint. It’s meant to convey that the team “sprints” during a short period of time to solve story problems. By the end of the sprint, the team has not only delivered business value, but they are then ready to do it again, and again.
Where’s the problem? Would the term “iteration” generate as much visceral imagery? Does it convey an intended reality or motivate a team to stretch or push themselves? Does it have an impact on how we think about iterative development? Is there an expected change to the development culture?
This article is an opinion piece hoping to get you to think differently about iterative development. Words sometimes matter because they drive how we think. Terminology that drives imagery can have a powerful impact on not only how we think, but can also influence what we can think about.
The Sprint
The term “sprint” comes from running as hard as you can for a short amount of time. It‘s often used in reference to sports, whether racing or even team-based sports, such as football, basketball, soccer, etc. It’s used in software development to motivate engineers to work hard and quickly solve specific problems and deliver real business value.
However, one of the core principles of Agile development is:
A “sprint” is not a sustainable pace.
Obviously, the use of the term “sprint” in context of developing software isn’t meant to imply that the developers work so hard that they can’t sustain the pace. However, because of the use of the term, it’s easy for developers and stakeholders (especially management) to fall prey to the imagery in such a way that pushes developers this direction.
Competing Commitment Philosophies
There are two basic philosophies that I’ve run across when it comes to planning and executing iterative development cycles. These two philosophies have to do with the expectation of delivering on the committed stories during planning. For the purposes of this article, I’ll label these two philosophies as “Commit” and “Stretch.”
The “Commit” philosophy has the developers select the set of stories that they can reasonably commit to delivering within the iteration. The expectation is that by the end of the iteration, all stories have been completed. If there is extra time, additional work can be addressed to prevent the team from becoming idle.
The reasoning behind this philosophy has to do with the perception that a commitment is motivational, itself, and will drive behaviors to succeed. Success breeds success.
However, this philosophy is typically dismissed due to the concern that developers will pad their estimates in order to easily complete their commitments.
The “Stretch” philosophy has the developers select the set of stories that they can reasonably deliver, but adds more to “stretch” the team. In this philosophy, there’s a good chance that the developers won’t completely deliver all of the stories, but there’s also a chance that they will, if they “sprint” hard enough.
The reasoning behind this philosophy is that by pushing the development team to over-commit, they will work harder (“sprinting”) and achieve more than they thought they could. Missing a commitment isn’t necessarily bad, so it’s commonly excused (or lightly punished).
However, this philosophy ignores the common response to over-commitments: if there is little punishment for missing the commitment, then there’s little motivation to work harder to achieve it, especially since it’s considered a stretch in the first place (i.e., comparing the pain from punishment to the pain of working harder).
In a way, the perceptions of these two philosophies can come down to the level of trust that management has with their engineers. If you trust your engineers, pushing them isn’t necessary, since you believe they have other motivations. If you don’t trust them, you’re more liable to push them and not trust that they are working with a sense of urgency.
What does this have to do with using the term “sprint” versus “iteration?” Because words can drive the way we think, we should take some care about how we describe the process we follow. “Sprint” means running fast, while “Iteration” is just a general term for a particular time-box among similarly sized time-boxes.
What do you expect a team of developers to do during a Sprint? You expect them to work hard to deliver all of their stories. What do you expect a team of developers to do during an Iteration? You certainly expect them to deliver their stories, but you might also expect them to do other things, such as handle production issues, learn about the tools, languages, libraries, and frameworks that they are using to deliver those stories, or even to take a break and chat at the proverbial water cooler.
I’ve worked with developers who had such an urgency to deliver that they didn’t pause after accidentally solving their build issue to learn what really solved it. I’ve seen developers so pressed for time that they didn’t attend their company’s social gatherings, or get to know their team better, or spend some time learning a new technology that the team was going to use on an upcoming project.
The Jar
There’s an analogy that I like to use when describing an iteration. An iteration is a jar and the stories to be worked on are different sized marbles to be placed within the jar. A full jar of marbles represents a commitment to deliver the identified stories (the marbles in the jar).
There’s a problem with this analogy. There is still lots of space in the jar. So, I introduce sand. Pouring sand into the jar fills the remaining space. This “sand” represents the “other” things that get done during an iteration. It may just be meetings, breaks, or other activities. It might also represent the possibility of dealing with a production issue, or spending some time learning, or addressing a small amount of technical debt, etc.
You may make the accusation that the sand represents the “padding” referenced earlier. In a way, that may be true. However, without that sand, developers might burnout, not learn when they need to, or be able to address the common interruptions that typically occur. Worse still, that sand might represent your developers taking the time to help and teach each other. Without it, they may be less interested in helping others as they focus on their own deliverables so that they don’t get in trouble if their stories don’t get done.
Conclusion
Success breeds success. The words we use can impact our ability to think in particular ways. I use the word “iteration” because I trust my developers, and I want them to become the best that they can be and to deliver great software at a sustainable pace.
