One of the things that development teams often talk about is the idea of feedback loops.

Though people may define this a little bit differently depending on their specific circumstance, one way of thinking about them is the amount of time it takes the service provider to request information from the client (or vice versa) and the amount of time as well as the amount of information included in the response.

When it comes to software projects, there are normally two ways in which people consider feedback loops to be valuables:

  1. Small feedback loops
  2. Large feedback loops

So novel, right?

But here’s the question: What do you do when the person to whom you’re providing a service, or the person to whom you’re working with values the opposite type of feedback loop than you do?

Feedback Loops in Software Development

When it comes  to software development, the general idea behind feedback loops is that developers want (or should want) to get feedback from the client as frequently and as fast as possible.

As with anything, there are advantages and disadvantages to both – some may argue that the small feedback loops result in more problems than large feedback loops, and others will argue just the opposite.

But I’m of the mindset that the greater challenge arises when each party is of the opposite mindset. That is to say, one party prefers one type loop than the other.

On Small Feedback Loops

In my opinion, one of the biggest advantages of small feedback loops is that it results in quick iterations.

The idea is that you’re building pieces of functionality, tossing it over to the client for review, receiving their feedback and resolving the issues, moving on to the next piece of functionality, then repeating the process.

But, like everything, this does come with a cost: time.

When you hand off small pieces of functionality at a time, there is definitely noticeable progress in the project being made, but the client ends up seeing the work as it’s being done.

Usually, this is tied to the idea of the “velocity” of a project, but that’s a topic for another post.

They are seeing a feature incomplete build of their solution that likely likes in design, user experience, and/or other features. And this is something that shouldn’t be understated: Although we know it’s not the end result, and we can often envision it for ourselves, the client cannot.

This isn’t a criticism, critique, or negative observation either. It’s just a different mode of thinking. People are generally used to receiving the final product be it on their computer, mobile device, or whatever other platform they’re using.

And though we’re handing off the work thus far for feedback, sometimes the focus can be on the lack of what’s there than what we’re presenting – we’re showing only a piece of the final project – and this can be a major hurdle for some.

So, although smaller feedback loops may ideally result in quicker iterations for us, it may be more challenging for them as it relates to evaluating the work thus far.

On Large Feedback Loops

Personally, the idea larger feedback loops make me nervous because it makes me feel like I’m handing off a “big bang release.”

You know what I mean: those types of projects where the client requests a result, goes off on their own for a few weeks with little communication, then emerges with something that does what it’s supposed to do, but doesn’t do it in the way that it’s expect or in way that even looks good.

Furthermore, this can also result in a significantly longer list of issues, defects, and/or bugs that could have been caught earlier through the use of smaller feedback loops.

The challenge, though, is that some people need to see the entire solution implemented before providing any feedback. And just like this may feel like a “big bang release,” the feedback can often feel like a huge list of problems that need to be fixed.

Just as small feedback loops feel like quicker velocity, larger feedback loops end up feeling like there is a slower velocity to the project, though this isn’t necessarily true especially if the chemistry between the developer and the client is one such that larger feedback loops can result in an overall shorter timeline of development as it works more in sync with how the client works.

Instead, sometimes seeing a more feature-complete build of the project can result in faster development time because the client is actually seeing more of their solution in place, and can see the larger picture of the finished product with less effort.

It’s Kind of Selfish

I tend to think that smaller feedback loops lead to more successful projects.

The thing is, I recognize that it’s from my own bias in that I prefer smaller feedback loops because they benefit me more.

But that, at its very core, is selfish.

Just as I have my own preferences, as does the client. Ultimately, I think that developers and clients need to find middle ground on which feedback is generated and to which its responded that works best between both parties, but this can be challenging especially when each party prefers their own methodology.

From The Outset

So during my time of self-employment, I’ve gone from usually running and managing projects for others with the perspective that smaller feedback loops are the way to go, and not complying with that can have negative effects on development.

But experience has shown that this isn’t always the case.

Instead, from the project outset, I’ve found that it’s important to set a level of expectations – to ask “How quickly would you like deliverables?” or “When would you like to see the first iteration?” or something along those lines and then back into a schedule from there.

Define the size of the feedback loop such that it works well with all parties involved.

And this point, the developer can be prepared for a certain level of a feedback, and the client has an expectation for what the project will look like at each point of delivery.

So rather than letting one’s personal preference drive the how feedback is generated, define it from the outset.