Iterative development. Incremental build. Whatever you call it, the waterfall model of software development is widely adopted because it allows for continuous improvement through repeated cycles without reliance on a set finish line.

But as Ogi Kavazovic points out, in B2B, even if you have great underlying tech and a great experience, you can still lose out to a competitor that is doing a better job at selling the future. In other words, your customers aren’t buying your process. They’re buying your product. And they want to know what to expect from the product over time.

You need effective software developers to think like architects. But they can only work with the direction they’re given.

Essentially, you need effective software developers to think like architects. Homebuilders don’t just jump in and see how a house turns out over time. They have to consider the foundation and the framing and where the windows should go. But they can only work with the information and the direction they’re given.

That’s why we’re going to show you the pitfalls of relying on iteration, and also how to turn iteration to your team’s advantage.

The problem

Here’s the thing with iteration—iterative planning and iterative implementation are two very different beasts. And problems arise when those two are conflated as equally beneficial to your development team.

You want the distinction in a blunt nutshell? Iteration at the implementation level is a powerful tool, while iterative planning is highly destructive to the engineering process.

Your team is capable of completing large-scale projects and implementing large-scale change. Iterative implementation empowers them to reach an end goal in a productive and functional process. Iterative planning, however, leads to scope creep and an eternally shifting end goal. And it can dismantle your engineers’ morale.

So let’s look at how you can architect a smarter development path for your team through iterative implementation.

The never-ending build

Speaking of architects: developing software is a lot like building a new house in stages. Let’s say you want to build a basic four-wall room you can live in right away. While living there, you’ll be expanding the house with new additions and features—new bedrooms, plumbing and wiring, a second story.

There’s lots of ways you can approach building that house. And you will likely want the strategy that maximizes the smoothness between stages for both the builders and the residents, while minimizing duplicate work and resource waste. That’s just smart planning.

China's "ghost cities" - architecture without the future (or the users) in mind

Let’s continue the construction analogy. With building a house, iteration at the planning level might look like this:

• Round 1: Build a house.
• Round 2: Build a house with two bedrooms.
• Round 3: You know what? A house with two bedrooms should have two bathrooms.
• Round 4: I’d really like skylights in the bathrooms. Even in the one you already built downstairs. Just move the bathrooms somewhere else if you have to.
• Round 5: A kitchen would be nice. Let’s add one.
• Round 6: Why isn’t this house finished yet?

With each new step, the architect has to redesign whole of the house to suit the new additions. We see this problem in software development, too – when you’re working with bite-sized directives, it’s easy for somebody from marketing or sales (or even the engineering staff) to say, “Oh, I’ve got an idea. Let’s add Feature X to the next generation instead of what we had planned to do.”

And you never reach the end.

That’s not to say that your product cannot evolve. But employing iterative implementation instead of iterative planning means the entire development process can rely on your team’s smarts, skills, and vision. And that, in turn, values your team’s abilities and boosts their sense of contribution.

Blueprint for a smarter development path

Here’s what you can do to empower your team: advocate for a full vision of their projects up front. Having the big picture at their disposal is an excellent way for them to understand the outcome your company wants.

For instance, instead of starting with “Build a house,” your team can start with the directive to “Build a two-bedroom, two-bathroom house with a kitchen, rumpus room, and outdoor patio.”

Even if you’re starting with four walls and a thatch roof, the architects know from the get-go that a bedroom will be added off that wall, and a bathroom will be attached from there, and so on. So they won’t put a support beam where a future doorway will be. They’ll go ahead and complete the plumbing rough-in. They’re planning ahead to improve efficiency later.

The "Redneck Mansion" (actually an outdoor theater set) reminds us of several linked features built without a scalable plan.

That’s why it’s key for your team to know what the end goal of a product is in clear, tangible terms. Deliver them a document that says what you want in the end. That way, the developers have a reference point for the project’s ultimate vision. It also helps avoid scope creep. The goal is always to reach your target, rather than spiraling off in new and unintended directions.

Iterative planning would take this process and break it apart into micro-chunks – two weeks, a month at a time. When your design goals are so short-term, your team loses sight of the actual end game.

Instead, draw a line in the sand with the spec. Your development effort is then whatever it takes to reach that line. Sure, the process is a negotiation with product and business about how quickly they need the product and what they’re willing to sacrifice to get it at that speed.

But once you have that negotiation, the product goes out when it’s ready. It takes how long it takes – within an acceptable time frame – and then it goes out the door as intended, not reimagined into oblivion. Instead, it’s polished and strengthened through the iterative implementation process.