The art of agile feedback in programming

Marcin Floryan, the Director of Engineering at Spotify, is an advocate for effective feedback in agile and he once spoke about the topic at Agile On The Beach conference. Marcin says he was doing an agile transformation at a company some years ago and was discussing with colleagues the problems and frustrations of software development. They wrote up on a whiteboard, the 3 things they wished were true:

1. The client knows what they want
2. The developer knows how to build it
3. Nothing will change along the way

He then takes each of these in turn…

The client knows what they want. Marcin shows a quote:

The developer knows how to build it: Marcin asks if anyone ever worked with developers who get everything right the first time with no bugs — and gets a chuckle from the room. We may not know how to do it ‘right’. If we are solving a novel problem there may be several solutions that might work, or there may be no clear solution at all.

Nothing will change along the way: What’s right for today may not be right for tomorrow. Changes outside our control, or ability to predict, can easily invalidate yesterday’s decisions. Doing everything ‘right’ today might take so long that what we’ve done is no longer relevant. The best approach to take is to use empirical feedback and use that to change what we do. He says that directions set in advance of experience have an especially short half-life.

In summary, change is inevitable but creates the need for feedback.

Agile and feedback

The word feedback is not expressly used in the Agile Manifesto, but it is built into the way Agile works at all stages.

Feedback is about learning the appropriate lessons at every possible opportunity. It is deliberate learning. It requires cycles.

Marcin shares his ‘Recipe for Agile Feedback’:

1. Make original assumptions explicit
2. Set a clear objective
3. Create a careful design
4. Learn from results — act responsively to meaningful data
5. Rinse and repeat

He then talks about the problem of confirmation bias in learning from results. We have our theory, and we naturally look for feedback that confirms our theories, finding ways to discard feedback that doesn’t support this. He asks if anyone ever thought ‘stupid users’ when assessing user feedback — and again gets a guilty chuckle from the room.

Feedback shouldn’t be so easily dismissed if it disagrees with our theories.

Software development, by its nature, is a process of knowledge discovery. If you’re writing something that has been done before you’re doing it wrong – you should use a library. That means that it is likely to take a number of iterations to get it right, as the team discovers this new knowledge and tests it. Fast feedback improves the speed of learning, and also the efficiency of learning.

Gather and assess feedback about the product AND feedback about the process. Iterative development means doing the same thing more than once. You work on it, release it, get feedback, work on it again.

The feedback loops in agile software development

Marcin says there are many feedback loops, and the idea is to discover problems early. Discovering errors later in the process gets much more expensive. There are three phases of gathering feedback, and each has a number of feedback loops nested within it:

• Idea creation – modelling, prototyping
• Development – coding, unit testing, integration, acceptance testing, demonstration
• Deployment – production readiness, concept to cash

Only code that you actually release to customers can provide real feedback on how well you’re providing value to the customer.

Marcin finishes with another quote: