Best Practices Are Dangerous When Adopting Agile

With most organizational change, after someone figures out the right or best way to do something, that way of doing it is captured as a “best practice” and shared with everyone else. For some types of work, collecting and reusing best practices is a tremendous aid to the change effort. An organization that is selling a product to a new type of customer may, for example, capture best practices for overcoming objections from potential customers.

When transitioning to Scrum, however, collecting best practices can be dangerous. Although team members should always look to share with one another their newly discovered good ways of working, they should resist the urge to codify them into a set of best practices. What’s good for one team may be too prescriptive for others. For example, one company I visited had decided that all daily scrums needed to be held no later than 10:00 a.m. I found this an extremely unnecessary dictate. I’m not entirely sure what purpose the dictate served, but many employees interpreted it as a lack of trust by their management.

Even a good practice can lure teams into a false complacency once it has been established as the “best.” Like sirens singing to us from the rocks, best practices can tempt us to relax and stop the effort of continuous improvement that is essential to Scrum. Mary Poppendieck quotes Taiichi Ohno, originator of the Toyota Production System, as saying that “there is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over.” Ohno goes on to say that if we establish something as the “best possible way, the motivation for kaizen [continuous incremental improvement] will be gone.”

In Scrum, sharing success stories and methods that work is a good idea. Establishing one set of solutions as the best is not. Don’t limit the very improvement you are seeking. Instead, let your organization’s standards evolve with you as you grow more agile. For more information on this topic, see Succeeding with Agile: Software Development using Scrum.