Tuesday, September 4, 2007

The Iterative Mind

Most ideas start out simplistic. The more the idea is considered, the more impacts are realized, holes in the initial intent are revealed and more people start getting involved. Soon the addition of features and other agendas causes bloat in the ideas scope. A simple idea such as adding a calendar to a web page turns into adding a CMS to administer an event and scheduling application. This is difficult to avoid, even if your a one-person show. Some people revolt at the idea of bloat and project scope creep, some embrace it. I believe the iterative mind does the latter.

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.
The pros to iterating are easier to understand. The primary reasons are boil down to:
  • 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.
An interesting concept that the iterative mind brings to the table is promoting creative thought again. Something that has been stifled in many projects out of budgetary, time line or product complexity concerns. Iterating renews the possibility that any feature can be added to a product in any upcoming cycle, it gives creativity a new breath of life. Giving creativity a wide girth can be an amazing experience and open the door to leaps in productivity and team commitment. Not every idea will be implemented, of course, but once an idea has baked and becomes formalized into a workable story that gets some priority behind it, it is time to consider iteration and how to apply it.