Optimizing Feedback Loops for Iterative Agile Development

At its core, Agile software development implies an iterative process. Why do we champion this process? For me, it’s because incremental feedback loops affect every part of agile development.

We need constant feedback because we learn more about our problem every day. There’s no time to spend a week planning and roadmapping. It’s not helpful to spec out the next two months of work. Many of today’s assumptions will be disproven once we actually dig in, and those well-laid plans go down the tubes.

Iterative Agile Development, however, is not a silver bullet. It takes dedication to optimizing our feedback loop to get the most out of the iterative process.

Feedback loops should be tight

A tight feedback loop provides feedback quickly and cheaply. This allows you to make small changes, get feedback immediately, and adjust your approach based on the feedback.

If you break your two-month project into two, month-long “sprints,” you only have one opportunity to get feedback on your Work In Progress before launch day. Doing eight, week-long sprints instead gives six more opportunities for feedback and course-correction. One-week sprints provide much less risk of time wasted due to mistaken assumptions.

So, it’s in our interest to make our sprints as short as they can be, while keeping them long enough to deliver something useful. (In many computing environments, a loop that’s too tight will monopolize system resources without achieving anything at all.)

The same principle applies at smaller scales in terms of ticket writing, development tooling, automated testing, code reviews, and production release schedules: Faster feedback means more efficiency and better results.

Feedback loop example: editing CSS on a website

1. Super slow feedback loop: Edit the styles -> push changes to production -> load the website to see how it looks
2. Faster feedback loop: Run a local dev server -> edit the styles -> view the website on localhost to see how it looks
3. Super fast feedback loop: Edit the styles in DevTools until they’re just right -> copy the changes to the CSS files

You can also tighten feedback loops by deploying tools like:

• Integrated Development Environments (IDEs) that perform static analysis
• Unit tests that are fast enough to run on every file change or commit
• Read–Eval–Print Loop (REPLs)
• Prototyping framework
• User testing.

Feedback loops should be front-loaded

If you acquire a key piece of knowledge or understanding early on, you have more opportunities to take advantage of that knowledge. And, you have less risk of making mistakes that could have been prevented by that understanding.

Because different tasks represent different levels of opportunity for learning depending on their familiarity and complexity, you can front-load your feedback by taking on the tricky or uncertain parts first.

Suppose your sprint commitment includes two big tickets: build some CRUD interfaces and integrate an API from an unfamiliar vendor. You might spend Monday and Tuesday building some simple forms. On Wednesday you might discover that there’s no public documentation for the API. You’ve got to submit a support ticket to get an API key from the vendor.

The CRUD task had a very low level of uncertainty, so the amount of new info you gained by tackling it was minimal. If you’d tackled the API first, you would have had more time to adjust your approach based on the feedback. A simple choice to read up on the API vendor for 30 minutes before starting in on the easy stuff could very well save the sprint.

Feedback requires effort and openness

In order to benefit from feedback loops, you have to build processes that encourage, surface, and incorporate valuable feedback.

This means letting stakeholders see what you’re building, as you build it. There’s no benefit to working in secret until it’s “done.” This is one reason we invite clients into the Slack channel where the team works. We also have clients perform User Acceptance Testing on the tickets we complete every single sprint. This way, everybody’s on the same page about where the product is heading.

Stakeholders can also help to round up real or prospective users for user testing, which can help to correct the assumptions of the client as well as the development team.

Finally, you have to actually want the feedback. And this can sometimes be painful, but tight feedback loops help a lot here. The team that just went heads-down for two months to deliver according to a detailed spec is not going to be able to hear, “Actually, that’s not what we wanted.”

But the Agile team that gets feedback on a daily basis has far less time and energy invested in their false assumptions. They have more tools in place to bring things back in line with the client’s needs.

That’s the team that seeks out the feedback and views it as an asset rather than a slap in the face, and that’s the team that delivers real value to clients.

If you enjoyed this post, you can find more of my written work here.

Connect with me on LinkedIN

---

Agile Jason Pollentier Lean Agile Sprints