Is Feedback the new Agile?

Lately I've been reading a good book on change, Influencer, the power to change anything. It was talks about the fascinating methods of Dr Mimi Silbert, who by creating an environment full of constant feedback about performance, helps career criminal change their lives forever. For instance, within hours of entering her Delancey Street Foundation, recruits will already have started working in the restaurant, setting actual tables and feeling the satisfaction from having achieved something new. (A sense of achievement is one of the best sorts of feedback there is.)

To see the power of feedback for yourself, take a graduate employee on her first day and give her a very small task to do. (Adding her name and team wiki and fixing up the layout is ideal.) Make sure that within an hour, and then several times through out the day, she gets feedback from completion of tasks. See how this sets her up for the rest of her time in the job. I've done this with many new graduates and always has good results.

After reading Influencer, I started thinking how all this applied to software development and I quickly saw some correlations with Agile methods. I started thinking to myself, "Is Agile all about feedback? Can we can simply replace the Agile Manifesto with a simple pledge , 'Thou shall give and receive feedback as much as possible?'" Well maybe that was taking it a bit far, but there certainly seemed many parallels.

For instance, continuous integration and unit tests must be obvious ones. The aim of both is to fail fast. That way you get your feedback as soon as possible that the code doesn't work.

And what about Scrum? When I was taught Scrum, the feedback cycles were strongly emphasised. First there is the daily standup meeting which gives feedback about how current sprint is going. Then there is the retrospective which gives feedback about how the sprint process is working. Bingo another one.

Pair programming (an opportunity for feedback into better ways to do whatever you are doing right now) is another. As is delivering small features regularly (feedback to the customer on how the process is going). And then there is keeping tasks small (feedback to the programmer that they have succeeded). The list just kept growing. So Agile may be more than just feedback, but nevertheless feedback seemed to be a huge part of Agile.

Then a slightly adventurous idea came to me. I thought "Lets turn the question upside down". Knowing what we know, that feedback is a powerful motivator for behaviour change, how can we improve feedback in our development processes to make them even more Agile?

Suddenly I was flooded by questions. How can we get our automated tests running faster? Have better coverage? Give each other more feedback about what behaviour we like? And behaviour we don't like? Reduce our units of work so they're finished quicker? Get our features to our customers faster? Give our programmers a better sense on completion for each card? Let our testers see the bugs they found have been fixed? Share the improvements the customer feels with the whole team?

These questions are the same questions we have always been asking. The difference is now we are emphasising giving each individual team member feedback about the results of his or her actions. With this in mind, it offers new possibilities for improving processes.

After all if feedback can tame the urges of hardened criminals, I believe it can work a power of good on our customers, programmers, testers and even our development managers.