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’s the Agile feedback loop. Which is part of the demo process used on Agile teams. It’s all about communicating with your stakeholder and having that good user interaction with the team. The Agile feedback loop enables a better understanding of user needs.
This feedback loop is so very important! As that is how you learn and deliver the right things. Agile learning and user feedback enable the team. Including good feedback in your software and product development will help you to deliver quality and value efficiently. Does the shortened feedback loop improve quality? The short answer is it absolutely does. Read on to find out more.
Improve software with Agile learning and user feedback in your Agile development, via the Agile feedback loop.
Table of Contents
What is the Agile feedback loop?
What is the Agile feedback loop? In short, you will improve quality by getting quick feedback. However, there is more to it. 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. All part of a single iteration of development. That evaluation is then used to make decisions on how to move forward. Allowing for continuous improvement and iterative development. Agile processes embrace and require feedback.
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.
From Agile software delivery to the Agile requirements processes, it all can be made better with quality feedback. Just by remembering good Agile learning and user feedback principles, built into the Agile methodology.
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 Agile feedback loop is important to software product development
Feedback will let you know if you are on the right track in your product-development. Which in turn will allow for course corrections to continue to better the software or product. Or to fix issues entirely. It’s all about interaction with users and stakeholders.
You would not know if you are on the wrong track if you don’t get honest and timely feedback. The software project team will collaborate with users, allowing them to develop software that meets user needs. Continuous integration of feedback to the team will allow for continuous delivery. That item that we all strive for.
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. So prioritize feedback from stakeholders and users.
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. Good cross functional teams are capable of such good work, but they still require good input thru feedback processes.
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. Making the Agile feedback loop so critical. Because the software and product team is not learning from it’s mistakes.
Not getting feedback soon enough in the process is a primary issue with the Waterfall development methodology. Building software requires feedback and we have to get back to that. The Agile feedback loop tackles this issue.
Requirements sought as a way to replace the Agile feedback loop
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 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 upfront 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 for those resources.
A major flaw in this is that you just can’t understand all of the requirements upfront. 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 upfront, 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 Agile feedback loop. This is part of an iterative mindset and a good Agile process.
Embrace the criticism, but use it only to move forward
Along the way, we struggled with 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. Embrace good positive and negative feedback, to best learn.
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 a 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 in its software process. Especially in an Agile environment. So allow that team self organization to get feedback and to react to it. Embrace it and promote it, to really help the team.
Get back to better solutions thru the Agile feedback loop
Here are some ways we can get back to better solutions by using the feedback loop and user interaction. These ideas will help promote good feedback which increases your product and software quality. The feedback system, simply put, can help you build better things.
Testing assumptions requires feedback
There is no real way to verify if your assumptions are correct, other than some sort of real software feedback. This could be actual user feedback. That is the 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 in Agile may be the best single way to deliver quality software. So don’t forget customer feedback in software. Use the Agile feedback loop to test ideas and get real answers.
Get info, determine solutions, get feedback, repeat
The process for getting feedback can be simple if you let it be. We often overcrowd the process with formalized rules and frameworks, and that gets in the way. But what you need is simple. You need feedback from actual users. Do your best work, and do that in smaller increments. Then get it in front of users as fast as possible. Get their feedback and learn from it. Then adjust your work and repeat the process all over again.
We let so many things interfere with this. But for truly great quality and products, not to mention to do them in smaller time frames, feedback loops are absolutely critical. Improve your software quality by getting quick feedback from users. Keep the user communication open. Use incremental progress, to deliver in smaller chunks of work, but ultimately to have better deliverables.
This process of do, then learning from it, and course correct is built into Agile concepts and ideas. This is all part of the Agile feedback loop.
The scientific process uses feedback by testing a created hypothesis
The scientific process is all about getting feedback, from testing a created hypothesis. Scientists use feedback to test their problems. It’s the way they get the most accurate solutions to their problems. They research and hypothesize. Then create solutions and test them. Measuring the results of the testing. That measurement of test results is a feedback process.
It is different in that often their process is not interacting with users of something. However, for the process and end result, that really makes no difference. In software, if you are trying to solve a user’s problem or meet a user’s goal, the only real way to know if you did is by getting feedback from the user. They are the single best source of information.
Agile Feedback loop – Include in your 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. Agile teamwork requires these interactions on and off the team.
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.
Agile Feedback loop wins over requirements in any example
I just completed working from an extensive and detailed list of requirements. The team had delivered a quality product. More so than that, they had put a lot of time and effort into this work. Then, the product was delivered Immediately, the users said, “well, what about this….”. We were a bit dejected, to say the least! We had worked from the requirements and thought we delivered what was needed. Just to find out the hard way, maybe there is something better to use than requirements.
In software development, requirements are often the driving factor of the output. They are treated as the end-all and be-all. They are what the team is trying to deliver. Requirements are used to tell the team what it is that they have to deliver. Often they are a stringent list of details. To guide the team to the final product. However, they are often incomplete. It’s just part of the process, that requirements are often incomplete
Could there be a better way? A way to guide work without telling the team exactly what to do. Could requirements not be all they are cracked up to be? What’s better than requirements? In the following, I discuss some drawbacks of requirements. Common problems with requirements. Issues from traditional requirement-driven processes. I then discuss some alternative approaches. Ways that align with agile and help the team deliver.
Requirements Are Too Stringent Of A Guideline
Requirements are a definition to be followed. They are stringent guidelines for the work to be done. This can lead to a lack of creativity or a lack of innovation. The feeling is that the requirement is dictating the work and that is what must be done. This stifles the team’s ability to build the best solution they can.
The rigidity of requirements is something that goes against agile methodologies. In agile, responding to change is a guiding thought. Following requirements strictly, and responding to change, are at odds with each other. This inflexibility is a drawback with requirements. But, what’s better than requirements?
Before getting into that, I first have to go out on a limb. I would argue that requirements should not exist in agile software development. The information is needed, but the concept of a requirement is too stringent. What’s better than requirements? There are processes available that don’t follow strict requirements. They use goals, or actual user feedback to determine the work.
When Are You Done
With requirements, sometimes you don’t know when you are done. Conventional wisdom states if you complete the requirements that you have completed the work. However, without knowing the goal you are trying to achieve, you don’t necessarily know if you are done. The team is strictly following a path laid out before work started. It is unclear from the requirements alone if goals were met. It is not always certain if requirements are still valid while the work is going on.
With requirements, the team can be lulled into a false sense of security, in that requirements are exactly what is needed. Surprise, sometimes they are wrong! Like anything, requirements have an element of error in them. Working off them strictly can lead down the wrong path. Requirements can be based on faulty assumptions and information. Strictly following them leads to errors.
What’s Better Than Requirements – Agile Feedback Loops Win Anytime
- Working towards goals
- Understanding needs
- Getting honest, timely feedback
Working towards goals gives the team the ability to see the endgame and visualize a path to get there. By understanding where they need to get to, the team is better able to build towards that goal. The team can create solutions with goals in mind, thus getting better solutions.
Understand goals, and fill in with information to support the delivery of said goals. Use the goals to guide the work. They are high-level details, almost like high-level requirements. Fill in the details as you do the work. This lets you achieve more, and deliver a better product.
Use goals as high level details to guide the work. Then fill in the details as you work it, for a better product.
Understanding needs has the same effect. It allows the team to build towards a goal, but to do so in a way that helps the user. There are lots of options for getting to a goal, but finding something that the user benefits from is understanding their needs. This is why goals and needs are what’s better than requirements.
Getting honest and timeline feedback is how you fine-tune the work being done. Build fast, fail fast, and learn fast, so that you can course correct. You will never know everything. Instead, get use-able pieces in front of those who will use it. Then get their feedback. This lets you figure out how to fix what you have. Also, how to add what you still need. Ultimately moving towards the goal of the finished product. This is why real feedback is what’s better than requirements.
Shortening the feedback loop gets you improved quality
Everyone wants to improve quality. By finding out what is wrong sooner, you improve quality. Finding ways to get that feedback sooner in the process, to course correct sooner and fix mistakes, only improves quality.
Traditional software development processes don’t implement anything until after a lengthy development cycle. They then implement all at once. It is a big bang approach, where it is either successful or it is not. Hopefully the work is good enough that it can be successful. However, it is often not and requires rework. The reason is that there was not good feedback on the work along the way.
By working in smaller increments, and by implementing those smaller increments in shorter timeframes, you can allow for feedback much sooner. Determining what works and what doesn’t, then making adjustments. Thus improving the quality. Making Agile feedback loops one of the most powerful ideas to help build the right things and do so with quality.
Final Thoughts On Requirements and Agile Feedback Loops
Ultimately, what’s better than requirements is a mindset that problem solves. A mindset that is flexible and adaptable. This is an agile mindset. An Agile mindset also includes feedback in the process. In good Agile leadership, recognize the importance of feedback. Feedback is fundamental to the Agile principles, so include in your processes.
Requirements are all about defining the work to be done prior. Knowing what is needed. Also knowing the tools to be used, processes, and how to go do the work. In the real world, this is not feasible. You have new work that is full of unknowns. There are changing needs and technology landscapes.
These things don’t allow the team to know everything before they start the work. The way to approach is to work towards needs and goals, figuring out the best way forward at each piece of work. Also, getting good feedback from users and stakeholders. This is an Agile mindset and approach. What’s better than requirements, is ultimately an agile approach to the work and using feedback loops to get there.
The Agile model promotes an approach in systems development and software development, where you learn about the work in smaller pieces so that you can more quickly implement and thus learn from it. So why not use the Agile tools available, like feedback, to build the most valuable software and products you can. Go and be Agile my friends!
Additional content and books to help with the Agile feedback loop
Additionally, I enjoy the definition of feedback loops from Hubspot, and linking to that helpful text here.