What is Iterative Software Development?
Custom software development has continued to evolve over the years, with the attempt to avoid the too common “but this is not what I wanted” issue that so often arose. Even with the best of intentions, software that is ‘completely’ designed at the onset of development, then delivered in a single deployment, does not take into account the maturity process that occurs as the project stakeholders are allowed to work with and socialize a software application. This waterfall approach would invariably result in extra development and/or disappointment.
The advent of an Agile methodology has helped correct these failings. Small, vertically integrated, software feature sets are developed and deployed to clients as they are built (these are termed Sprints). Discussions around these feature sets allow clients and developers to ‘course correct’ as needed. Features that were thought essential at the beginning of the project may be dropped entirely. Features may evolve to become more or less complex. The end result is a project that the client is happy with, and does not require end-game repair work.
WDD has taken this Agile methodology a step forward. While Agile-like Sprints are still part of our process, we have developed a very structured approach. We differentiate our approach with the name Iterative.
The rules of an Iterative Sprint are:
- 1. Each Sprint will be two weeks long
- 2. There will be a meeting with WDD and the client at the end of each Sprint to discuss the following:
- Review the deliverables assigned to the current Sprint
- Finalize the features that will be included in the next Sprint. This will be based on the points allocated to a Sprint, the number of points a feature is assigned, and the priority of each feature.
- Plan for the next two Sprints’ tasks.
- 3. Every Sprint will result in a fully tested, operational application that may be used, tested and socialized by client stakeholders.
- 4. The client may, at any time, determine the product of a Sprint is sufficiently complete such that it can be deployed and used by client users (Either in a Beta or production environment).
The sense of accountability of the side of the development team as well as the client is key. Promised features must be completed as promised and a client review of the last Sprint deployment is part of every Sprint discussion.