One of the biggest advantages of agile development is the constant feedback built into the process. It is built into every step:
- Developers give feedback to BA’s
- QA’s/Testers give feedback to BA’s and Developers
- Customers/Business Users give feedback to the team
In the process I use with ThoughtWorks, when a developer/pair pick up a story, they read the story and discuss it with the BA before starting to code. This gets everyone on the same page before coding has begun and it helps eliminate issues that arise because of how imprecise written code specifications can be. This means that the story is changed at the cheapest possible time.
The same is true for all feedback, when you get feedback quickly, your response can be immediate and cheap. When feedback is old, your response must be measured, might require additional research, and it will be much more expensive.
I continue to be surprised when I see or hear about feedback being treated as a non-critical piece of application development:
- Feedback withheld because management is concerned the feedback will have a negative impact on velocity.
- Customer feedback is gathered and documented by a specific person or group. The feedback is provided to the development team if the product owner believes the feedback needs to be addressed via a story.
This isn’t good enough. Feedback needs to be provided to the application team no matter what. Related, it is also okay to decide not to act on feedback. But hearing the feedback can help the evolve the overall design in subtle ways to make better fit the needs.
Feedback isn’t and shouldn’t be unique to agile. It can be and should be worked into any and every development process.
Embrace feedback. It will help you better understand your customers and provide a better application.
Jeff Siver 