Agile is iterative. But iterative isn't always agile. Increased agility is not a natural by-product of iterative development, and choosing an iterative evelopment process with high degrees of ceremony inhibit agility.
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.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form
Some would say that the time-boxed iteration cycles is the KEY difference between Agile development and other iterative approaches. Time-boxed iterations are what keep Agile agile. Longer, feature-based iterations could result in wasted time. This is especially true if the customer ends up wanting something else than what was developed.
While Agile indeed involves time-boxed iterations, this is not to say that developers are restricted, or that they are unable to determine how long a feature implementation will take. In fact, Agile developers should be able to choose how much will be accomplished within a time-box by working with the BA and PM to determine which scenarios will be tackled. If a scenario is too large to be completed within a time-box, then it should be divided into smaller scenarios. They key is to maintain the time-box so that the team can remain agile. After all: quick releases = immediate feedback = rapid adaptation = Agile development.
Other than that, your article is spot on.