The Iterative Development Process
After visioning and gathering requirements for your project, system or software — whatever you’re working on — it’s time to actually create it. I favor an iterative method of development. Iterative development means working in small chunks and constantly turning out end products that others can react to and provide feedback on. It also means that you can keep gathering and incorporating requirements as you go. In my experience, we have never discovered or defined all of the requirements at the beginning of a project. This methodology enables us to remain flexible as new needs come up or the unforeseen happens, which they always do.
There are a couple of decisions that have to be made before plunging into development. The first is how long the iterations will be. Depending on the complexity of the development, they can be anywhere from 1 week to 3 months long. My preference is for the 4-week cycle. The important thing to remember is to try to produce something that works at the end of the development cycle, even if it’s not final or release-able, and to work on only the number of requirements that can be completed within that timeframe. In other words, don’t extend the deadline to accommodate more requirements; rather, scale back the requirements to meet the deadline.
The second decision is how formal or informal the development process should be. This will impact the kinds of documentation that need to be produced and the intensity of testing. I always advocate documenting as you go, even if it’s just notes in a wiki that can be cleaned up later. At the very least, keep an ongoing list of changes made, features to be addressed, and bugs or issues that arise during development. A more formal process may require a full-time documentation manager who can manage changes to the use cases, project control list and issues list, as well as automated and human testing from test cases. The key is flexibility; adapt the processes to fit the project, not the other way around.
Here are the general steps in each iteration of development:
- Planning: Before starting the iteration, sit down with the development team and ask these questions: What have we learned from the previous iteration? Have the vision, goals and/or scope of this project changed? What feature subset will be coded in this iteration?
- Design and develop in order to produce a working end product.
- Test and correct bugs; this phase can overlap the previous phase.
- Update documentation and generate user help materials, if needed; this phase can overlap the previous phase.
- Collect feedback from the working group, which leads into planning for next iteration.
- Update the features/issues lists and related documentation with changes based on the working group’s feedback. Refine the project plan and related estimates, such as cost estimates.
- If applicable, externally release the product (a rule of thumb for software development is to time a new release for every 3-4 iterations).
In theory, this is a good system for development, but it is not one that I have gotten working perfectly in practice yet. There are some issues that I keep running into. The first is old-fashioned feature creep. It is a tendency of everyone involved in the project to insist that certain features are needed now, regardless of how much time they’ll add to the iteration cycle. Developers, users and stakeholders are all equally guilty of feature creep (although they don’t usually want the same features). I have found that prioritizing features and keeping a running top-ten list helps with this, but doesn’t alleviate it.
The second issue is related. I have found it very difficult to get the development team to stick to a strict timeline while development is under way. Developers tend to want to keep working until it’s done and are reluctant to cut features for the sake of hitting a deadline. There is also a fair amount of fiddling and tweaking that happens, along with a reluctance to say that something is good enough to put out there for feedback, even though it’s not polished and pretty. So deadlines creep out and out and out, and stakeholders get restless because you’re not meeting with them when you told them you would.
These are both management issues, and it takes time and experience to develop the project management skills required to address them.
