Many years ago some friends and I went to an outdoor concert. The music was great, the weather was perfect, and there were lots of people taking off their shoes to dance barefoot in the grass. My friend was one of them. The show ended late and as the crowd dispersed in near total darkness, my friend discovered that one of her shoes had gone missing. After nearly an hour of searching, she dumped out the contents of her handbag and used her purse as a shoe!

This is why when asked by customers, prospects, managers, and peers if we are using best practices in our work, I frequently betray my Project Management Office and Operations colleagues and reply that there’s no such thing as a best practice. The phrase “best practice” implies that there is just one universally correct way to solve a problem or achieve a result – and of course, this isn’t true! In most circumstances, wearing a purse on your foot would not be considered a best practice. However, given the choice between walking across a long gravel parking lot late at night with a bare foot or covered with a pocketbook…well, you get the idea.

Cem Kaner, James Bach and Bret Pettichord used the following illustration of this concept in Lessons Learned in Software Testing.

Consider two testing projects and the practices appropriate for each:

One is developing the control software for an airplane. What “correct behavior” means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do — or don’t do — would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone’s work.

Another project is developing a word processor that is to be used over the web. “Correct behavior” is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters — 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as “damage to be routed around”.

• Testing practices appropriate to the first project will fail in the second.
• Practices appropriate to the second project would be criminally negligent in the first.

Requiring blind adherence to best practices ignores an organization’s environment and stifles creativity and innovation. It also fosters a culture of risk-aversion, process and policy inflexibility, and fear of repercussions. This is not the recipe for success in today’s ever-changing global marketplace. It also doesn’t make for a very fun place to work. I’d like to propose that we change the question. Instead of looking for assurances that best practices are being followed, let’s ask if we are a flexible and adaptive learning organization. Because sometimes, a purse really does make the best shoe.