Overview of Agile and Iterative Development

By: Brian Mains Date: May 2, 2007 Printer Friendly Version

Iterative and Agile development provide a different approach to developing applications that traditional "waterfall" methodologies. Agile and Iterative methdologies are a more fluid, customer-driven, and evolutionary-designed approach to developing applications. Whereas waterfall development likes to develop applications by performing big up-front design first, agile avoids that approach and develops the requirements along the way. There are many reasons for doing this, and this is not a foolish approach to designing software. It also does not support starting development of an application without any requirements at all; we will overview how requirements are developed later.

The Problem

The more important question is: is there a reason for another methodology? The answer to that question is yes, because there are considerable reasons for doing so. There can be problems with big up-front design and developing a complete specification before developing the application. Several of the problems are:

• Not all of the problems have been completely thought through.
• Information comes to light that changes the application.
• In addition, most common projects using these methodologies are not unit-tested, though that is not always the case.
• Some research has stated that this approach is more fix in the future, and often contains more bugs in the software.

Note that using the waterfall methodology doesn't mean the project won't work, and using an iterative approach doesn't always mean that there will be significant performance gains. "A study by Boehm and Papaccio showed that a typical software project experienced a 25% change in requirements" (AID, p. 72). In addition, another study showed that "45% of features were never used" (AID, p. 73). With traditional software development, these pose huge problems.

Agile and Iterative Development Overview

There are many projects that fit into the agile group of methodologies that are in existence today. The major methodologies are Scrum, eXtreme Programming, Unified Process, and EVO. These methodologies mix and max some of their features and differ in some ways, but some of the feature are:

• Iterative development - Development is done in iterations, which each iteration is a specific length of time. Scrum iterations are a month-long "sprint", XP iterations are 1-3 weeks, UP iterations are 2-6 weeks, and Evo has 1-2 weeks. At the end of each iteration, the team determines whether to release the product with the functionality created. The goal at the end of each iteration is to get a working product. By getting a working product at the end of each iteration, it is possible to release smaller changes more frequently, making it better for the users.
• Up-Front Requirements Gathering - Requirements are gathered up front. Some methodologies plan a two-day ( or so) requirements gathering session to determine what the high-level requirements and features of the system will be. This is not a full-blown requirement specification meeting, but rather to get a high-level overview of what the system will do. XP uses story cards for this, and Evo has its own custom specification language called Planguage. UP uses UML specifications, where Scrum documents requirements in a Product Backlog and uses rough-sketch UML diagrams to flesh out design.
• Iterative Requirement Sessions - The actual work that will be done for a system is determined a day or two before the actual iteration begins, not during the requirements gathering sessions. This is important, because plans can change in the system that cause the work to be done to change during that iteration, usually for good reason. So if an iteration is about to end on Friday, the team will use some of Thursday and Friday to plan work for the next iteration.
• Stand-up Meetings - XP and Scrum have daily stand-up meetings that last 20 minutes or so. This meeting is designed to talk about the previous day's activities and to discuss any problems that may occur or that may be foreseen.
• Visible product output – Most agile methodologies have some sort of project output; that is, something visual that the team can see. Scrum has a product backlog, which tracks the project hours per feature, and produces a chart of the current progress. XP does something similar as well.
• Customer-Focused - Agile methodologies are people-focused, meaning what the customer has to say is very important. After all, developers develop software for customers. So, customers are always involved in the system. In most methodologies, this means that the customer is a part of the project team, and that they are directly involved in the process, as well as through the iterations. In XP, requirements are verbally spoken, so the XP team interacts with the customers a lot; however, all of the methodologies require asking the customers about any problems/questions that may come up.
• Team-Oriented - In agile methodologies, the team makes decisions about the software product. The team volunteers for work, designs the project, and makes any corrections that were found from testing. It is the team that succeeds or fails as a whole, and not as the result of one person.
• TDD/Refactoring - Test-Driven Development and Refactoring are two techniques widely supported in iterative development. Test-Driven development is the process of creating a unit test before you actually create code in your application. This helps to flesh out a better design of a component in the system you are developing. While not really understanding the usefulness of TDD in the past, I have come to see this as a great benefit for developing great software. Refactoring is the process of making good code better by changing the way that it works in small ways. By making slight changes to the code, you can improve how the code interrelates, or improve the maintainability of the code. Sometimes we are forced to develop software that turns out to be hard to maintain or understand. However, Refactoring is the tool to help make a stronger design and increase the maintainability in the application, through small changes.

This methodology as a whole has proven very successful. In my personal development experience, this methodology has been very helpful for me to design software. Because it can be very hard to design a system completely up-front, I am more comfortable and relaxed when using this methodology because as I design software, I can see how one part of the system interrelates with the other system, or it points out code that I need to refactor. And, when I use this design methdology, I reduce the amount of code I have to rewrite later.

Additional Information

To find out more information about iterative development, consult the following resources:

• Wikipedia definition of Scrum
• Wikipedia definition of eXtreme Programming
• Wikipedia definition of Unified Process
• EVO methods
• More resources at agilealliance.org

There are many more site available if you google the appropriate terms.

Resources

(AID) Craig Larman, Agile and Iterative Development, Addison Wesley