How to Really Deliver Value With the Feedback Loop

TJ Rerob
TJ Rerob
Nov 28, 2020 · 7 min read
The feedback loop is critical in Agile methodologies
The feedback loop is critical in Agile methodologies
The feedback loop in Agile software development is fundamental to most Agile practices

Imagine a process where your Agile team could show work to users. Those users could provide real and honest feedback. Which your team could use to reinforce ideas and to learn. Wouldn’t that real feedback be so helpful? That process exists! It is the feedback loop, which is part of the demo process used on Agile teams.

What is the feedback loop? The feedback loop is a more generic term, for the repeating cycle between parties, where information is shared, evaluated, updated, and shared again. Team members can share information, assumptions, and work products with users to get an evaluation. That evaluation is then used to make decisions on how to move forward. The feedback loop applies to so much more than just a demo of software products though. It should also be used to refine information, assumptions, and validations. Refining those through real feedback will only strengthen them. This allows anything you are doing to be made better.

Much in software development has gone to processes less dependent on feedback. It’s believed that the software development team members can research and determine what it is that user needs. While that might be able to be done, it won’t always give you the best product. Sometimes it will fail and give you the wrong product. Either way, it will likely take longer than it needs to.

Why the feedback loop is important

Feedback will let you know if you are on the right track. Which in turn will allow for course corrections to continue to better the software or product. Or to fix issues entirely. You would not know if you are on the wrong track if you don’t get honest and timely feedback.

Feedback from users will not contain the bias of the person that created something. Often, the creator of something can miss things. Because they make assumptions to steer their creation. Those assumptions can cause things to be overlooked. Actual users only care about using the product according to their needs. If you can get feedback from them, they will provide that feedback accordingly.

Why we strayed from getting feedback

It is my opinion that as processes evolved and improved, we sought ways to bypass feedback. Maybe this was thought of as an efficiency gain. Where it was using up too much time of users, to get the feedback. Thus a better process would be where we could figure out the information without the users and keep moving forward. That is just not the case.

Maybe it was thought that as a natural progression of learning for team members, they will grow and do not need to get as much user feedback. This is also not the case. As they learn software, products, the business needs, it only means they might not need as much information to get started. It does not change the requirement for feedback. The feedback loop is still critical. Not getting feedback soon enough in the process is a primary issue with Waterfall development methodology.

Another reason I think we strayed is because of more traditional software development methods, involving requirements. Requirements are meant to tell the team exactly what is needed. They are a list of needs and goals that drive the work of the team. Often they are created as part of a formal and structured process, involving business users. The business users sign off on the requirements and the team executes on them. However, the requirements don’t tell the full story. Also, without something visual and tangible items for users to evaluate, they might not know all of the requirements. Making it impossible to be able to provide them. Nonetheless, we created the requirement process to try and get all information determined upfront, to go do the work.

Trying to get all of the requirements up front also comes from project management techniques and processes. In that, for software projects, the requirements are attempted to be figured out prior. So that you can organize resources around the work. Then you can organize time and budget to those resources. A major flaw in this is that you just can’t understand all of the requirements up front. The waterfall model is at a disadvantage against Agile methods when you are dealing with complex and changing requirements. You simply can’t understand all of the details around requirements up front, let alone know the time and effort it will take to complete them.

We try to figure it out prior

Often we think we can figure it all out ourselves. Instead, we should figure out enough to start. Then get pieces of work ready enough for feedback. A trend in software and product work is to try and do an upfront understanding of the work. I argue there is a big difference between planning around doing work, and trying to figure out the work ahead of time. It's ok to plan for work, to try and figure out things your team may need to tackle the work. On the other hand, trying to figure out the details of that work well before doing the work causes issues. Trying to figure out the details of the work is not part of the Agile scrum development methodology.

Expectations influence completion

A popular theme in software development is the due date of the work. A due date is determined before the work, by those not doing the work. This is supposed to be when the work should be done. However, the work should be done when the software or product meets a needed goal, not an arbitrary date. Shift expectations, from expecting a finished work product because a date is reached. Allow iterations to be times of inspection of the work, to alter course and see if the work is done. If it is, great. If it is not, the work continues. You have to allow for growth, to leverage the feedback loop. This is part of an iterative mindset and good Agile process.

Embrace the criticism, but use it only to move forward

Along the way, we struggled with the criticism. But we shouldn’t be afraid of it, we should learn from it. Criticism is the backbone of the feedback loop. It depends on real and constructive criticism. Some cultures hold it against the team members if feedback dictates that they greatly change their work. Or in other words, they were wrong and need to make changes and fixes. I argue that first, that is part of the process and will happen at times. Second, you could not get to that feedback and make adjustments, if it had not been for the first work and the ability to get real feedback. So use it, and learn from it. Criticism comes from interaction with users and stakeholders, and it is useful to the team. So use it to help improve software quality, your efficiency and deliver business value.

As product owner, scrummaster, or even project manager, enable the feedback loops for the team. Don’t interfere with or hamper that feedback. The team needs it to succeed. Especially in an Agile environment.

Get back to better solutions thru the feedback loop

  1. Testing assumptions requires feedback. There is no real way to verify if your assumptions are correct, other than some sort of real feedback. This could be actual user feedback. That is most useful. It could also be indirect feedback from observing the actions of users and collecting data on their interactions with your assumptions. If actual user feedback is not available, that is the next best thing. Good feedback loops is maybe the best single way to deliver quality software.

Include the feedback loop in your Agile processes

I believe the single best way to improve software is by using feedback loops. Embrace the feedback aspect of your Agile development process. Don’t bypass the interactions with users and stakeholders. Remember the ideas of the Agile manifesto, especially around individuals and interactions over processes and tools. Build your work around those interactions to really unlock efficiency, quality and value. The interactions with users and stakeholders will enable help you reach the goals of your Agile project.

A method to help break up user stories into smaller pieces, is the Vertically Sliced user story. Which helps enable better and quicker user feedback for work in the iteration or sprint. Check out more info on that here.

Additionally, read up on unlocking the teams potential by unlocking the team’s ability to innovate. Innovation is key in Agile development. Don’t hinder it, instead, enable it for the team. More info here.

Dev Genius

Coding, Tutorials, News, UX, UI and much more related to development

Sign up for Best Stories

By Dev Genius

The best stories sent monthly to your email. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

TJ Rerob

Written by

TJ Rerob

A Product Owner and Systems Analyst with 15 years in info tech. I leverage this to learn/build new ideas. I have worked in Fortune 500 companies and startups.

Dev Genius

Coding, Tutorials, News, UX, UI and much more related to development

TJ Rerob

Written by

TJ Rerob

A Product Owner and Systems Analyst with 15 years in info tech. I leverage this to learn/build new ideas. I have worked in Fortune 500 companies and startups.

Dev Genius

Coding, Tutorials, News, UX, UI and much more related to development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store