It a tough question, right? Many companies implement one or the other, but few implement a true hybrid approach. The decision on what to follow depends on many factors, not the least of which is corporate culture and cost of change. Additionally, one of the chief concerns is often the type of products being developed and programs implemented. First let me quickly define what traditional and iterative development are (well in my mind at least).

Traditional, or waterfall software development is probably more familiar to most. The basic belief is that complex software systems can be built in asequential, phase-wise manner where all of the requirements are gathered at the beginning, all of the design is completed next, and finally the master design is implemented into production quality software. Of course all of the UAT and customer experience testing is integrated as well. This approach is more akin to a production line where RGSs (Requirement Gathering Sessions) are held and system specifications are compiled. Then finished requirements specification document are turned over to “software designers” who plan the software system and specify the code, create wireframes etc. The design diagrams are then passed to the “developers” who implement the code from the design. Program managers build PERTs and GANTTs plus mitigation plans, to attempt to account for all of the roles, stakeholders, resources etc.

Iterative development is part of the “new school of development”. Most people know it by Agile or Lightweight Agile. The funny thing is, at its core it is really a return to the old days of software development. Agile methods call for software design to be both iterative and incremental. The IID process allows for continuous revisiting of requirements and change is not as impactful or costly as it is in Waterfall. The Agile Manifesto set the ground rules are follows:

“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”.

So which is better? If you have followed some of my previous posts, you know that I have worked on a broad platform of product/services and offers. I have brought new products to market, launched existing products into new service areas and managed multiple product enhancements. There has been one truism in all of this: change. It’s inevitable. Whether the market conditions change, or the segmentation analysis, the requirements, the budget etc. change will happen. How a company manages change is a big driver for speed to market and success.

In my opinion, Agile provides more flexibility in addressing change and managing shifting priorities. By being able to review code with business owners and bashing it against requirements after a sprint, change is usually smaller and easier to swallow. Plus it’s cheaper in many ways. If using waterfall methods, you usually need to wait until UAT or another code delivery point to review prototypes with business owners then implement change. At that point all of the requirements may have changed and the product is not what was intended. You have now dumped money into “throw away” code or have created more work.

I think you can also take the best of both and implement some combination of traditional software development process and project management techniques and combine them with iterative phased development. This is not a true development hybrid, but a management hybrid. You can use Agile methods to feed a master plan or use even use your burndown chart milestones to represent project milestones. No matter which one you favor, your decision on implementation must focus on controlling the big 4 (cost, schedule, scope & quality). Not an easy task, but that’s what makes it fun.