Technical reviews and safety

Tom Breur

11 October 2015

Retrospectives, just like Technical Reviews, are efforts to surface information in pursuit of excellence. To improve product and team performance. Continuous improvement of course does not wait for any review – that’s why it’s called continuous (duh!). But reviews and retrospectives are scheduled for a dedicated time slot. They benefit enormously from “safe” group moderation.

In their excellent Handbook of Walkthroughs, Inspections, and Technical Reviews (1982) (written long before we started thinking about Agile Retrospectives) Freedman & Weinberg raise some excellent points on how to create a “safe” environment. Their choice of words might rather be a “well functioning” meeting, instead of “safe”, but many of their recommendations are in line with experiential teaching and good facilitation techniques. The word “safe” seems to be in common use nowadays.

Freedman & Weinberg point out that “safe” meetings aren’t just a “nice to have.” Safety serves to provide reliable information with regards to your software development progress. Agile concepts like transparency (as proposed in XP) come to mind. The way you surface information is a prime driver of reliability.

While rereading Freedman & Weinberg’s handbook, it made me wonder how the governance at Volkswagen seems to have gotten in the way of “safety”: it turns out that besides the fraudulent software to suggest lower emissions, there were more quality issues going on. Problems that were (also) known internally, and had persevered. For years many Audi cars had been delivered with the wrong piston springs, which caused higher oil usage. The factory had known about this for many years.

When bad practices are allowed to persist (after all, the Volkswagen Group always took pride in excellent “German” quality products), I see this as an “impressive” example of lack of reliable feedback to (senior) management. For the time being, I’d like to think that most senior executives were indeed unaware of the large-scale fraud and hidden quality problems.

The purpose of surfacing (reliable…) feedback is to raise issues – not to resolve them. You would encumber the meeting with the latter objective, and participants might also feel more (too) personally “involved”… Almost everybody seems to want to “fix” whatever is broken. That inherent “need to fix” reflex seems only natural. Admitting to less-than-perfect quality is difficult. Nobody likes to call their own baby ugly. It requires courage, people standing up for pride in their craftsmanship. But of course it also requires a “safe” (enough) environment to do so…