Software isn’t concrete. However, the “waterfall” model of creating detailed plans, getting approval on those plans, and then sticking to those plans originated in the construction industry, and is still sometimes used in software development. The waterfall model has merits, but speed and flexibility are not encouraged in this heavy planning approach. A major flaw of the waterfall method is that the planning phase can take so long that by the time the software is delivered, the actual requirements no longer match the planned requirements, and the software doesn’t solve the current business problem.

Problem-solving team/continuous improvement approach

The ability to shift priorities and accommodate new requirements has made an iterative approach to software development more attractive. Many businesses need to deploy quickly and implement changes as new information becomes available. The iterative approach encourages the use of a dedicated team tasked with solving a business problem. Planning the features to be included in the software is done in short cycles with frequent small releases. As requirements shift, the development plans can accommodate current priority needs. This approach is similar to the continuous improvement ideology popular in manufacturing, keeping the value to the customer as the primary goal.

Although there is no overall, massive development plan, the iterative approach uses a roadmap and does take regular “compass bearings” to ensure that development stays on track solving a business problem and supporting the vision for where the overall architecture needs to be for upcoming features. For example, if the developers know that a mobile app is coming, they will lay the foundation as they go and build it in to the architecture from the beginning.

Disciplined coding, no shortcuts

Even though the iterative approach is fast, it actually discourages shortcuts. The only way to accommodate changes and new requirements quickly is to have a solid architecture and extremely clean code. Iterative development is a dichotomy in the sense that it’s both highly creative, but extremely disciplined at the same time. Solid architecture, clean code, and short planning cycles allow the system to expand elegantly without the patching monstrosities that can result from trying to sneak changes into an inflexible waterfall plan.

Minimal disruptions to users

Another benefit of an iterative approach is that it avoids the disruptions and uncertainty that can be caused by implementing a major update all at once. Trickling in small changes makes it easy to explain how to use them without requiring users to stop for complete re-training.

Changes can also be planned according to business needs. For example, during a busy season, you can freeze the software, implementing no major changes apart from bug fixes. Bigger changes that will require training can be implemented during slower times of the year when people have the time to learn new procedures. Changes can also be batched into those that makes the most sense for different departments so that they can learn their new features together.

Ongoing growth and support

Using the same team to work on multiple iterations of the software can also speed maintenance by having the same team implement fixes along with new features. With iterations, the team doesn’t deliver and then disappear. Support and growth are ongoing and handled by developers with system expertise.

Test ideas quickly

With iterations, you can also try something as a test run to gauge impact. The popular “fail fast” credo can be supported with A/B testing of two different interfaces for example, to see which one results in better user engagement.