Agile | Insights | Project management

Getting comfortable with iteration

Written by Brian Ganas
On January 9, 2023

There is a constant debate happening between the new way of thinking about development, typically agile methodologies, and the old ways of thinking, typically the beautifully named but oft-disparaged “waterfall.” The thing is: this debate isn’t happening much in a verbal space. Almost anyone you speak with is going to say out loud that waterfall is out and agile is in.

But this debate still rages on; it’s happening in the minds of every project manager, business analyst, and stakeholder. I guarantee it. The idea of moving forward with software development without knowing every single feature that’s going to be needed and/or created is a scary one.
 
Coming personally from a business analysis background, I share this fear. I start working on documenting what we need an application to do, and it’s a terrifying prospect to forego months of careful, considered planning and research. We’re just supposed to… start working?

 

Change the focus

The problem is a lack of understanding or comfort with the concept of iteration. When people think of software and iteration, they’re focusing their attention at the wrong levels. They are planning major version changes as iterations, each new release coming with a large set of deadlines, feature changes, and fundamental alterations to how the solution is going to work. Development teams end up caught in this line of thinking, believing that the only way we can start and work on a new solution is to identify each of these large iterations, research and document all the requirements, and then begin a development and testing plan.

We need to refocus the idea of iteration and make sure we’re looking at small-scale changes instead of large scale. The idea behind agile has never been to justify the idea that we can skip planning altogether. It simply reframes how we handle planning and research. We blend it together with the development process. We’re looking a few weeks, maybe even days, ahead as opposed to months or years. And we can do this because we get comfortable with iteration.

Act small, fix small

Agile encourages organic evolution of a software solution. Rather than adhering to blueprints that were set out months ago, we allow the software to grow within the environment in which it exists. Users provide feedback and we react to that feedback — quickly. We need to grow comfortable with the fact that we will make mistakes, we will add features we don’t need, we will release certain features that are incomplete or fail to deliver the best solution. Those are not failures within the process; those steps are a part of the process. But fixing those mistakes is a key behavior that allows agile methods to thrive. Iteration. Act small, fix small.

Changing to an iterative mindset

There are a few things I’ve enacted personally to try and effect a change toward an iterative mindset.

 
  1. The phrase “let’s try it” seems to unlock people’s inhibitions like nothing else. Encouraging the “let’s try it” attitude as a product owner, ScrumMaster, or SME gives a dev team permission to fail, and therefore permission to innovate and imagine. The solution may not always work or it may require significant overhaul later, but it gives the team the freedom to work on something knowing that the future is still unknown and that it is okay to explore ideas.

     

  2. Smaller stories. There are countless arguments for this objective in general, but making user stories smaller in the pursuit of iteration helps so much. A team member working on a smaller backlog item is naturally going to feel less pressure to ensure the work has achieved absolute perfection. Smaller stories naturally encourage iteration because they encourage, and often require, future changes on a more limited and more frequent scale.

3. Embrace the process. Don’t go into a sprint review or a meeting with the word “failure” attached to any work the team has performed. Apply positive associations with the attempt instead of negative ones. The cliche states that it’s only failure if you learn nothing. With a team ready to innovate and iterate, it’s virtually impossible to fail; you’ll always learn something from every work item. Learning what not to do with your software solution is just as important (more important?) as learning what to do.

4. State the obvious. It seems like such an easy answer, but actively speaking about the concept of iteration helps reinforce the practice of iteration. Talk about it during standups. Talk about it during sprint reviews. Report to stakeholders and customers that you engage in an iterative process, so change may be small, but it will be frequent and highly reactive when necessary.

5. Do not state blame. This one is easy and benefits a team well beyond the concept of iteration. When a feature doesn’t work as we hoped, do not blame anyone. Not the PO, not the developer, no one. Just move on and fix it. End of story.

6. Do not accept blame. This gets trickier, as now we’re interacting with external forces. When a new feature doesn’t work as planned, we also have to defend our team and our process by not accepting blame. We must own our mistakes and our process, but we have to reinforce the fact that an iterative approach means we may not have the solution perfected with our first attempt. Push back on blame. Mistakes and incomplete features are a part of the process. It’s natural and it’s okay. Repeat that message ad nauseum.

Hopefully, with some practice and support, your team can grow comfortable within an iterative space. It’s helped my teams and I know it can help yours!