Incremental vs. Iterative Software Development

As the world became more interconnected and competitive, software development teams sought a new approach that would enable them to deliver value to customers more rapidly while maintaining the ability to respond to changes efficiently. Agile development answered this need. As per the 2020 Standish Group Chaos Study, Agile projects outperform traditional projects and have a significantly, 3x higher success rate. Conversely, waterfall projects have a 2X higher failure rate.

Agile methods emphasize adaptability, collaboration, and continuous improvement through iterative and incremental development. They recognize that requirements and priorities may change over time. By breaking the development process into shorter cycles, Agile enables faster feedback and the ability to respond more quickly to new insights and evolving requirements. Understanding the fundamental concepts of increment and iteration is essential when discussing Agile approaches in software development. These two terms may initially appear similar, but upon closer examination, their differences become more pronounced. In this blog, let’s explore the distinction between these two approaches.

What are the differences between incremental and iterative development?

Think of Kanban and Scrum as incremental development, which focuses on delivering the original planned product in small and incremental releases over time. The primary issue here is the limited chance for customer feedback and product enhancement, leading to customers ultimately rejecting the product. Based on a study by CB Insights in spring 2016, a significant 42% of startups failed due to a lack of market demand for their products.

On the other hand, Lean or Design Thinking development takes a more iterative approach encourages collaboration, continuous feedback, and the ability to respond to changing requirements throughout the development process. Agile iterations are time-boxed and focus on delivering a potentially shippable product increment that can be evaluated and adjusted based on customer feedback and evolving priorities. Both emphasize learning and adapting through a cycle of build-measure-learn. Here are two visual examples to frame the differences between these approaches.

Example 1: Jeff Patton used a sketch of Mona Lisa to summarize the difference between Iterative and Incremental development.

Incremental:

• Develop small portion at a time
• Customers see the whole product at the end.

Iterative:

• Develop through quick iterative cycle
• Excellent for discovery, prototyping and delivery as well.
• Improves the solution by valuable inputs
• Rapid start to receive early feedback which minimize risks

Example 2: According to Henrik Kniberg, Software development is like building a car,  which involves meticulous planning, design, and execution.

Let’s imagine embarking on a captivating journey of car construction. Our ultimate objective is to manufacture a top-notch, well-crafted vehicle that perfectly meets the drivers’ requirements. As we navigate through this Agile voyage, the concepts of increment and iteration serve as our reliable guideposts.

Using an incremental approach, a functional subset of the car is delivered at each increment. This incremental approach gradually shapes the car into its final form, resembling the construction of a magnificent structure where each brick contributes to the overall grandeur of the end result. This can sometimes resemble a traditional waterfall method, which I call “mini Waterfall”:

• The entire vehicle remains unusable from the customer until the very end.
• The delivered components are mostly fixed and harder to adjust based on customer feedback.
• There is less opportunity for the customer to provide valuable input during the development process.

In an iterative development approach for building a vehicle, each iteration can be thought of as delivering a Minimum Viable Product that represents a functional subset of the final vehicle. To demonstrate this, let’s consider the following example when building a vehicle for the customer:

In the first iteration, the team starts with a skateboard as the Minimum Viable Product. The skateboard consists of a deck and wheels, providing a basic form of transportation. Let users join us on a ride to improve our product step by step. With feedback from a focus group, we’ll upgrade from a skateboard to a scooter, then a bicycle, a motorcycle, and finally, the dream machine meticulously engineered to elicit unparalleled customer delight. Those valuable inputs drive our innovation journey!

Each iteration represents a significant step forward in the vehicle’s development, allowing for continuous improvement and adaptation based on user feedback and evolving requirements.

How does a team pick between being incremental and being iterative?

Now that we have distinguished the differences between the two approaches, you might be wondering which approach best suits your team. Here are my recommendations.

Take an incremental approach when:

• Extensive upfront analysis and design have been conducted to establish a comprehensive plan, like in house building.
• The team has a clear understanding of the entire scope from the beginning, with minimal need for changes or adjustments to the vehicle’s design or features.
• Only the delivery phase is required, similar to the waterfall method. The focus is primarily on completing and delivering the predetermined set of vehicle features or functionality without incorporating iterative feedback or adaptability.

