Agile essentials 3: Feedback

The success of your project relies on you getting feedback on every aspect of your project, as often as you can. In a perfect world you’d be getting qualitative and quantitative feedback, but any honest feedback is better than none. When you get feedback, do something with it.

I’ve been waiting ages for even a tenuous opportunity to use this Richard Feinman video in anger, so here it is:

If it disagrees with experiment, it’s wrong. In that simple statement is the key to science. It doesn’t make any difference how beautiful your guess is, it doesn’t make any difference how smart you are, who made the guess, or what his name is. If it disagrees with experiment, it’s wrong. That’s all there is to it.

                 – Richard Feynman

To be honest, the video and the quote are more entertaining and wise than anything you will find in this post. Nonetheless…

To adapt what is said in the video slightly, I’d say in a project team you need to be able to identify the thing you’d like to improve, make a guess about a change you can make to improve it, make the change, measure to see if things improved, and then repeat. That goes for features and development processes.

Quantitative vs Qualitative

Ideally, if it doesn’t detract too much from doing the job, you can make quantitative measurements about your team and your software. Maybe you could measure how many stories you satisfy in each sprint? Or how many bug reports or improvement requests you receive on a feature once it’s complete? You could then go on and measure how those things change as you make changes to your development processes. The extreme version of this can be seen in things like the A/B testing being done at Netflix, where they don’t even bother measuring things like user happiness, bugs or robustness, they jump straight to something like “does this change earn us more money?” and then set out proving it with data. Quantitative measurements are better because they’re less prone to subjective bias (less prone but not immune, obviously).

That said, we don’t live in a perfect world and your team may not be set up to gather reliable quantitative data. Bad data, like the “counting issues in a sprint” example above, where there are a hundred reasons why the numbers are meaningless, can do more harm than good.

Furthermore, there are almost certainly a bunch of things that affect your team and your project that can’t be quantified in a satisfactory way, like how happy people are with the team processes, or how happy customers are with some recent software change.

For process stuff, retrospectives with the team are invaluable. Right now, this is the only essential I can recommend on a project: Have retrospectives, regularly, with the whole team, and when even one person raises an issue take it seriously and act on it.

For feature stuff, workshop features before you build them to create a shared understanding of what is being built with at least some of your user base. Demo your feature as soon as possible after you’ve built it and act quickly on the feedback.

Here’s an example from a retrospective: we were having a retrospective last year and one team member at a different site announced (over a meeting room loudspeaker) that she didn’t like some of the team being in a room and others being remote. We took it seriously and asked the team member to explain what she had a problem with. She talked about missing out on little asides and visual elements in meetings, about feeling less part of the team. We had to admit that we could see the problem. I’d be surprised if anyone prefers video conferencing to being in the room but we agreed to all dial into cross-site meetings rather than book a room because keeping everyone in your team engaged is important.

Since then, we’ve returned to the issue several times. There are still problems, e.g. because we like to have small meetings in a room there are moments when we do that and don’t invite anyone off site. You have to keep an eye on these things; I guess it’s on everyone to work out if they really invited everyone who needed to be in the meeting or not. However, for larger meetings and project stand-ups, things are much better – more inclusive, more integrated and people say they are happier.

Keeping yourself honest

One similarity with science, and Mr Feynman, which I hadn’t really fully appreciated until writing this, is that you should probably record the changes you’re making and how you expect them to change the way the team is working (your guess!) in some formal way so that you can check back later on and decide how well it worked. Maybe even structure your changes as little experiments, with log books and conclusions.


To tie this back into my original post, when you’re looking at your processes I think you should be asking how often they allow you to get feedback on what you’re doing and how easy/acceptable it is to change your processes (or the work you’ve done) when something is wrong. If the methodology you’re following is limiting you in your freedom to respond quickly enough, I think you need to ask serious questions about whether it’s worth following.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s