Iterative Development

Foremost, the defining characteristic of iterative development is executing each phase of the traditional software lifecycle in shorter periods of time, multiple times. I've seen many teams fake iterative development where earlier iterations involve requirements elicitation with little or no development. Slice it and dice it any way you'd like, but this is not iterative development. That's waterfall, and waterfall does not work. True iterative development aims to grow software incrementally, where each iteration produces a new version of the software with more features. That sounds like agile, but can still result in a process that is no more agile or successful than waterfall.

Agile Is Always Good

There is a certain amount of FUD (Fear, Uncertainty, Doubt) surrounding agile development. Some view it as a group of developers run amock, out of control, with no clear direction. No. That is not agile development. That is chaos. Yet others consider agile an overloaded term that has lost much of it's original value. While agile is only a term, the principles and practices espoused by agile are critical to software development success. The term agile has only been used in our industry for a few years, but the ideas espoused by agile have been applied by teams getting it done for decades. Others view agile as a process. Scrum, XP, Crystal, or any other Agile process. No. Processes enable and encourage agility, but they are not agile. Some may believe that agile makes software development easier. Absolutely not. Software development is hard work, and nothing is going to take away it's essential complexities. Agile makes software development correct, but it's still very difficult.

Agile is not chaotic. Agile is not new. Agile is not process. Agile is not easy. But agile is always good. Agility is defined by a team's ability to respond to change quickly and speed delivery of functional and low-defect software. More frequent delivery enables testing, encourages feedback, and isolates problems earlier in the software lifecycle. Agility requires the right mix of practices, infrastructure, technology, and team. Increasing this ability is always a good thing.

Iterative != Agile

Some may argue that I'm pointlessly arguing semantics here. That iterative development done right is inherently agile. But software development done right is naturally agile, and I doubt anyone can argue that there are many teams that aren't getting it done. So there is an important distinction between iterative development that isn't agile, and that which is. Why? Because I've seen teams going through process transitions in an attempt to bring more efficiency to their software development efforts. In most of these cases, teams are adopting iterative processes, yet feel compelled to maintain a high degree of ceremony surrounding that process. And it is possible to maintain ceremony using iterative processes. But ceremony and agility cannot coexist, and this is an important distinction. Below are six common aspects of iterative development that inhibit agility.

Agile development conforms process to people, whereas non-agile iterative development conforms people to process. Of all, this is arguably the most significant. Forcing people to conform to process is ceremonial. We treat people as pluggable parts, and view process as the most valuable asset. People are the greatest asset because they have brains they can use if we choose not to constrain them by rigid processes. Do not ignore pragmatism. Allow people to define the practices that best fit the team, empower them to make the fail-fast decisions, and ensure they collaborate intensely.

Agile development emphasizes collaboration whereas non-agile iterative development is tool centric. If traceability and automated syncrhonization between tools were a reality, tools would be an important aspect of the development effort. But neither is realistically achieved. In most cases, plugging information into any tool other than your IDE is wasted effort.

Agile development recognizes source code as the primary artifact, whereas non-agile iterative development values many other artifacts. In the end, the software development effort is judged by the software produced. Pretty documentation, elaborate models, and detailed test plans offer nothing if the software isn't right. The source code is the only artifact that matters, and any other artifact produced should be focused on improving the quality and correctness of the source code.

Agile development is driven by the customer, whereas non-agile iterative development is driven by the contract. Teams that gather requirements and demand sign-off by the customer before proceeding are in denial. Requirements will change. Instead of employing a process that resists change, employ a process that embraces change. Allow the customer to drive the feature list. Explain to the customer the impact of change (scope, schedule, resources, cost), then let the customer decide. Before you do this, try building a relationship with your customer so that you don't constantly pit IT vs. the business. One team. One goal.

