Standards Watchdog - Do you provide the reason behind rules when enforcing them?
Learning lessons the hard way is a fact of life, but one of the great things about teamwork is that you can help others avoid making the same mistakes over and over again. This is the foundation of great standards! But what happens when a new (or old) team member misses a standard?
"The floggings will continue until morale improves"
- A bad manager
Everyone makes mistakes. If you run around wielding your authority as a cudgel, telling them they'd better comply or else, two things will happen:
- They will resent you
- They will only bother following standards when you're around
For example, if one of your standards is for developers to send "test please" emails, there's likely a hard-earned lesson behind it - otherwise, that rule wouldn’t exist. Instead of simply enforcing the rule, take a couple of minutes to explain why it matters and the value it brings.
| From: | Adam |
| To: | Mark |
| Subject: | No test please email |
Figure: Bad example - This email doesn't explain why this is so important
| From: | Adam |
| To: | Mark |
| Subject: | Test Please emails standard |
Hi Mark
Regarding that PBI you worked on yesterday.
We have a standard about sending "test please" emails to the client (check out the rule).
This saves time by getting early feedback, allowing bugs to be fixed while it's still fresh in the developer's mind.
The longer the feedback loop takes, the more expensive a PBI becomes to the client.
Please make sure this is part of your workflow ;)
Figure: Good example - Provide a link to your standard and the main reason(s) why it is important
