Most people have heard of the KISS principal. There are a plethora of reasons for why keeping it simple can be difficult and why adhering to iteration then fails. Below is a short and incomplete list of reasons why iterating work can be feared and loathed:
- Loosing the tail. The assumption is when a large project is iterated over, some of the low priority features will not get done (and we want it all). So if we iterate, not everyone will get what they want out of the project as features prioritized lower may never come to pass.
- Iteration lengthens projects. The argument is that taking several months to plan, design, architect and build something all at once, results in less churn, planning and allows the project to be locked down and accurately estimated. Iterating a project will take longer because of the time to spin up and down the team to do iterations.
- Iterations will result in less quality and product cohesion. If a project is done all at once, the product vision, direction and documentation will be better and lead to an improved result. Iterations allow for flexibility to change direction each cycle and that can lead to a project direction tug-o-war.
- Lack of understanding why building software can be hard or time consuming. Keep in mind less technical team members will not always have a clear perspective into what work is a high level of effort or has prerequisite work involved. If coworkers don't have the full picture of what is involved to build software such as working with other teams, third parties or even pulling along legacy platform baggage it will create an understanding rift and ultimately distrust.
- Incremental course corrections. During the course of iterations, teams can change features, priorities and sometimes even longer term project road map goals. Altering scope is often hard or even implausible to do in a waterfall project since the team can spend hundreds of hours designing and writing technical documentation up front that would have to be reworked. By having a small, flexible team that works closely with it's constituents the final, long term product will be more accurate and useful (even if it wasn't what you started out to build).
- Quick exposure. When teams iterate properly, they are supposed to implement and release the most important content and features early. If the Product Owner has done their job, the less important features and details will be in the tail end iterations.
- Quality. The idea here is a close knit team will keep better track of the product changes all throughout development and everyone will take more pride and ownership in it.
- Staying competitive and relevant. By getting features to market more frequently, media attention will be generated and product use can follow. Making users wait months or even years between product releases for features and bug fixes is becoming less and less acceptable to everyone from users, shareholders to marketing departments.