To Improve or Not To Improve
In the last few months I’m being continually surprised by the many applications of a simple principle:
“Invert, always invert” — Carl Jacobi
The principle is relevant when searching for a solution of a complex problem. The essence of it is that the solution of a complex problem is often found or clarified when examining the opposite of the problem or by re-expressing it in inverse form.
And today I was thinking about the Manifesto for Agile Software Development
One important tool in the field of process improvement is that of a “secondary metric”.
While a primary metric measures what needs to be fixed, the secondary metric measures what must not be broken.
Many times when software teams seek improvement in an aspect stated as a primary value of Agile Software Development, people forget to consider which are the things that they must not break in the process. This leads to continual fluctuation of the problem from one area of work to another and the team scrambling to deal with the next crisis in their field of vision.
Next time when you and your team start contemplating an improvement, think about the aspects of your work that you don’t want to suffer. Also, consider completely inverting the focus of the improvement effort — for example, if your primary aim is to improve “Customer collaboration” establish this as your secondary metric and work on improving something else instead; maybe contract negotiation — i.e. “How to improve our contract negotiation practice without hurting customer collaboration?”.
Happy improving with “inversion of control”!