Iterative product development can be a better approach when:

• Uncertainty is high or evolving requirements: When product requirements are not well-defined or likely to change, an iterative approach provides flexibility to adapt and incorporate changes based on feedback.
• Complex product: Breaking down such product development into smaller iterations helps manage complexity and enables better progress tracking.
• User-centric design and feedback: Iterative development involves users early on, gathering feedback to refine the product based on their needs and preferences.
• Risk mitigation: By delivering functional increments regularly, potential issues or challenges can be identified and addressed earlier, reducing project risks.
• Continuous improvement and innovation: Iterative development encourages learning, experimentation, and incorporating improvements based on new insights and emerging technologies.

How do we embrace software development at Artera?

Marci Nyárády, a Senior Engineering Manager, shares how his team chose to use an iterative approach when we worked on a feature to throttle automated messages sent to patients:

Artera, a leading communication platform in the healthcare industry, operates a robust automated text messaging system, delivering millions of messages to patients on a daily basis. However, the sheer volume of messages, particularly those prompting patients to contact healthcare personnel, can overwhelm staff members when numerous messages are simultaneously sent and responded to. Consequently, this influx of messages often leads to a decrease in the number of booked appointments, a subpar patient experience, heightened stress levels for healthcare staff, and reduced revenue for our valued customers.

Recognizing the need to address this issue, we identified the implementation of a throttling mechanism as a potential solution. Throttling involves imposing limits on the number of messages sent within a specific time frame and introducing delays when these limits are reached. Nevertheless, we required further insights regarding the configuration of this throttling feature to ensure it would be beneficial for healthcare staff. Questions arose, such as whether there are designated hours for sending these messages, if certain message types require distinct throttling parameters, or if users would like the flexibility to adjust limits based on their workload.

To gain answers to these critical inquiries and obtain user feedback on desired functionalities, we adopted an iterative approach. Initially, we established the simplest possible solution for a single customer and a single message type, allowing us to assess the usefulness of message limiting and delaying. Notably, we refrained from making any modifications to our product at this stage. Instead, we integrated a hard-coded limit and staggered message delivery within Artera’s solution, leveraging the flexibility of our customer-specific code. While this solution lacks scalability for multiple customers or diverse message types, our primary objective during this phase was to acquire swift feedback.

Encouraged by the positive response and the confirmation that our approach addressed the identified challenges, we progressed to the next stage. Our aim was to provide customers with the ability to customize throttling limits and enable throttling for different message types. To accomplish this, we implemented changes within our product, enhancing our infrastructure to queue throttled messages. Additionally, we developed a user-friendly interface that empowers customers to set limits and enable throttling for specific message types.

In the upcoming weeks, we will introduce this second phase to our customers and gather their feedback. While we have numerous ideas for further product enhancements, we remain cognizant of the importance of aligning these improvements with our customers’ needs. For instance, empowering staff users with greater control by allowing them to pause queues and monitor real-time queue size and content, or providing increased configurability through support for multiple separate queues and routing of distinct message types. Nonetheless, we recognize the necessity of evaluating customer feedback and incorporating it into our decision-making process before determining the subsequent steps in our product’s evolution.

Takeaways

To summarize, iteration and increment are two fundamental aspects of the Agile journey in software development.

• Increment is about adding small pieces together to make something bigger.
• Iteration is about repeating and improving to make something better.

They have distinct purposes and are not the same. By adopting the appropriate approach, we empower ourselves to create the right product. This enables us to navigate the ever-changing terrain of software development, consistently enhancing and delivering an exceptional product that satisfies our stakeholders and captivates our customers.

---

The contents of this post as well as the opinions expressed herein do not contain business advice. The business information provided is for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any actions based upon such information, we encourage you to consult with the appropriate professionals. THE USE OR RELIANCE OF ANY INFORMATION CONTAINED IN THIS POST IS SOLELY AT YOUR OWN RISK.