The Feedback Cycle is king!

Agile software development methods are organized around an important concept: the feedback loop.

The idea is that whatever you do - coding, attending a meeting, doing a full project - you must have a way to gather feedback about what you did so that you can analyze it and improve based on that analysis.

While coding you use Test-Driven Development (TDD) to build a fast feedback cycle about the algorithmic quality of the code. When attending a meeting you ask at the end of the meeting: "was this meeting useful? How can we improve it in the future?", when doing a full project you have a "retrospective" meeting where you analyze the project and learn from it to improve future projects.

The Freakonomics people have now written an article in the New York Times exposing academic studies that prove that the best way to be good at what you do is to include regular and quick feedback into the process of learning to do it.

Agile teams know this already: quick feedback cycles are at the core of the values in the Agile manifesto.

1. Working software over comprehensive documentation - Working software is seen as the ultimate feedback on the progress of a project. By showing the working software to your customer (see below) you will be able to assess whether what you are delivering is a)what the customer needs or wants, b)finished or something is still missing to complete a feature.

   Working software provides you feedback at these two levels:
   





• Quality of the developed software (as perceived by the customer);


• Completeness of the developed software (as perceived by the customer).




2. Customer collaboration over contract negotiation - Collaboration with your customer builds a feedback cycle that can improve the results of your work in terms of "fit-for-purpose" and "completeness". Customer collaboration can happen at the software review level as discussed before but also at the level of requirements eliciting and problem solving. Many times a set of requirements is set for a product, but as the software is developed the customer understands better the problem being solved by the software and may change his mind about what is relevant in that context.

   If you are tied to a contract and the customer is not actively involved in the project that adaptability to the context disappears, and the feedback cycle is no longer used or even useful - I'm sure you know of the impossible change-request processes that have been created to avoid this exact feedback cycle.

Agile methods thrive on feedback. Build a feedback cycle into everything that you do and you will become better at it.