How many times have we heard a software consultant or tool vendor say the phrase “best practice?” 
In this context, best practice is mostly marketing lingo to get us to use their services or tools. It is selling by guilt. After all, if it’s the best, we would be a fool not to buy it! If it is the best, then it must be worth the high price the vendor is charging. Or is it?
Let’s analyze the word “best.” First, I am reminded of a cartoon about Father’s Day. The young son is looking for a gift and sees a rack of several T-shirts with the words “Best Dad Ever.” The son looks up at the mom and says “If a dad is the best, shouldn’t there only be one of these shirts?” If you apply the definition “Surpassing all others in excellence, achievement, or quality”, then the son is right. Only one practice can come in first!
I attend many Agile presentations at conferences and meet-up groups. I become skeptical when I hear a presenter use “best practice” in a slide or discussion. I wonder about the presenter’s real background. What experiences does the presenter have to make boastful comparisons? How does the presenter know which ideas are “best?” Does the presenter know how “best” applies to our particular situation?
We need to know the universe of all the options. If we are doing pairwise comparisons, we should be using “better.” For instance, it’s better to ride the bus to work than to walk. Then we can give reasons such as we’ll be protected from rain if we are in a bus. But there are lots of options for transportation, and just maybe, there is an alternative option that would even be better, such as driving a car to work. The bus may not be the “best”, but for our situation, riding the bus may be “good enough.”
Maybe we do not need the “best” to make our Agile journey and to reach our goals at the top of the mountain?
- Do we need a sophisticated tool for managing our user stories? The vendor may say their tool is part of a “best practice” for managing User Stories. The tool may have lots of robust features that are necessary or useful for large and geographically distributed teams. But for your co-located groups, it may be “better” using index cards where the team can touch, hold, and move the cards on a white board. Or maybe a spreadsheet will work. Those could be our “best” practice. Stated differently, our current practice is “good enough” to meet our needs.
- Do we need to write automated tests? Many software projects will benefit from writing and executing automated tests, but for some it may be “good enough” to continue with manual tests. The costs of writing, setting up the environment, and managing the automated tests may be more than the benefit. There may come a time in the project when it would be “better” to automate the manual tests, but that time may be later in the project when the software is more stable.
- Does the development code need to be the “best” to release? There can be a lot of variables in making release decisions, because we do not want to release with defects that will negatively affect sales. We can release if we have enough value and quality to begin generating some revenues and gain valuable feedback from the early adopters. An analysis to know if you have met the minimal viable product (MVP) and minimal marketable feature (MMF) with the desired quality can guide the project on knowing if the release is “good enough.”
Look at your situation and figure out what will work for you. Do your research on how other similar teams and organizations have benefited from different practices. Be Agile with your practices and tools. Understand your goals, and inspect and adapt as your situation changes to better achieve those goals. Be skeptical when someone pitches their product and practices as the “best.” What is “best” for someone else may not be best for you.
We strive to make www.agile2success.com into a “better practice” resource for cultivating and growing successful Agile transformations. With the large number of Agile resources available out there, we will never be able to honestly market it as the “best.” Our goal for the blogs is to make them informative, interesting, and entertaining so they will at least be “good enough” for you to keep reading and maybe better understand some practical solutions for the Agile challenges you are facing.
Finally, best wishes on your organization’s Agile journey up the mountain … and in this case, I do mean “best”!
