Just under 4 years ago I set myself a goal to “socialize the concept of technical debt” within my organization. I had a strategy but no visible means of measurement. When I’d achieved my goal it was obvious that I’d succeeded but I had no direct evidence to prove it. – and why bother? – I succeeded.
Thanks to Luke Morgan (Agile Muze) for the inspiration of the “Elephant Test” – I’d never heard of it until last week.
For years everyone I know has been indoctrinated into using “SMART” goals (as defined in the early 1980s). As a line manager, employee of multiple large corporations and one-time domain expert in learning and performance management systems I too bought into and supported the “SMART” mnemonic.
Here’s a challenge – try running a 5 whys exercise on each of the attributes of SMART.
- Specific,
- Measurable
- Attainable
- Relevant
- Timely
I can develop valuable meaningful responses (not excuses) to most of these except measurable.
I’ve spent enough years working for corporations that love to measure to have a very good handle on the values and dangers of measurement. But until my inspiration from Luke, I never had an alternative.
Today I do!
Why measure something when you implicitly know, trust and recognize what you’re looking at?
The Elephant Test “is hard to describe, but instantly recognizable when spotted”.
A big leap in agile management is trust. Trust your teams to do the right thing.
- If you trust your team to set and accomplish their own reasonable goals, you must also trust their judgement.
- If you trust their judgement, they must be able to recognize when they’ve achieved a goal.
Measurement is the most brute force way of recognizing something – but not the only way.
Software development and management is a knowledge activity. We tacitly know what’s right and wrong and we openly share that recognition. Occasionally we choose to measure but much of the time we trust our judgement and that of our teams.
So if the team says they saw an Elephant, chances are they saw an elephant.
Or don’t you trust them?
If that Elephant happens to be that your team believes they’ve met their goal and their stakeholders agree, why must that goal be explicitly measurable?
I know when I’ve made a difference and those around me know when I’ve done a good job. That team consensus is far more rewarding and more trustworthy than preparing measurable evidence – it’s also a lot harder to game and a lot harder to sub-optimize your behavior to group perception than around numbers.
Next time you’re looking at goal setting. Don’t go overboard on making them all measurable. If they can pass the elephant test, that should be more than sufficient.
Try starting out with a clear simple vision, good direction, a suitable time window, a strategy and some commitment to do the right thing and work from there. You’ll know amongst yourselves when elephant-testable goals have been achieved (and delivered in good faith). These may also be some of the most valuable impacts your team can have.