In my last post, I spoke about the limitations of Best Practice.
I can imagine that some of you may be thinking:
“Well Mr Bennett, it’s all well and good to poke holes in rules of Best Practice, but what do you suggest we do instead!? We can’t just have a free for all! How will people know what to do?”
A free for all is not at all what I’m suggesting. In fact far from it. The deep and lasting irony about using Best Practice outside of its appropriate domain of use is that you get less actual control as people game the system to get around it.
Let’s use a concrete example to illustrate the point I’m talking about.
You might for example be using a process control framework (let’s call it Scrum) – and you can have a simple rule:
Rule A) “Only the Product Owner may abnormally terminate a Sprint”
Rule B) “Only the Team may abnormally terminate a Sprint”
Rule C) “Either the Team or the Product Owner may abnormally terminate a Sprint”
There have been passionate discussions (mostly online) as to which one of these rules is “right”, and evidence of one kind or another exists to support all of them. Clearly, as written, they cannot all be right.
Which one is Best Practice?
Rules are used to guide behaviour and also provide an objective justification for punitive action towards rule breakers.
In our society we are all aware of the punitive actions associated with our criminal justice laws.
But terminating a sprint is a process rule, not a criminal justice law. If a criminal justice law is broken, it is used in a court of law in order to provide guidance as to whether the rule was in fact broken and what the appropriate punishment should be. When was the last time this happened on your project?
Process laws are therefore less about punishment and more about guidance. But how suitable are rules for this purpose?
Rules like these unfortunately offer very little guidance for complex situations. And the more general they are, the less guidance they seem to offer. You could easily argue that Rule C could be replaced by “Anybody except the ScrumMaster may terminate a Sprint” – it may sound silly, but really, what is the effective difference between that statement and the rule as described?
The problem with rules is that to be clearly enforceable, they need to be pretty specific – which is OK when your rule genuinely is “Best Practice” because everything else apart from following the letter is going to be an undesirable outcome. But if anything less than perfect is your aim, then simple statements such as “Only the Product Owner may terminate Sprints” begin to lose their utility and we instead direct people towards a “not terrible, but not great either outcome” – in many cases like these, the focus tends to be not on excellence but instead on preventing horrible failure. The problem with this approach should be obvious, you drag down the great outcomes to protect yourself from the bad. Maybe it’s me, but I don’t see a competitive advantage in that approach.
Narrative is a good option – in these series of narrative fragments I have provided an alternative to simple rules – and one in a very human form, one in which our race has been learning and passing on knowledge for centuries.
Instead of a single point, instead there is a rich tapestry of guidance and learning. One in which the team and organisation can add to themselves over time as they share their successes and failures.