July 04, 2016
“What would you say are the best practices for?”
I’m about to slam my head into my keyboard, but I restrain myself. It’s a simple enough question and I probably have the answer. I’ve helped out a lot of folks with this type of question so that they can start moving forward in a more deliberate manner. That is a good thing! Answering this question is usually very easy. Somewhere deep inside, however, I don’t really want you to hear the answer.
Not because I want to hold out on you. Not because I expect you to know the best practices. Not because I have some sort of jaded outlook on the whole thing (well, maybe that plays a part).
I simply am losing the desire to recommend to you what amounts to “what everybody else is doing”
In my career I have been a junior developer, an IT guy, a team lead, a manager, a software architect, an agilist, a speaker, a guy in that rock band that almost did something, the ‘techie guy’ in the sales meeting, a tools evangelist, etc. I feel that I’ve had enough experience over the years that I can comfortably sit down with you and there’s probably a greater than 50% chance that I can help you be better than you were yesterday at whatever you are doing.
That is why I feel confident telling you that “Best Practices” suck
Best Practices are not ‘wrong’. They accurately represent what are the common practices that work well. I tell you they suck because they are not, in fact, the Best. They are common. Run of the mill. Nothing special.
These practices will help you avoid mistakes, which is a good thing. Mistakes that can be avoided are costly. If you spend a year doing everything wrong and realize you have to start over, you would hate to hear that others have done this a thousand times before and what you just learned was a common “best practice” in the industry.
These practices will help you mitigate risk, which is another good thing. It is much easier to do something with a roadmap to guide you along. You don’t have to wonder if you are going down the wrong road, because the ‘best practice’ will guide you towards your goal.
Assuming your goal is mediocrity.
I am not alone in this
Far be it from me to claim originality in this area, for I am not the first to reach a tipping point on the use of Best Practices. Other folks like Peter Vogel (2016), Heather Bussing (2013) and Daniel Rasmus (2012) have hit the same frustration limit. We need to learn from these practices, for sure, but these are not the untouchable rules etched in stone that we pretend them to be.
The life of a Best Practice
At one point, every Best Practice was just an Idea. Somebody (or maybe multiple somebodies in parallel) thought up a new way to do something. An example from the software delivery field is the concept of locking down requirements at the beginning of a project to reduce risk of scope creep during a project. This seemed like it might work to solve a problem, so why not try it out?
Through trial and error, this new Idea goes through ups and downs until it becomes a Practice. At this point, we’ve learned enough from our failures to have a repeatable process that avoids these failures and seems to apply to multiple situations. Benefits abound!
Full of idealistic vigor, we begin sharing our Practice with the community at large and it may or may not catch on. Others may try it out for themselves and provide valuable feedback. At this point, our Practice is becoming refined and growing into a Mature Practice.
It is also possible that, completely independently, other teams and organizations may have reached the same conclusions as yourself, thus validating your Practice by stating that they have a similar Practice. Through this sharing, refinements inevitably occur to take the best points of all the similar Mature Practices and thusly is born a Best Practice.
Why is that bad?
It’s not bad. It’s just mediocre. Consider the life of the Best Practice we just examined. At the end, we are:
- Avoiding failures we experienced in the past.
- Executing ‘common’ parts of the original Ideas that everybody agreed on and worked in multiple scenarios.
Any traces of what would make something unique to your particular business or scenario have been stripped away in place of a nice neutral gray.
It’s like a Venn diagram, except all the good stuff isn’t in the middle.
Am I being overly dramatic?
Sure, Best Practices are better than Bad Practices. If you are just trying to get something going in the right direction, it’s not a terrible place to start. Especially if you are looking around in confusion, realizing you have just wandered into the unknown, and need some sort of map to guide you.
Much like the tourist attractions when you arrive in a new city, the Best Practices are safe, well-travelled, and you can be sure that the experience has been optimized for new arrivals. As any seasoned traveller will tell you, however, the true rewards are off the beaten path where you might get lost.
Innovation requires mistakes
If you are not content with being in the trailing wake, you need to innovate. This means venturing into the unknown and making a lot of mistakes. Fail early, fail often, and be ready to react. Lean processes are all about the idea of reducing waste but also promote hypothesis-driven improvement.
Instead of asking around for what everybody is doing, ask instead: What is everybody else NOT doing?
There are probably some very valid reasons not to do things, but the only way to disrupt a particular industry is to do something that nobody else is doing because they aren’t sure it will work.
We need to continuously improve the work we are doing. We can be better today than we were yesterday. To continuously improve we need to think about where we want to be and start taking small to improve towards that goal. We might fail along the way, but learning from these experiments is key to improvement.
A good first step? Stop making ‘what everybody else is doing’ the end goal!
