The Case for Iterative Delivery

By Nicola L. Brown

Why choose iterative delivery?

Perhaps the more important question is why would anybody want to deliver a solution this way?

Why not simply build everything that we think our users want; create the perfect solution and deliver that at one point in time?

Wouldn’t that be easier? Doesn't that make natural sense?

Well, one of my first thoughts, when trying to rationalise this, is that more often than not, any problem that we are trying to solve, somebody else has taken a shot at solving it.

The likelihood that there is already a solution to an opportunity that we have identified, is very high, especially in this age. 

Unsplash Photo by Mars Sector-6

So, where does that leave us? Does it mean, we shouldn’t even attempt to solve that problem, create that experience, explore that opportunity?

Absolutely not!

Rather, it means that from day 1, we have to ensure that whomever’s lives we think we’re going to improve with our solution, they are active participants in the process.

It doesn’t mean that they are hands-on in building the solution, but for anything that is being contemplated, they must have a say.

A good way of looking at it is to accept that until an idea has been validated by our potential user, it is a mere assumption. 

I guess in a round-a-bout way, this takes me back to my original set of questions, I’ll start with the ‘why’.

via GIPHY

Why is iterative delivery a key Agile component?

1 Delivering an iteration allows us to know sooner, if the product or solution that has now come to life, is in line with the validated idea.

🠊 Did we build what our user expected?

🠊 How on point or far off are we?

2 The reality is that sometimes we, as users, need a nudge to understand if what we thought we wanted, was actually really what we wanted. I’m sure we’ve heard the quote by Henry Ford, "If I had asked people what they wanted, they would have said faster horses." 

3 It allows us to get feedback on how our product or solution can evolve (or if it even needs to evolve) or should be taken back to the drawing board. 

And while we may understand the reason behind delivering like this, sometimes it gets a little fuzzy in trying to figure out how to get it done. 

Let’s try to break this down as simply as possible.

Five Key Steps to Delivering Iteratively

1. 🔍 Be clear on the problem

First, we must be clear on whose problem we’re trying to solve. No matter how great we think our solution is, it cannot solve everyone’s problem.

People are dynamic; even in how we use solutions are different. I’m almost sure you can easily think of a friend who has the same model phone as you and may use it completely different from how you do. That’s just the reality. 

Unsplash Photo by bruce mars

1. 💡 Identify our customers

So let’s start by thinking about our customer segments. And when we’ve identified the segments, we’ll narrow it down some more.

Some things we’ll want to think about is:

• Which segment is smallest or largest?
• Which segments provide an opportunity to solve a simple problem which may have a huge impact?

We’ll shy away from the segment which may seem to have the most complex problems with the least amount of persons in that category. 

1. ⮝ Prioritize what we’ll deliver

This is where we can also start looking at our value matrix. It’ll help us identify our quick wins and those are what we want to go after. The bonus to delivering something quickly to our users, it boosts team morale. There’s a certain euphoria and pride when a team sees something they’ve worked on, being used, and is working as intended. 

© Agile Caribbean Link

1. 💣 Deliver the simplest thing

After we’ve identified our target, we want to deliver the simplest thing that will start making a difference in our user’s life. This requires deliberate effort and focus because it’s easy for us to get caught up with working towards perfection.

I may be going off here, but I think this is one of the biggest opportunities for us in the Caribbean. We’re quick to delay releases if we don’t get a process automated or digitized end-to-end and to do this takes time and effort. The more we delay, the higher the waste, as we’re not delivering value to anyone. 

The most important rule in our development is always to do the simplest thing that could possibly work. Not the most stupid thing, not something that clearly can’t work. But simplicity is the most important contributor to the ability to make rapid progress.

- Ron Jeffries, Do the simplest thing that could possibly work

Photo by UX Indonesia on Unsplash

This was one of the first lessons I learnt from my Programme Manager. He was keen on us understanding that especially when we’re changing a process, it’s important to readily identify at each step, how much of the process we would automate. And it wasn’t willy nilly either.

It was starting with the end user in mind; improving the part of the process that they needed to interact with, so that from the first release, they would feel the difference. If it meant that within the office, this seemingly digital flow, required us to still have some manual actions, that was fine. The next iteration could start looking at that. But the intent was always, how are we improving our customer’s experiences. As John-Matthew Sinclair states in Welcome to the Experience Economy, "businesses have to do more for their customers."

We know that we’re operating businesses and so this may not feel like the ideal, but if we’re serious about changing the ways of working, we have to have these, perhaps,  uncomfortable conversations. What is required is transparency and openness about how we plan to deliver. 

1. 💬 Proactively seek feedback

So what happens after we deliver?

Do we pack up shop and move on to the next thing? Nope!

We have to ask our customers for feedback on what we’ve delivered. That can take several forms. The simplest way is to just ask. This could be in the form of sending out a survey…think something like Net Promoter Score (NPS).

Unsplash Photo by Christina @ wocintechchat.com

Again, we know that ideally we’d want to include collection of this kind of feedback in the solution we’ve released. But, really, is that necessary for a first release? Can we readily cite an instance that our end users indicated that they needed an NPS survey in order to use a solution? I would make an uninformed guess to say that doesn’t happen.

So, there’s absolutely nothing wrong if soliciting this feedback requires a little manual effort on our part in the first instance. If possible, a phone call goes a far way as well. It allows us to get a deeper insight into what our customers are thinking, as we’re able to ask follow-up questions if a remark was unclear. You can explore some other ideas here.

However we get the feedback, it’s important to use those insights to figure out opportunities for improvement in the solution, or a direction for what the next iteration may look like. The feedback becomes an input, a kind of starting point, to determine what’s next. 

And then the cycle starts again.

But the point is that, while we’re working to improve people’s lives, we have to figure out how to make that happen sooner. And to do that, we cannot be chasing perfection. Instead, let’s figure out how to get solutions to our users faster and more frequently.