Best Practices


Listen Now

Subscribe on iTunes

This week we are doing something special. Right after the New Year holiday, all of the regulars from the Software Process and Measurement Cast gathered virtually to discuss the topics we felt would be important in 2016.  The panel for the discussion was comprised of Jeremy Berriault (The QA Corner), Steve Tendon (The TameFlow Approach), Kim Pries (The Software Sensei), Gene Hughson (Form Follows Function) and myself. We had a lively discussion that included the topics of women in tech, microservices, capabilities, business/IT integration and a lot more.

Help grow the podcast by reviewing the SPaMCAST on iTunes, Stitcher or your favorite podcatcher/player and then share the review! Help your friends find the Software Process and Measurement Cast. After all, friends help friends find great podcasts!

Re-Read Saturday News

We continue the re-read of How to Measure Anything, Finding the Value of “Intangibles in Business” Third Edition by Douglas W. Hubbard on the Software Process and Measurement Blog. In Chapter Four, we focused on two questions. The first is getting the reader to answer what is the decision that measurement is supposed to support. The second is, what is the definition of the thing being measured in terms of observable consequences?

Upcoming Events (more…)

It is good to be optimistic, but we still want airbags...

It is good to be optimistic, but we still want airbags…

Is optimism a good thing?  Optimistic people live longer and are typically happier then less optimistic people.  Michael Sheier and Charles Carver report in Effects of Optimism on Psychological and Physical Well-Being that optimism may lead a person to cope more adaptively with stress.  Unfortunately the personal benefits of optimism do not tend to expend to projects and teams.  So why is optimism good for most of people while it is a problem for teams?

  • Optimism causes risks to be overlooked.
  • Optimism causes estimates to be missed.
  • Optimism causes plans to be slipped.
  • Optimism causes the need for heroism.

In people optimism is a great thing, but for project managers optimistic realism (defined as optimism balanced with “REAL” data) is far healthier. Regardless of my plea most teams or leaders eschew realism and plan optimistically.  We are trained to be problem solvers; trained that we can surmount any problem by sheer force of will, therefore we plan optimistically.  Planning for optimism only counts when you define planning for optimism as a plan based on measured performance plus planned innovation.  Innovation must be planned because projects cannot count on serendipity to achieve their goals and neither can teams nor an organization count on lightening striking twice without a plan and process to attract it.

Agile teams of all shapes and flavors need to separate how they view themselves from how they view their role.  Personal optimism is great, but professional optimism should be replaced with optimistic realism.  Realism is seeing the forest for the trees and planning to make sure you achieve your goals.  A self-managing team must see risk, to predict the future and plan for innovation and change to deliver in a timely, accurate and efficient manner. Teams must focus on performance because they are charged with delivering functionality while making a customer happy.  It takes optimistic realism to deliver.  In short:

  • Optimistic realism causes risks to be identified.
  • Optimistic realism recognizes capacity.
  • Optimistic realism supports making flexible plans.
  • Optimistic realism fosters teams.

Optimism without measurement and data as a balance is unrealistic.

To paraphrase Edwin Starr, “Best Practices, huh, what are they good for? Absolutely nothing,  Say it again . . .”

Every organization wants to use best practices. How many organizations do you know that would stand up and say we want to use average practices? Therefore a process with the moniker “best practice” on it has an allure that is hard to resist.  The problem is that one organization’s best practice is another’s average process, even if they produce the same quality and quantity of output.  Or even worse, one organization’s best practice might be beyond another organization.  The process reflects the overall organizational context.  It is possible that adopting a new process wholesale could produce output faster or better, but without tailoring, the chances are more random than many consultants would suggest. For example, just buying a configuration management tool without changing how you do configuration management will be less effective melding the tool with your processes.  Tailoring will allow you to use the process based on the attributes of the current organizational context such as the organization’s overall size or the capabilities of the people involved.

An example of an organization’s best practice that might not translate to all of its competitors is the use of super sophisticated inventory control computer systems used at Walmart. Would Walmart’s computer system help a local grocery store (let’s call this Hometown Grocery)? Not likely, the overhead of the same system would be beyond Hometown’s IT capabilities and budget.  However if hundreds of Hometown Groceries banded together, the answer might be different (tailoring the process to the environmental context).  Without tailoring the context, the best practice for Walmart would not be a best practice for our small town grocery.

The term best practice gets thrown around as if there was a dusty old tome full of magical incantations that will solve any crisis regardless of context (assuming you are a seventh level mage).  There are those that hold up the CMMI, ISO or SCRUM and shout (usually on email lists) that they are only way.  Let’s begin by putting the idea that there is a one-size-fits-all solution to every job to rest.  There isn’t and there never was any such animal.  Any individual process, practice or step that worked wonderfully in the company down the street will not work the same way for you, especially if you try to it do it same way they did.  Software development and maintenance isn’t a chemical reaction, a Lego construct or even magic.  Best practices, what are they good for?  Fortunately a lot, if used correctly.

Best practices find their highest value as a tool for you to use as a comparison in order for you to expose the assumptions hat have been used to build or evolve your own processes.   Knowledge allows you to challenge how and why are you are doing any specific step and provides an opportunity for change.  How many companies have embraced the tenants of the Toyota Production Systems after benchmarking Toyota?

Adopting best practices without regard to your context may not yield the benefits found on the box.  If you read the small print you’d see a warning. Use best practices only after reading all of the instructions and understanding of your goals and your environment.  This is not to say that exemplary practices should not be aggressively studied and translated into your organization.  Ignoring new ideas because they did not grow out of your context is just as crazy as embracing best practices without understanding the context it was created in. Best practices as an ideal, as a comparison so that you can understand your organization makes sense, not as plug compatible modules.