Incremental vs Iterative Development
Finding repeatable success in software development
Early software development aspired to follow the principles of their other engineering brothers and sisters. Like building a bridge, the software practice would understand the domain they were building for, draw up plans, and simply march forward constructing a solution. But this plan once and plow forward often lead to project delays, cost overran, and unreliable software. New methods of development under the Extreme Development banner. It promoted ideas of breaking projects into smaller buildable units and sought feedback early and continuously. This discrete grained development can be split into two approaches, Iterative and Incremental development and they offer our projects a greater chance of success.
Defining Iterative vs Incremental
Modern software Design by David Farley
At the heart of Iterative development, lies feedback. Iterative development, fostered by the Extreme Development community, forms software by going through a cycle of building and evaluating feedback on what has been built. This feedback then informs the following steps in development with engineering teams changing direction and design on the signaling from received feedback.
Incremental development on the other hand is also a step by step development process. The difference compared to iterative development is that it still holds Waterfall methodology at its core. With a laid out plan for development, engineers work to develop more discrete segments of code. Each segment is a completed if a production ready part of the larger project.
These two development approaches are similar in their additive nature but vary in the approach to achieve it. Lets dive a little deeper into each and understand how they can fit into your projects.
Diving into Iterative Development
Iterative development starts with gathering initial user feedback. From there, designs are drawn and teams begin to build software. This software however, is the smallest viable product that is needed in order to have an artifact to bring back to their user base to garner more feedback. Whether it's positive, negative, or even neutral feedback, it informs the next stages of development. Designs are adjusted or extended and software is forged appropriately. With this new viable product, feedback is once again sought out. And repeat.
A common example used in the wild is the development of a transport vehicle.
Source: Making sense of MVP - Henrik Kniberg
Initial user feedback expresses the need for easier, faster transportation than walking. The team plans and develops iteration one, a skateboard. With the initial iteration complete, we now have an artifact to bring to users and gauge their feedback. They might express the need for easier control using handles. Thus during the second iteration, we add handles for better control. This cycle continues, better ability to propel the vehicle, greater horsepower, improved comfort and ability to house multiple passengers. Each point of feedback informs new iterations till we have a product that best aligns with user needs.
One of the benefits of this approach is greater reduction in risk. With this iterative approach, user feedback can arrive early and products can remain aligned to user needs. In other words, it's a flexible and adaptable approach to software building. It also enables faster time to market.
Iterative development does have its challenges. The planning process is complex. With each iteration, planning, task identification, and delegation are needed. The continuous engagement with users requires management as well. Teams will need to find effective methods to garner feedback from users over time. Due to the layered approach of the development, the product can look very different between the first and 10th iterations. This means teams must be willing to refactor and redesign the system to better meet the current design.
Diving into Incremental Development
Source: Making sense of MVP - Henrik Kniberg
Incremental development is also a step-wise development methodology. Starting from a Waterfall style, upfront requirements discovery and software architecture, incremental development aims to build a full software project one compostable unit at a time. Individually, the components might not be usual features that end users can evaluate but they are complete in the purpose they are built for. With each increment, more and more components are built and put together. Ultimately, all or enough pieces are assembled to have a working product that can be brought to users or the market as a whole.
Let's say you are developing a calculator app, you have done user interviews and have determined that a calculator app would be a great product. Development might start by first implementing the Math computation library. This library alone does not help the end user since it's just a Java library, but the library offers everything we believe we need to express computation functions. Next we would use an Input expression library and feature. This lets us take user calculation expressions as input and returns the internal expression of that calculation for the app to process. Again, by itself, it doesn't offer end users their solution, but we have the components to evaluate user input and express math calculations within our application. On and on we develop, with each new component bringing us closer to our desired product. Putting it all together, we will hopefully have a product that satisfies our end users needs.
The benefits of taking this approach comes from the upfront design of the system. With a goal and design at hand, developers will have a tighter development cycle as it does not include seeking continuous user feedback. Another benefit is that upfront division of labor can also be done. Although weekly or biweekly updates can be done within the team, less recurring planning is needed. The systems design can come out more consistent as the structure of the program is not developed as organically but planned out more cohesively.
Some of the challenges of this approach is that it does not reduce risk as much as an Iterative approach. With the upfront design and planning, the team won't find out if the product aligns with the user needs until closer to the end of the development cycle. Although the design is layered out more cohesively upfront, should the software not align to user need, it has a larger cost to refactor to bring it closer to user expectations.
Approaching software development in a step by step manner has significantly improved the success of software projects. By engaging with users and breaking software projects down into more manageable planned, development teams can move faster with reduced risk. The most recommended approach is an Iterative method as keeping users in the loop leads to better aligned software and reduced project risk. In reality however, both approaches will find their day in the sun. Teams working much closer to end users will find great success with Iterative designs while perhaps infrastructure teams that don't really have an end user base to interview but system challenges to solve can find success with Incremental design. Regardless of the two approaches, they both move away from a pure Waterfall style development as a step wise building process allows for points of reflection and receiving feedback. These methodologies will help improve the deliverability of your overall work and reduce your time to market.
That’s it for this week. Till our next post, keep growing, keep building, keep innovating.
Theko Lekena
Share your thoughts in the comments below or hit that ❤️ button at the bottom to help support this community and deliver change.
Image: Photo by Danist Soh on Unsplash




