“Optimism is an occupational hazard of programming: feedback is the treatment.” - Kent Beck
Eliciting feedback and dealing with it skilfully is one of the most difficult and powerful ways of achieving control in complex environments.
When we do software development in an Agile way, we elicit feedback. There are lots of different definitions of the concept of feedback but here we’re using the word to mean something like “information gathered in response to a product which is then used to inform and modify the product.”
We gather feedback in different ways. In Scrum, the most obvious is show and tell where the team demonstrate what they’ve been working on to stakeholders. The retrospective is also feedback. Not about the product necessarily but about the team which is producing the product. The daily stand-up also produces feedback. Sitting the team together also provides helps.
But there are other kinds of feedback. Testing of all kinds produces feedback, as does deployment - or sometimes the attempted deployment - of working software. And of course the actual use of working software gives even more feedback.
Feedback sounds great. Right? But dealing with feedback can be a rough ride. Running a show and tell and finding out your team has built the wrong thing can be very upsetting for all concerned. Releasing software that’s cost an enormous amount of money and then finding that no one wants to use it can also be very unpleasant. But if your project or your team avoids getting feedback, in the end things will be even worse.