In his keynote ‘Fast Feedback Teams’ Ola Ellnestam (at the Agile Testing Days 2012) talked about the importance of fast feedback and how to shorten the cycle durations. To me, there seems to be a trend in focussing on getting feedback in shorter and shorter cycles.
While I completely agree that in many cases it takes too long to notice the effect of a change made earlier, I am also a little bit worried that we (as software developing teams and companies) might forget about slow feedback cycles. Let me explain.
Feedback loops
Let’s look at aspects of feedback loops. There is an actor to change the system operation as well as a sensor that reads some information. In order to actually be a feedback loop, the sensor is driving the actor.
Note that most systems allow data to be read at any time and (essentially) any frequency. However systems usually also do not immediately respond to changed input. Here’s an example: You could read a thermometer in your room as often as you like. And you can also turn the control of the heater up or down pretty often and yet the room temperature will not change immediately.
Usually there is no point in acting a whole lot faster than the system can react. If it takes ½ an hour for the room temperature to adapt to a newly set value, reading the thermometer and changing the control every minute doesn’t make much sense.
Some waste and some risk
Now, with the focus on short time scales and a high frequency of the measurements (no matter wether they are qualitative or quantitative), I can imagine two undesirable outcomes:
- In a situation where the system reacts slowly to changing parameters, measuring often is waste. This is because the system couldn’t possibly yield another outcome (yet).
- If we only measure with a rather coarse-grained way (e.g. only the values red, yellow, green), we might miss a slow trend. (I guess this is the reason we often suddenly must buy winter tires, even though we clearly noticed that the temperatures decreased over the past weeks and we’re wearing our long sleeved shirts and anoraks too.)
That said, if the system reacts fast on a change and we can get the feedback quickly, it’s very likely a good idea to actually get that feedback. A good example for this case: Having fast unit tests in programming. 🙂
Hi Stephan! I had same thoughts during Ola`s talk. Finally, I decide so when we use word “fast” we talking about “fast for this current system”.
Thanks Andrey.
Indeed, ‘fast’ should be fast enough for the context at hand.
I’m a big fan of shorter feedback loops, but I hadn’t considered the possibility that sometimes it might take longer to gather useful information.
I’m curious if you have an example where a software product could benefit from a longer feedback cycle? I imagine this is possible but I’m trying to imagine the scenarios.
Thank you for the comment and the question. A very good question indeed.
I didn’t mean to give the impression that we should replace fast feedback with slow ones, though. An additional slow(-ish) cycle can help if there are slow trends in the information you’re gathering or if the system itself reacts slowly.
One example I (partially) experienced was this: A company had to cut cost, so all testers were laid off on one day. I good while after I left, I heard that months later defect rates and customer complaints increased. To me this is not much of a surprise and it’s not clear whether the lay-offs were the only cause of the effect either.
We need to notice slow changes as well as find ways to make them visible. Dave Thomas & Andy Hunt explain this in a great way in ‘The Pragmatic Programmer: From Journeyman to Master’ (chapter ‘3. Stone Soup and Boiled Frogs’).