On This Page

The Definitive Guide to the What and When of Product Owner Responsibilities

The Definitive Guide to the What and When of Product Owner Responsibilities

Sign up to get your free download

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.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.