The Iterative Approach: Pros And Cons
The advantages of the iterative approach are clear, and every person who has ever used it knows them.
The first one is divide and conquer, or the ability to split a big task into smaller parts and manage them separately. Such management is more comfortable, takes less time, and in general, more transparent. It also significantly simplifies the scope of work and so decreased implementation effort.
The second advantage is adaptability — if the project has iterations, it is easy to introduce new features (as long as they fit into one iteration), change existing features, or do any other functional change. The time needed to stop working on one part and switch to another is no more that one iteration. It is incredibly flexible and allows to adapt an application to changes in requirements quickly.
The third one is parallelism or the ability to work on several features in parallel. The project manager may split the work scope into pieces suitable for one iteration and ask several teams to work on them simultaneously. Such an approach significantly speeds up development and allows us to build a complex application in a relatively short amount of time.
However, despite all these great traits, an iterative approach has its drawbacks.
Cons
Sometimes iterative development can be started before the planning is complete — so the actual plans are not clear. It may lead to a situation when developers may write a code for a feature that will not be included in the application as it was removed from planning after the iteration was started. You should think ahead to avoid this issue.
Another related tricky situation is when nobody has a full picture of the application functionality and target audience. The consequences are identical to the previous issue — work for nothing and wasted time. You should get all the required information to have a full understanding of requirements, and only then start development.
The common technical problem of the iterative process is the accumulation of issues, often called technical debt. The root of the problem is in the assumption that iterations are entirely independent and always fully completed. However, this is often not true in real life — developers may have some unfinished work after the iteration. This unfinished work may become a big problem in the future, so it is recommended to address it early.
Finally, some projects are so small or straightforward that iterative process overheads take much time from the total project duration. Let's say you have a project that needs 50 hours for implementation, and iteration planning, discussions, approvals, and other related bureaucracy take another 50 hours. So, it is better to use some standard linear approach for such a project to save time and money.
When To Use
In general, the iterative approach is a good default approach for medium and large size projects. It is also very good for projects that often require changes (i.e., high level of adaptability) or deliver a lot of features very quickly (i.e., need to have several teams working in parallel).
However, you may look elsewhere for small projects or projects with a lack of vision or unstable plans in general.
You may combine different approaches and use the iterative approach only for some phases of the project lifetime. For example, you may use a linear approach during the discovery and planning phases and then the interactive approach for the development and testing phases.
I hope these best practices can help you to choose the correct approach. Think ahead, choose wisely, and your project will succeed!