Traditional ALM is a predictive process that tells us to continuously manage software’s governance, from conception...
to grave. That includes all aspects of software development, including (but not limited to) requirements, architecture, coding, testing, release and defect management and so on. That all sounds great. But the devil is in the details. How exactly do we get started? How do we gather requirements and how many do we need to gather? This tip examines how iterative development helps software teams to get the right requirements at the right time.
How much detail is necessary?
The funny thing about requirements is that it is easy to gather too much of what we don’t need because there’s always more detail we can add. For example, at the beach, we can say that we have a pail of sand. Or a plastic container with a plastic positional handle that has a capacity of 30.28 ounces filled with silicon dioxide granules of dimensions varying from .01” to .1” with a uniform distribution. Maybe we should add that the silicon dioxide has a molecular weight of 60.0843 g/mol, a melting point of 1427°C, and a density of 2.634 g/cm3. We could easily go on and on.
Do more requirements matter? Agile tells us that more requirements up front don’t really help. For the garden variety of questions, such as “what are you carrying?” an answer like “a bucket of sand” is quite enough. Then, should we need more questions answered to create the application, we ask them, such as “Is the sand wet or dry?”
Just-in-time requirements are the Agile way
Remember what separates an Agile mindset from more traditional ALMs: requirements are never just gathered up front and processed. We ask just enough questions as are necessary to get started on the right foot. Then, as new questions come up that require elaboration, we iterate on the questions, and get the answers from the people who know.
A traditional ALM tells us to gather as many requirements as we can up front. However, many of those will be obvious to everyone, and that’s an unnecessary waste. Likewise, when we spend an enormous amount of time documenting requirements for something that’s not quite what we needed to understand, that’s time and money wasted. And when we change our minds after gathering an enormous amount of requirements for something that we decide is no longer what we are interested in, that’s a waste as well. That’s why just-in-time requirements elaborated iteratively are the Agile way. Gathering requirements in this fashion is not only different than the traditional process, but it’s a lot better because it’s a lot cheaper.
Iterations allow for midcourse corrections
The concept of iterations plays deeply in Agile, especially in the commonly used Scrum practice. Why should that be? What good are iterations, when we really just want to “get it done right the first time”? The answer is that very little in life can get done exactly correctly the first time. For example, when intercontinental ballistic missiles are developed, money is no object. Success is measured in accuracy of landing and the destruction of an opponent’s targets at that location.
Yet, no matter how much money you spend on extreme precision engineering and materials, landing a missile travelling at ballistic speeds through the stratosphere 10,000 miles away from where it was launched just doesn’t work without frequent midcourse corrections. That’s exactly the same problem we face with software development! We may know up front exactly what the end state looks like: the requirements. But even if we carefully point and light the rocket, we are bound to fly off course later. And we don’t want to find out that we’re 100 miles away from the target, coming in at ballistic speeds, with one second left until impact. Because at that point, there will be no force on Earth that could put us back on track.
Yet many traditional methodologies tell us to do exactly that. They tell us to find our exact requirements up front, plan our work, then work and track against our plan. We don’t want to be a week away from release and realize that our requirements are not what’s really desired in the application. Because at that point, there may be no force on Earth that can get our project back on track. Iterative development is much like the frequent midcourse corrections on the missile. These corrections make the journey to the endpoint seem easy, because anytime we drift off course from requirements that may have been unclear when we started, or we get blown sideways from a wind gust at 40,000 feet, we simply make a small correction and get back on course.
This iterative aspect is the reason that in Scrum we normally make iterations of two weeks, and keep in frequent contact with the project’s stakeholders. It’s usually far less costly to fix a small mistake early than it is later. That’s why we make those minor midcourse corrections frequently, just like the missile.
The importance of the timebox
Iterative development in an Agile methodology has one other aspect worth mentioning -- that of the timebox. In Agile Scrum, when we define a two-week iteration, we mean it. We don’t allow things like “Oh, we’re really close on finishing this feature, so give us an extra week,” or “Well, Fred was sick for two days, so we should extend this sprint by a day, at least.” Two weeks is two weeks.
If the team doesn’t make its commitment on some story, there is no partial credit for that sprint’s velocity. A story that is not accepted by the product owner just doesn’t count for the team’s velocity. Does that seem harsh? I think of it more like tough love. If I’m a teacher, I don’t do my students any favors by telling them, “Well, I know that the term paper is due at the end of the term, but since you are asking me for an extension, well, that’s OK.”
By sticking to the timebox, we increase the odds that we will actually accomplish what we set out to do on schedule. And, since we are setting the hard expectations for a sprint only two weeks in the future, the odds of meeting them will be much higher than if we set the hard expectations for a project completing 10 months or so in the future. The psychology of the timebox is easy. When the end is 10 days away, there is so much less temptation to meander around thinking and philosophizing a potential solution than if the end is 10 months away.
So, don’t worry about what your friends might say. If iterative development makes sense to you (and it should!), then take the chance and implement it as part of your ALM. You’ll be glad you did.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.