Screw Fast Feedback

Agile teams love faster feedback

Or so the mantra goes.
Legions of agile enthusiasts and countless books, conference talks, webinars and training course harp on about faster feedback as though without it the World would cease.

In the fantasy world we – agile enthusiasts – inhabit, the faster the feedback the better.

Entire hordes of agile nerds are finding ways to make technical feedback – compiles, unit tests and functional tests – faster than ever before. We have frameworks now that give you almost instantaneous feedback on the impact of changes you are making to code and the product you are building. We delight in making the mechanisation of feedback itself faster.

With all the emphasis and near-dogmatic fervor directed in favor of fast/faster feedback, I think it’s time for some perspective – screw fast feedback. I mean really – screw it.

Why do people who understand the value of fast feedback impose the idea on everyone else? There are clear reasons why you make the investment in discovering – and discovering quickly – what someone or something has to tell you about something you did. Whether this is software, a customer or anyone!

3 Reasons For Not Seeking Feedback – at any speed.

We – enlightened folk – prance around thinking the value is self-evident to man and beast. It isn’t.
Let me put more succinctly:

1. If you are asking for it but not going to act on it – and yes, considered inaction is ‘acting on it’ – then don’t seek feedback.
2. If you are asking for it and not going to act on it as quickly as you get it – then don’t  go through all the trauma of seeking it faster.
3. If the source of the feedback is unwilling to give it to you quickly or even at all – don’t waste your time trying to seek it faster.

I have seen too many teams pursue the delusion of Continuous Integration but not write tests – the equivalent of asking for feedback – or not write enough tests to tell them anything meaningful. Then even when they get some feedback – “Red Alert: the build is broken” – it remains broken for days.

Don’t release your product early and often If your customer is not prepared to do anything with it when you release it . Why take the considerable pain of changing how you work to do something that no one needs. That is just dumb.

Every optimization you make costs you something – so think twice about what you will use that optimization for:

If it will not enhance the value you deliver, ease the flow of delivering that value, improve the quality of the valuable product or increase the joy of working on this valuable thing – then do not make the investment.

Why I wrote this

This piece is about giving the rest of the world a break from the pressure to seek feedback and act on it. I hope we can all get back to what works for each of us.

Note: On the subject of feedback, I care that you share your opinion about this post. If you tell me what you liked, I’ll do more of it, if you tell me what you didn’t – I promise I’ll consider doing less of it.