Is Iterative Software Development Really Agile?

A few years back, I was asked to take over as the Scrum Master for a team that was already familiar with Agile/Scrum concepts. I was quite excited because, for a change, I was joining a team that already knew what Scrum was and I did not need to train the team in Scrum Methodology. After a few days with the team, one thing became very clear – they were doing Iterative Waterfall and not Scrum.

Confused? Read on, to find out more…

Before we Begin: The Waterfall Methodology of Software Development

Software Development for many years used to follow the Waterfall Methodology where teams first gather requirements, designed the system, built it, tested it and then finally packaged it for delivery. The term Waterfall was used because each stage had a clear-cut start and finish and happened one after the other just like water flowing/falling over a bunch of steps. Look at the picture below:

Is there really an Iterative Waterfall Methodology?

I used the term Iterative Waterfall at the beginning of this article. What exactly is Iterative Waterfall? Is there such a thing as Iterative Waterfall?

Actually, Iterative Waterfall is not a formal software development methodology but is one of the most widely popular/used methods. In fact, most people who claim to be doing Scrum are actually doing Iterative Waterfall.

A typical Iterative Waterfall project would do any or all of the following:

• -        They have a Functional Specifications Document (FSD) instead of a Product Backlog of Features
• -        Scope is Fixed and all features have to be built by the Delivery date
• -        The first few iterations are spent in planning (and sometimes design too) for the overall delivery
• -        The Product Owner just translates sections of the FSD into a User Story which results in huge user stories that typically take 2 or 3 or more iterations to finish
• -        Development and testing for a user story happen in different iterations; i.e., Development finishes in Iteration N, while Testing completes in Iteration N+1 or later
• -        Team have a clearly defined Tech Lead who does Task assignments and tracks progress
• -        Each Sprint/Iteration does not result in a potentially shippable product.
• -        One big-bang round of Testing is done toward the end of the project to ensure good quality software product
• -        Team does Analysis à Design à Develop à Test à finish for each story assigned to them.
• -        Daily Stand-ups are more like Status Update Meetings.

Are you part of a scrum team that does any or all of these?

Is Iterative Waterfall or Iterative Software Development Really Agile?

Of course Not.

Iterative software development is extremely popular because, people who are very used to the waterfall model of development, find it very hard to give-up on their practices and just include the Sprint/Iteration thing into their project and claim to be doing Scrum. They also, split user stories into smaller pieces just so they can calculate a Velocity and show progress. Team does development in Sprints, requirements are captured in stories, estimates are done in story points, velocity is calculated etc. Isn’t this almost like Scrum?

Like I said at the beginning of this section, No Iterative Software Development is not Scrum. In Scrum each user story is an incremental feature of a product and in each sprint delivers a product that could potentially be packaged & shipped to the market. The past many articles have covered various different concepts about Scrum and we have pretty ignored all of them as part of this Iterative Waterfall. Haven’t we?

What is your experience on Software projects? Have you come across any Iterative Waterfall projects? Do Share your experience with other readers…