TLDR When you want others to improve how feedback loops work in your organisation, it is very effective to amplify things that work in other groups. Liz Keogh pointed this out during Elizabeth Hendricskson’s session care and feeding of feedback loops at eXtreme Tuesday Club London two weeks ago.
This is also our experience. And it was useful to be reminded of it, as I do find it easy to forget. Liz also gave an example, since the meeting agreed to keep details private to encourage free flowing discussion, I’ll provide one of our own.
Besides making software ourselves, we also review code, architecture and processes for clients. We try to be mindful of good things that are already happening, however it is easy to fall into a trap of wondering around, observing some behaviour and artifacts, and then make some recommendations.
So we have made a habit of while we wander around to point out “did you see what that other team did to solve this problem you say you have?”
For instance Rob and I did a process review for a manufacturer of expensive machinery. Expensive as in, they could pay for tens of person-years in development for the price of one reasonably kitted out machine.
One of the feedback loops that most teams found to be difficult, was getting fast enough feedback from testing on the actual machine. The teams had their work out on physical boards and did ten minute meetings in the morning, so it was easy for everyone to spot. Several columns with up to a handful of cards, and then one ‘waiting for test’ column with tens of them.
Most of them? Yes, there was one team that only had a few items waiting for test, and they were going to be taken care of by the end of the day.
We suggested the other teams visit the team that had sorted their end-to-end testing feedback. By the time we came back to present our conclusion, several improvements had already been made. This also meant that there was fertile ground for discussing potential improvements that Rob and I had come up with, but they had not yet identified.