Why iterating is so important in software projects

June 09, 2021 | 0.25 PDUs

Organizations often treat software projects the same as construction projects: grandiose phases of planning, writing requirements, construction, testing, an develivery. Each phase is gated by approval processes and ceremonies.

But—writing software isn’t like constructing a building. Humans have millennia of experience constructing buildings. While there are definitely always surprises in construction projects, we understand the general idea behind what a building is and how it works.

We cannot say the same for software. We have just decades of experience with software. While your average stakeholder is a software consumer, they have relatively little understanding of what software actually is as it’s really not tangible.

So how do we accommodate the relative novelty of software projects and our lack of understanding of how software works? It turns out the best way to handle this situation is to iterate. Iteration involves constructing a small portion of the product, getting it in front of the end user, gathering feedback, and course correcting. I’ll talk a bit more about iterating in a moment, but first I want to talk about what software looks like without iterating and why software projects are uniquely positioned to take advantage of iteration.

The waterfall approach

Waterfall development describes a phased approach to delivering software: a phase for planning, a phase for eliciting requirements, one (or multiple) phases for constructing the software, one (or multiple) phases for testing the software, and a delivery/acceptance phase.

I have had the misfortune of being on software projects where requirements are elicited for months, software constructed for months, and then finally the product presented to the user. It simply has never gone well for me.

It turns out that we’re really quite bad at describing the software we want using words. We don’t understand software all that well. We enumerate tons of requirements about how we think software should look, feel, and function. Once we’re done listing out all the requirements, we sign off on them, pass them over to the developers, and hope that something reasonable comes out the other end six months later.

Most often, we’re disappointed with what comes out the other end. It’s not our fault and it’s not the fault of our developers—we’re just really bad at describing the software we want. As I have discussed earlier, we have little experience with software and little understanding of it. We wish we could just say “make uber, but for cheesesteaks” but instead we need to figure out how to describe that in a series of hopefully-objective one-line shall statements.

The ability to iterate is a rare gift in software projects

Software projects are really hard. I’m not saying other projects are easy (in fact, they’re all pretty hard). But one rare gift software projects give us is the ability to iterate. If you’re constructing an office building, can you build a small part of the parking garage, ask the customer to test it out, and then rework it based on feedback? No way. There are tons of reviews ahead of time, but ultimately the physical structure has to be constructed all at once, and you would not send a customer on to the job site prior to completion of the project.

Software projects are unique in their digital nature. The “job site” might be an application on your computer or on the internet. If you’re doing some testing, a “failure” is just a software crash. The stakes are lower to involve the end user frequently.

So let’s use this to our advantage: let’s involve the end user as much as we can to increase the likelihood of success.


Let’s consider what iterating might look like in software development. What if, instead of writing thousands of shall statements, we listened to our stakeholders, took some notes, and then presented mock-ups and functional prototypes to our stakeholders. The stakeholders say “oh wait, that’s not really what I wanted, I wanted X, Y, and Z.” Rather than finding out after six months of development, we found this information out after a week of preparing mock-ups.

We go back and update our mock-ups. We’re closer now, but still have some issues. No worries, we get that feedback from our stakeholders, go back to our prototyping application, crank out another prototype, and get it back in front of them. Rather than spending a lot of time delivering a final product that’s way off the mark, we spent some time during requirements gathering iterating with our end user.

We shouldn’t stop there—once we have ironed out some functionality, let’s build it out. We can hand off completed chunks of functionality to our development team. They develop that piece of functionality and then we get it back in front of the end-user. This time, it’s really a part of our final application! Very exciting. But maybe the end-user sees an issue or two with the implementation. No problem! Rather than having to untangle tons of code to figure out what needs to be changed, the amount of code we’ve written since the end-user last saw the application is relatively small—a rework is probably not a large deal.

While the development team works on this functionality, by the way, our design team is iterating on functionality for other parts of the application with the end-users. We’re now firing on all cylinders: our end-users are constantly reviewing and verifying requirements and then, relatively shortly thereafter, reviewing and verifying their implementation.

How to enable iteration

There are some ways we can help enable iteration in our software projects. One way is to recruit User Experience (UX) designers and enable them to create mock-ups and prototypes using ubiquitous tooling (e.g., Sketch and Figma). We need to make sure we have buy-in from management that we can move away from the huge requirements documents that don’t work and more towards an iterative, prototype-driven approach.

Next up, we need to make sure we empower our team to move fast. We should consider implementing agile development approaches. Consider describing work in small chunks (e.g., stories) and implementing two-week sprints in which work is completed. Each sprint should have a kick-off meeting, retrospective (i.e., mini lessons learned), and work demonstration.

We should give our developers the tooling and processes to move fast. Code should be maintained in a modern code control repository (hopefully backed by git). Automated testing should be built into the culture, which allows developers to keep shipping code without worrying about breaking previously-delivered functionality. Our developers should perform Pull Request (PR) reviews on the code submitted by other developers. We should implement continuous integration to make sure our application is tested whenever new code is integrated. We should automate code delivery to make sure pushing out new versions of the application is not a large ceremony but rather just a fact of everyday life at work.


Software projects are uniquely suited to iterating. Rather than large periods of planning and requirements gathering, we can get prototypes and mock-ups in front of end-users quickly and iterate/ideate with them. We can present actual software to them quickly! When we get things wrong, we get just a little bit wrong, we course correct, and get closer to the target. Ultimately, iterating helps us get to what our end-user really wants.

Welcome to PMKnowledge.org! Here you will find articles about various project management topics. Each article lists a number of Professional Development Units (PDUs) you can earn by reading the article based on the average reading time of that article.

© 2021, PMKnowledge.org