Why the need for feedback ? Constant change
XP holds that when developing software in an environment of constant change, ‘getting it right first time’ can be very difficult. Even where it is possible, changing requirements can quickly invalidate a perfect solution even before it has been completely implemented. Because of this, XP values incremental improvement based on feedback, over trying to build a perfect solution first time (Beck & Andres, 2004).
To incrementally dispel uncertainty and uncover unknowns, XP aims to get as much feedback as possible, in a short a cycle as possible. This feedback can come in various forms, depending on the kind of change or uncertainty faced.
|As a customer, how can I get an idea of how long it will it take to develop a feature?||Get estimates from developers. In the Planning Game, customers can prioritise stories based on the feedback from developer estimates|
|As a developer, how can I get clarity on a feature with ambiguous requirements?||Discuss it with the On-site Customer|
|I have an idea but is it a good one?||Get the opinion of your team mates|
|I have 2 potential solutions for developing a feature, but I am not sure which is the best one||Try out both solutions in a time-box to see how they look, then pick the most promising one.|
|Is my solution easily testable?||Write automated tests for it – Test Driven Development. If the tests are difficult to write, they may be giving you a hint on some deeper design problems with the code.|
|Is my code well written ?||Review the code after you’ve implemented the solution. Practice Pair Programming to get feedback from team mates.|
|Does my code work?||Run the automated tests for it.|
|Have I broken any part of the system when implementing my solution?||Practice Continuos Integration. Run all the automated tests|
|Does this architecture work? Will this idea really solve the customers problem?||Deploy the system and see – Regular Small Releases|
|As a customer, how can I gain confidence in the teams capability to deliver?||The team deploys the system frequently with Regular Small Releases|
Benefits of rapid feedback
- Feedback helps clarify misunderstandings and remove ambiguities on features being built (Chromatic, 2003)
- Feedback helps reduce waste. If an idea is not working, we can ditch it and try something else.
- Schedules and timelines can be refined based on feedback from completed development cycles.
- Problems discovered in each development cycle can be acted on. The design of the sytem can be fine-tuned based on its actual performance in production. (Beck, 1999)
- Customer feedback on implemented features can be incorporated.
- In an environment of automated testing and continuous integration, we can quickly pinpoint the changeset that caused a breaking change.
- The customer can get an assessment of the teams capability, and build an appropriate level of confidence from the feedback gained from frequent releases.