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
- 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.
- Get info, determine solutions, get feedback, repeat. The process for getting feedback can be simple, if you let it be. We often over crowd 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 you 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 timeframes, feedback loops are absolutely critical. Improve your software quality by getting quick feedback from users.
- 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 users problem or meet a users 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.
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.