Agile development is adaptive and emergent, whereas non-agile iterative development is planned and predictive. Estimates are never right, and plans are always wrong. Planning isn't bad, but the most valuable aspect of the plan is not the date, because that's always wrong too. The most valuable aspect are the tasks, the dependencies between those tasks, and the complexity of those tasks. But don't overanalyze the tasks. Let the details emerge throughout implementation. Yes, Brooks is probably right...you may have to throw one away. But in the end, you'll be remembered more for where you went than how you got there. And if you need to stick to a date, recognize that something else must give. Let the customer decide.

Agile development is feature-boxed, whereas non-agile iterative development is time-boxed. Most iterative development efforts aim to work in 2 - 4 week timeboxes. Allow the team to decide how long is needed to complete a task based on the complexity of the features. Instead of time-boxed iterations, emphasize incremental system growth. Code early. Run a build hourly. Test the build. Measure your progress continuously. For a project manager, an iteration might last weeks. But for a developer, the end of an iteration is only as far away as the next release to the source code repository. Focus on features in each deliverable to ensure everyone remains aligned.

Agile Attitude

Agile development is a philosophy that requires a certain attitude. While agile development is the natural evolution of software process, it is also evolutionary in how it debunks the idea that software development is an engineering discipline that demands ceremony. Agile is loose, yet formal. Measured, though not predictive. Planned, but adaptive. Agility is also difficult to measure. Teams are either more or less agile. Agility is measured by degree. And while iterative is agile to a degree, iterative is not always agile to the degree that is most effective.

Comments (5)

JakeBrake: ... As I suspected, there are exceptions "rules" and opinions aside. I lived and breathed iterative and incremental in "waterfall" development. Perhaps the myth and misunderstandings have created a new reality such that there is a new "waterfall" that will further propagate myth - no different than the myth you espouse "Agile is always good." Is that not like suggesting that Hilton, Spears, and Lohan are celebrities? At any rate, others will disagree with your statement. Clearly you have a bias and do not care to be challenged. :) 1 September 09, 2007 kirkk: ... Royce never actually used the word "waterfall" in his article. He did use the word "iterative". But waterfall is what the industry wound up with as the predominant methodology. Waterfall was commonly used to describe a type of methodology where a lot of work (requirements, design, etc) was done up-front, and a lot of risky work (construction, testing) was performed late in the lifecycle. By definition, waterfall is single pass. Waterfall with iterations is, by default, not waterall. It's iterative. I use waterfall, iterative, and agile to describe a type of methodology that has various characteristics. Based on my definition, if the methodology you describe has iterations, then it's not waterfall, it's iterative. 2 September 07, 2007 JakeBrake: ... Royce's article was a study of a small set! KK says, " Waterfall should never have existed, but it does, and continues to be the predominant process guiding many development efforts today. " That is a strong statement. Waterfall is not a single-pass considering the iterations within. Having worked waterfall on many successful US DoD projects, I can only assure you that it works. Agile is simply another silver bullet that does nothing more to solve people problems than any other methodology. Methodologies continue to be invented for the wrong reasons and never actually solve the problems intended and/or at the desired success rate. Companies want products developed yesterday. As of today there are no methodologies that cure marketing oversell. Additionally, I have seen no factual evidence that proves Agile is better than the others. I am confident I will see none. Waterfall is iterative and remains so. Like all others, it neither solves people and project management problems nor does it solve "oversell". 3 September 05, 2007 kirkk: ... I am familiar with Royce's article, and unfortunately, incorrect interpretations of the article have left us with a predictive and plan-driven process. Certainly what Royce described is iterative, but many team's manifestation of the process is single-pass waterfall. Waterfall should never have existed, but it does, and continues to be the predominant process guiding many development efforts today. 4 September 04, 2007 JakeBrake: ... "... Slice it and dice it any way you'd like, but this is not iterative development. That's waterfall, and waterfall does not work. True iterative development aims to grow software incrementally, where each iteration ... " Kirk, there are flaws and mistruths in these statements. Waterfall does work and it is iterative and always has been. It was iterative in 1975 when I was first involved in it. It has remained iterative in all the years since. The only changes to the process are the growing myths and misunderstandings about it! http://www.sqablogs.com/JakeBrake/863/ 5 September 04, 2007

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close