Stone Circles

Nynke May 29th, 2006

In No Trust without Transparency , (link sent me by Marc Evers, Thanks!) I read:

Transparency is the antidote to requests for big planning upfront. Transparency offers project managers the ability to do risk management through the project life time. If you aren’t reporting cumulative flow, or burn down or burn up, or (gulp) earned value, every day to every stakeholder then you aren’t embracing the core foundation of agile development techniques - high trust.

I quite agree … nakedness and transparency can work wonders. And Walking Talk and Talking Walk can replace reporting with embodied communication for numerous “small” systems up until on-demand systems. See TimeForEvolution (on the satir workshops site) for more on that.

And what if we are building or making adaptations to a big high reliability system in production, in a corporate environment, serving many different customers in an ongoing manner? This requires anticipatory stances. How can we support management talking healthy strategies that do not stifle us walking our active minds and creative joy?

We can’t have all these stakeholders aboard the team, as I suggested we could do in Walking Talk and Talking Walk . Not without serious loss of progress and expansive professional power. The communication graph just gets too complex and takes up too much of our energy and time.

Supposing we trust management: How to undo harmful wishful thinking in time? How to manage expectations of management? Management that is continuously flying high in the air all over the world, fully dressed, with only short stops on Earth for Talking here and there? What measurables and observables could work and can we perhaps adapt to in agile ways in this case (while still leaving us reasonably naked)? How to achieve some kind of transparancy of the system for the head?

In natural human(e) systems,
around 80% of information goes to the head
from the body (negative feedback loops),
and only 20% of information goes from the head
to the body (positive feedback loops)

Because of an intense preoccupation in our industry with the removal of defects, we tend to discourage multiple reporting of all failure instances. Multiple reporting is often replaced by resolving multiple reports to a failure type. And of course we compensate for that simplification by attaching some kind of severity rating for taking its frequency into account. Now we can safely see through a single mind.

Huh? An empty board room?!?

Photo by cubicgarden

Or can we? For none of these reports are actually the same, and the differences between them could give (more) clues to what is actually going on in the system. The cost of not doing multiple reporting can be quite higher than the cost of doing them. Not to mention the associated cost of lost opportunities. For undoing the unnatural discouragement of multiple reporting, the following might work? (feedback for contemplating more/different minimal measurements verrry welcome!)

Clear language

• What if “continuity” could mean the “probability a system operates without interruption, under stated conditions, for a stated interval of time”?
• With the above meaning of “continuity”, could “availability” mean “the proportion of time that a system is delivering service”, and can it incorporate notions of recovery and repair time as predictive measures of outage duration?
• And perhaps something like “maintenance rate” could mean “the number of hardware and software defects detected per system in the first year of its operation”?

With above meanings, the continuity of a system is both determined by the nature of a failure type and the re-occurrences of that failure.

With that language, would this perhaps work?

1. Allowing for monitoring trouble field data and representing those as the sum of the trouble rates due to all past and present systems releases: multiple reporting
2. Explicit filtering of raw data. When filtering trouble field data to reduce different instances of the same failure caused by the same fault to one single report, the filtered data effectively represents software defect detection rate and hardware fault detection rates.
3. Monitoring defect removal rates in similar ways to software defect detection rates
4. Monitoring hardware repair rates likewise.

When monitoring as described above, management can expect …

• Earlier releases to have lower contributions to a cumulative trouble curve than more recent ones
• Peaks in a cumulative trouble curve when a new version is released
• Peaks in a cumulative trouble curve when a system is duplicated, like for a new customer
• An overall increasing trend in a cumulative curve because of the increasing number of (managed) systems
• Normalized data to the number of systems, to result in decreasing trends
• Software detection curves to display a distinct skewing in time due to defect repair delays
• The ratio between raw trouble reports (Talk) and and real defects (Walk) to remain constant

If any of these turn out not as expected the development system would need immediate management attention.

(I am doing some simulations with matlab, the pix are soon to follow in more detailed entries)

Would this minimal measurement system be helpful for (executive) management effectively managing risks? What you think?

It doesn’t solve the other problems that can only be solved with observables (Walking Talk and Talking Walk) … yet it may be a start for (re)connecting corporate heads, flying loosely about, to their eXtremely bulky (Very Large Corporation) bodies on the ground?

connections, measurements, transparency

• people & systems