IT Development - SDM Handbook

The following discussion is adapted from "Agile and Iterative Development: A Managers Guide" by Craig Larman.

Iterative Development
An approach to building systems (or anything for that matter) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a a self-contained mini-project composed of activities such as requiremens analysis, design, programming, and test.

Incremental Development
An approach to building systems in which the final system is built by adding and releasing new features, iteration by iteration. In this approach, the team does not wait until the entire system is functionally complete to deploy the product to users. It is deployed little by little until the feature set is adequate or funding for new enhancements is removed.

This systems development methodology uses five primary phases (Envisioning through Deploying). It is quite possible that a development team could take those phases and take a waterfall approach to development (that is, a strict sequencing of phases that is focused on fully completing each phase before moving on to the next). In this scenario, if there are 12 months of features to be developed, the development team takes 2 months for Envisioning, 3 months for Planning, 6 months for Developing, and so on.

That approach is not espoused by this methodology. Instead, this methodology encourages splitting up the features into many iterations and deploying several times during that 12 month period. There are two main ways to structure the project using the MSF Process Model and iterative development:

One Envisioning phase and iterate over Planning through Deploying
With this approach, the project team will spend a large amount of time Envisioning the entire project (i.e. all 12 months of development). The team will structure the project, come up with a rough schedule, and plan out which features go in each iteration. Then, they will embark on many iterations, basically treating an iteration as Planning through Deploying. This has the benefits of iterative development, without all the overhead and the "fuzzy front end" delays of Envisioning.

Iterate over Envisioning through Deploying each Iteration
In this approach, the team treats each iteration as its own project. They cycle through the all the phases as if they were starting the project over again. In practice, the subsequent Envisioning phases will be shorter than the first one, but the activities will still be performed. The advantage of this approach is that the team makes sure they are not assuming too much or getting too far off track from their original goals and structure of the project.
 

Again from "Agile and Iterative Development: A Manager's Guide".

In modern iterative methods, the recommended length of one iteration is between one and six weeks. Each iteration includes production-quality development, not just requirements analysis, for example. And the system resulting from each iteration is not a prototype or proof of concept, but a subset of the final system.

This methodology espouses an iteration length of 3-6 weeks. This has several benefits:       

• It provides early value to the users. They are able to start using the system and getting the benefit of the system as soon as the features are developed.
• It provides early feedback to the development team. If the features developed somehow do not meet the needs of the users, the developers become aware of that shortly after developing the features. Those problems can be corrected before moving on too far into the rest of the project (possibly with bad assumptions). It ensures that the final system meets the users' true needs.
• It gives the users confidence in the development team. When the users see early, concrete features they can actually start using, it will inspire confidence in the team. Also, if they provide feedback to the team and the product is changed because if it (in the next iteration), they will feel that their voice has been heard and they will take greater ownership in the product.
• It provides for easier implementations. It is much easier to deploy a small set of features (including deploying the code, converting data, training, writing users manuals) than it is to do the entire system at once. If too many features are delivered at once, critical activities (like full testing, users manuals, training) will most likely be skipped because they are too labor-intensive.
• It provides the University with flexibility for changing priorties. If priorities change and resources must be diverted from a project, all the work done in the project will not be lost. The development team has at least provided some value to the users. Otherwise, 6 months could have been spent in development, with nothing to show for it.

Are we agile?

Again, adapted from "Agile and Iterative Development" by Larman.

The hype around supposedly "agile" methodologies leave almost everyone claiming that they are "agile". What does this mean?

Agile Development Defined
If agile methods have a motto, it is embrace change. If agile methods have a strategic point, it is maneuverability. It is not possible to exactly define agile methods, as specific practices vary. However, short timeboxed iterations with adaptive, evolutionary refinement of plans and goals is a basic practice various methods share. In addition, they promote practices and principles that reflect an agile sensibility of simplicity, lightness, communication, self-directed teams, programming over documenting, and more.

In short, this methodology espouses those principles, and the principles of the Agile Manifesto without adhering to a specific methodology that classifies itself as agile (XP, SCRUM, DSDM, etc.)

The Agile Manifesto
No, we aren't trying to overthrow any government or create a Communistic society. In 2001, a group of methodologists met to bring together the various "new" methodologies that had been developed over the previous decade or so. They boiled down the principles of those methodologies into a simple statement, now known as the Agile Manifesto:

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more." (Agile Manifesto)