Iterative Software Development

Iterative software development is almost synonymous to agile work. Let’s face it – is there any other strategy to tackle big issues other than good old “divide and conquer”?

 

What Does “Iterative” Mean?

What do we mean when we say “iterative approach”? It essentially means repeating some actions, usually by taking a big issue apart and doing the same thing for all of the smaller chunks.

If you want to make a nice stir-fried meal, you have to dice meat and vegetables. “Dicing” is an act of cutting something into small blocks, roughly uniform in size. You do that by cutting a large ingredient into two halves. If they’re still too big, you repeat this process over and over again until you’re satisfied.

“iteration – a procedure in which repetition of a sequence of operations yields results successively closer to a desired result” – Merriam-Webster Dictionary

Of course, when you cook, you usually don’t cut in half. You either portion the meat first and then cut those pieces all at once or start dicing immediately. You don’t have to cut everything in half, you can estimate the desired size and use it.

What it does tell us about the iterative approach is that the algorithm doesn’t have to be the same in all iterations. It can vary between phases and take into account the state of the task at hand.

But you can’t argue that when it comes to any big task, you always deal with it iteratively.

 

How To Eat An Elephant?

When you divide and, hopefully, conquer, you take a task too big to even grasp and break it down into manageable ones. If you bite off more than you can chew, you can choke. Most of us adhere to those rules subconsciously. Both when it comes to food and to our agile work.

“How do you eat an elephant? One bite at a time.”

Sometimes we learn about problems that are too big to comprehend. There are so huge, that there isn’t even a starting point. Usually, all it takes is listing all the phases and sub-tasks to find a natural first step. It will be thing that absolutely has to be done and one that you know how to do. If you’re lucky, there will be a few of those.

If we have a few tasks to choose from, it gets complicated. Some people advise to start with the most difficult task. That way we’re going to learn everything we can and also we’ll verify if it’s even doable. We don’t risk leaving the difficult things until the end so if we’re about to fail, we’ll fail early. On the other hand, the first iteration will be the hardest.

Other people say that you should with the most obvious task. You’ll score a quick and easy win, get everyone in the right mood, and learn something by doing a simple thing. All the scary parts will become easier because you’ll inevitably learn something.

There are no “best practices” here. If you apply Cynefin framework, you’d realize we’re in Complex domain. You have to make a decision and analyze the outcome every single time. What you shouldn’t do is trying to tackle the big issue at once.

 

Iterative Problem Deconstruction

If we’re around Cynefin framework, then we should explain the difference between two domains – Complicated and Complex. Complicated problems display causality. While it’s not always straightforward, you can deduce that doing something has a certain effect. You can create good practices and predict the outcome of your actions.

Complex problems are too big and too difficult to predict anything. We can just experiment (i.e. act) and see what happens. Looking back, we can try to determine why something happened but those rules are usually not visible before you do something.

Every big problem consists of many smaller ones. Their complexity level (or Cynefin domain) of parts is never higher than of the whole. A big Complex problem will consist of other Complex, Complicated and Obvious issues.

Just by splitting, you’ll learn more about the nature of the task. Sometimes we even discover that one big problem is really a myriad of easy to do tasks. All it took was to look from a different angle.

Once you have many small tasks, you can work iteratively.

 

Agile Or Iterative Software Development?

Being “agile” means many things. It’s a way of thinking, an approach to solving problems, a philosophy. We talk about Agile Mindset which is characterized by light-weightiness, iterative approach, empiricism and continuous improvement. But most of all it is admitting that we can’t predict the future.

It might sound scary but we really can’t predict the result of actions in complex environment. Iterative software development is undoubtedly complex. Thus, careful long term planning is usually out of the question. We focus on here and now. If we do plan, we don’t make a detailed blueprint. We allow for things to change.

Good plan is the one that can be easily changed.

If we’re about to plan and work on small items, anticipating changes, then we have to work iteratively. We do one bit, we zoom out and see what the next step should be. It’s not magic. It’s an iterative approach.

Let’s face it – this is the only way to deal with big, unstable requirements.

 

Iterations Embrace Changes

Let’s take a look at our good old Product Backlog. As Scrum Guide clearly says and experience painfully shows, nothing is certain when it comes to requirements and proposed features. They change all the time!

“As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.” – Scrum Guide

You can’t rely on the requirements to be immutable. They’re going to change due to environment, competition and human nature. You’ll also release new versions of software and people will start to use them. They’ll give you feedback, one you might not like. That will result in changes.

So it would be really good if you would create the software iteratively. Release it early, release it often and learn what your users think. That way you can include their wishes in next iterations.

Compare that to doing everything at once. There would be no feedback and no opportunity to include inevitable changes in your work.

When you’re working with an engineering task, like building a bridge, you can expect the requirements to stay fixed. But as we all know creating a software is a mixture of mind-reading and art. There will be changes.

 

How To Use Iterative Software Development?

How to incorporate change in your work? How to manage them? It’s not easy but iterative software development at least give you a choice. By splitting big work into manageable pieces, you gain the opportunity to work on the most crucial tasks first and defer work for those that are yet uncertain. You can re-plan after every iteration.

There will be things that you can’t prepare for, there will be surprises and Black Swans. But it’s better to give yourself a standing chance than to hope for the best.

Besides, in iterative software development there is always a next iteration.