Change by Assertion

I’ve been involved in process improvement for around twenty years, I think I’ve had some successes.

This is a problem “I think I’ve had some successes” ?
Last year, I was having a conversation with my friend and colleague about how we could approach a particularly tricky question, Mike and I were challenged with understanding the performance and productivity of a large client organisation’s software engineering department – this is difficult to measure.
Our conversation turned to metrics and reporting and we were both struck, and concerned, by the realisation that the approach in the software industry to improving the way teams work is based on the assertion that a particular approach is just “better”. Customers should “have faith”  that if they stick with the recommended program things will improve, many process improvement approaches dismiss an evidence based approach to process improvement as being too hard, conveniently ignoring the issue of measurement.
Change by assertion is not good enough.
Without measurement it is impossible to assess the impact of change and any conclusions are simply expression of opinion. Inappropriate measurements will not only give misleading results but worse can drive negative behaviours. It’s important therefore when selecting measures the effect of the measurement itself is considered, even to the extent of designing measures which if gamed would encourage positive behaviour.
It is important to strike a balance across metrics, it’s no good building things quickly at the expense of quality, or building products with features that aren’t required, or burning out developments teams by overwork. Value is often difficult to quantify but it is absolutely critical to understand the Value that your teams produce, if a team or organisation cannot identify and articulate the value it is creating the team should find something more valuable to work on.
Finally, however good your metrics and measures are, there is absolutely no substitute for actually observing teams at work, if you are curious about how your organisation or teams are performing “Go See!”
We’ve developed Holistic Software Engineering (HSE) to align your business strategy with your engineering teams, HSE combines holistic measurement and communication practices with recursive feedback loops to ensure that your organisation is building products that will deliver your business objectives.