Agile is an iterative and incremental development process. However, the fact that you are doing iterative and incremental software development, does not necessarily mean you are doing Agile. It is often useful to see the relationship between iterative and incremental development [IID] and Agile through a venn diagram. A common fallacy is to see the relationship as below:

This is not entirely correct. Considering any iterative and incremental development process as Agile is misplaced. Agile is an iterative and incremental development framework but there is more to Agile that just iterative and incremental development. A brief overview of Agile has been presented in the Agile Manifesto. Doing iterative and incremental development does make you more responsive to change, increase customer collaboration and even deliver working software at the end of iteration. However, it is possible to do iterative and incremental in a manner that is anti-Agile. To achieve agility in your development process, in addition to an iterative and incremental development you would need:

• Agile conforms process to people and stresses on a self organizing team. This is perhaps the most important distinction. Agile does not view people as “resources” or “nuts and bolts” or “puts process on top of individuals”. A self organizing team would choose the process it needs based on experience and current situation. This is possible only by creating a culture of decision making, team collaboration, customer collaboration, continuous training and learning. An iterative and incremental development process ridden with ceremony and processes is anti-Agile.
• Agile stresses on collaboration. Tools are there to help you achieve a goal and are not a goal in themselves. A self organizing team could choose to only use notepad while another could choose a million dollar IDE. However, the teams would be collaborating towards a common goal at the end of iteration and not individual targets or productivity. In addition, Agile stresses on customer collaboration beyond just doing iterative and incremental development.
• Agile is adaptive and emergent. The fact that you had a nice plan upfront on what each of the increments would be and exactly how iterations would work, and the project was run exactly like that, is not Agile. This could be possible in some projects [shorter duration, one which you have done many times], but in most projects this is a clear indication that Agility has taken a hit [either of the customer collaboration or product owner feedback loop would be weak]. Ideally, you would want the project to adapt based on emerging requirements rather than stick to an iterative and incremental plan.
• Finally, Agile is about useful working software. At the end of an iteration, working software has to be provided. It is useful to consider Scrum notion of “potentially shippable code”.

As can be seen all the four aspects above aid each other. For instance, the fact that you focus on useful working software makes the project adaptive to emergent requirements which is possible only in an environment of customer collaboration. A self organizing team would be in a better position to provide useful working software quicker and better through better internal team and customer collaboration.

Hence, a better relation between IID and Agile would be as below:

IID + [Agile Values and Principles] = Agile

Also, a better Venn Diagram representation of IID and Agile would be as follows:

Popularity: 21%

Posted on January 6th, 2008 by admin
Filed under: Introduction, Myth Busters, Values | 1 Comment »

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: 29%

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