Waterfall model of software development is not suitable for most software development projects. To overcome this, one of the approaches that software professional use is an iterative and incremental approach. This is generally used for more risk prone, dynamic and uncertain projects. Agile is also said to be an iterative and incremental development process [like many others: RUP and Dynamic Systems Development]. However, it is often easy to confuse Agile, Iterative and Incremental. Iterative and incremental development are very different from each other.

Lets consider incremental development at first. Incremental development is dividing the project in various [as much as possible] independent parts and developing these sub-parts at the same rate/ different rate and integrating them when ready. According to Alistair Cockburn: By “incremental development”, I specifically mean a staging and scheduling strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed. Assuming a hypothetical example of development of a social networking website with parts like member registration, sign in, forgot password, member profile, search members, friends list, blog, blog search, photos, photo search and messaging. Depending on the product owners requirements, development team can start with member registration, sign in, member profile and search members. You could complete these and integrate in a common repository as they become ready. Once these parts are ready, you can pick the next set. It is also possible that you are working on all the parts simultaneously and integrating them when ready in the central repository. This is a very simple example of an incremental development [division in parts, integrating parts when ready]. Also, as would be evident, you could do incremental development with iterative development [Agile or non-Agile] or waterfall.

Continuing with the above example, one way of looking at iterative development is to see the first iteration comprising of member registration, sign in, member profile and search members. The second iteration can comprise of friends list, blog, blog search. The third iteration can comprise of photos, photo search, messaging and forgot password. This is not necessarily correct. A better way to look an iteration would be like this:

• The development team can provide member registration with form fields like name, email address, password, zip code and submit button.
• In the next “iteration” you divide name into first name and last name, email address and password to be confirmed twice and eliminate zip code entirely and add birth date to the registration.
  • Here, multiple iterations help “iterate” towards a final solution.

Again, according to Alistair Cockburn: rework scheduling strategy in which time is set aside to revise and improve parts of the system. As with the case of incremental development, you can see that iterative development does not presuppose incremental development. You could hypothetically speaking [from the above example] build all parts of the system at one go and then refine the system in next iterations.
Iterations and increments generally work well together. And contrary to popular belief, they have been around for long [in fact, as early as 1950’s]. However, they are not the same. RUP and OMG actually even call them by the same name. One of the simplest way that can work is by dividing the project in increments and then factoring in a certain time in next increment for iteration on what was delivered in the previous increment. However, if not managed properly this can lead you to get waterfall into the process. You could be actually incremental when you need to be *also* iterative or vice-versa. And of course, you could be doing incremental and iterative and not Agile. But thats probably a topic for another post. If you are confused as to why some of your “incremental and iterative” [Agile or non-Agile] projects are doing well, while others are not - one possible place to start is to check if you are actually doing iterative and incremental at the same time or not. Another possible method to get it going is what is called a 1/3rd - 2/3rd rule. If the broad outline [bare bone/ no whistle] project is not ready in 1/3rd of time you broadly estimate the project to take, you might have fallen off-track. An important factor to consider is that while it is normally simpler to divide a project into increments but the choice of iteration has to be conscious. People to iterations because they want to be able to demonstrate something quicker and get feedback quicker. This is done to minimize uncertainty and be responsive to opportunity. The decision on how iterations should be constructed should depend on what aspect of the system/ part are you trying to test and get feedback on. Carefully constructed iterations would help you learn about the requirements - validity and clarity, the process efficiency, the code quality or what are whose pet peeves. And hopefully you would iterate your iterations as well [hint: you are getting to Agile].

Popularity: 16%

Posted on January 5th, 2008 by admin
Filed under: Introduction | No Comments »