Iterative Incremental Development

While agility has its origins in the world of software (Agile Manifesto, 2001), its impact has been so significant that, to this day, it has already revolutionized the way thousands of organizations in all sectors work. And it's no surprise!

After more than ten years of operating with an agile mindset at Runroom, one thing is clear: we wouldn't go back.

Agile is a broad concept that refers to a working method. The word "method" comes from the Greek terms "Meta" (μετα), meaning "beyond," and "Hodos" (ὁδός), meaning "path." Therefore, a method is nothing more than the path to follow to go beyond.

Although it's not the only one, iterative incremental development is a crucial component in the world of Agile methodologies and intrinsic to the way we work at Runroom. How does it work?

Creating or developing a product iteratively and incrementally involves making the product more complex and refined with each delivery (incrementing it) based on the feedback obtained from testing (iterating it).

By working in this method, we obtain a functional product from the start, one that is potentially launchable and becomes more usable and adapted to the intended context with each passing day.

How to organize delivery cycles will depend on the product's specific circumstances and what best suits the teams' working method. 

After years of trial and error, we have found that delivering value to the customer, a product that is potentially publishable, works for us in two-week cycles (sprints), which are further broken down into one-week internal work cycles.

Where does the Agile path lead us?

Every organization conceives agility in a different way, but if there's one essential aspect common to Agile methodologies, it's that they all focus on delivering value to the customer in a specific way: early and frequently.

The variables 'timing' and 'frequency' of value delivery are what distinguish Agile methodologies from the traditional waterfall model:

The problem with the waterfall methodologies is that they can't provide value until the final phase of the process, which means they are unable to learn from user feedback until that point. This results in, at a minimum, two problems:

1. Reduced fit. The solution reached is less suitable for the real user's need.
2. Waste and rework. Any changes made after the value delivery moment are costly because the product has to go through the entire waterfall process again.

So, what do we need to do to achieve early and frequent value delivery, especially when it appears to be clearly more efficient and optimized?

What do we achieve with iterative incremental development?

• Maximizing customer value delivery: Testing and receiving user feedback in real time allows us to refine the product definition, thereby maximizing the value we deliver to the customer.
• Minimizing development costs: Delivering value iteratively and incrementally reduces the costs associated with incorporating feedback, as we don't have to wait until the end of the process, shortening the redesign and deployment cycles.
• Reducing time-to-market: Having unfinished but perfectly functional product versions allows for much earlier launches, giving us a competitive advantage.
• Lowering the risk of overdevelopment: Considering that around 60% of software functionalities are never used, another significant advantage of iterative incremental development is that it allows us to stop developing (and, consequently, investing) at any moment, thus avoiding unnecessary resource expenditure.

The scope of functionalities is managed dynamically, ensuring an optimal fit between scope, price, and time. The cessation of product development is determined by achieving a sufficient return on value, not an external calendar.

This is what iterative incremental development of a product organized into two-week sprints looks like:

There are certain prerequisites for iterative incremental development:

1. Cross-functionality: Early and frequent value delivery requires collaboration and breaking down functional silos, where all disciplines work together to achieve a common goal. It's about aligning teams around business objectives (delivering maximum value to the end customer) rather than departmental goals, with their associated delegation of responsibility.

2. Autonomy: Developing a product iteratively and incrementally necessitates self-managed teams that do not rely on hierarchical external decisions that could block or fragment the workflow. It is essential to decentralize decision-making and empower teams who, as experts, are best equipped to know how to develop the product.

3. Kaizen mindset, culture rooted in actions: Kaizen (改善) is a Japanese word composed of two terms: kai (改), meaning "change," and zen (善), signifying "beneficial." For iterative incremental development in which the product constantly evolves, we need to welcome change; we need Kaizen mindsets focused on learning and continuous improvement. To achieve this, it's crucial to instill agility within the organization (Business Agility) and create an organizational culture built on actions and behaviors that emphasize excellence, learning, and the professional and personal growth of employees. It's not enough to decorate the workspace by writing our values on the walls; effective time must be dedicated to improvement.

An example of a best practice in this regard is regular retrospectives: What has worked? What bottlenecks have arisen? How are we collaborating? These rituals help refine the process and introduce small incremental changes in the workflow over time.

In the case of Stooa, an Agile development of a fishbowl tool, we explain the research and iteration process that allowed us to turn intuition into reality and bring Stooa to life: the first online fishbowl tool on the market.