Feedback Loops: Overcompensating

One of the things that I've noticed while working with various colleagues over the last few years is that the more experienced ones are much more skilled at making slight adjustments to their approach based on feedback that they receive from the environment.

I've been reading a couple of books on systems thinking over the last few months and one of the takeaways for me has been that we need to be careful when reacting to feedback we get from a system to ensure that we don't over compensate and end up creating a new problem for ourselves instead.

The idea of over compensating is also know as 'chasing the gauges' in the airline business where it describes the following situation:

When you roll on aircraft left or right. pitch it up or down, change the throttle or the brakes,t tokes time for the plane to "settle out.

Good pilots fly by making a change, then waiting a couple of seconds to see the results. If you don't you'll just "chase gauges" that are themselves still changing.

In terms of software development a mistake that I've made before is to see something go 'wrong' in a situation and then come up with a 'solution' to that which effectively means doing something completely different to what we're doing now.

We had example of this on a project I worked on where we ended up doing a lot of re-work in one iteration because several people were working in a similar part of the code base and ended up trampling all over each other.

In the next iteration we had some stories which would touch a similar part of the code base and I thought it would make sense to split the work by front and back end rather than having each pair work on one story.

While this removed the re-work problem the unfortunate side effect was that it meant we had no visibility about either of the stories until one day before the end of the iteration.

A colleague pointed out that it might have been more effective to wait for a pattern to emerge before trying to make a correction.

In this case the solution probably didn't need to be as dramatic as ensuring that people didn't touch the same areas of the code base.

A more effective approach might have been to just have the pairs sitting next to each other and ensure that they communicated which bits of the code they were changing.

Tying that in with frequent commits would probably have removed the problem of re-work and still allowed us to keep the visibility of individual stories.

It takes a bit more discipline to not overcompensate and I think in a way it goes against the human instinct to try and fix a problem as soon as we see it.

I'm trying to move more towards the following approach:

• Wait and watch situations for longer before taking action
• Ensure any action isn't too dramatic i.e. small steps
• Watch to see how the system responds to the change
• Try something else if necessary

It is difficult though and I certainly make a lot of mistakes.

From http://www.markhneedham.com/blog/2010/10/24/feedback-loops-overcompensating