Documenting Your Best Practices

I think it's important for the software organization to have documented Best Practices to provide a common starting point for all engineers, whether new or well-seasoned. The term Best Practice simply means this is the most efficient or simplest or greatest customer/business value, (I would stress the latter) way of doing something known to date. What Best Practice doesn't mean is that it's a rule. Rules change infrequently but Best Practices are always open to change.

The business may have a rule that an agile team must have a daily stand-up meeting visible and accessible to anyone who wishes to attend given the space available. How an agile team implements the daily stand-up meeting is subject to one or more Best Practice. There may be a Best Practice that has the Scrum Master facilitating this meeting, asking three questions: what have you done, what will you do and what problems are you having. There can be another Best Practice that has a different development team member facilitating the daily stand-up each day in a round robin fashion. Both these Best Practices can exist at the same time, in the same document, until one is proven better or, if they are equally beneficial, one is proven more popular.

I think that Best Practices are potentially updated after each agile teams' retrospective. One major pitfall of documenting Best Practices is these are never reviewed and updated. The business must guard against Best Practices becoming static and agile teams or the development manager need to ensure there's an ongoing effort to review and validate all Best Practices. If the Best Practices document hasn't changed in 30 days then maybe the agile teams are not trying to improve since most Best Practices are used in each sprint and subjected to retrospective review at the end of each sprint. If for example, all agile teams adopted the practice of having the Scrum Master facilitate the daily stand-up, having tried and rejected having a development team member facilitate, I would probably remove the Best Practice of having a different development team member facilitating the daily stand-up.

One last point, I don’t think there’s generally a great amount of detail in Best Practices as these are not always step-by-step procedures, at least not in an agile environment. If there’s a Best Practice to use planning poker in a sprint planning meeting (or grooming session) then there’s probably a brief description of what planning poker is and maybe a link to Wikipedia. Planning poker is a good example since there are at least a dozen different implementations that are almost but not quite the same. However, a code review Best Practice may be very detailed because there’s proven value in your company by following these detailed steps.

 

Best Practices document the way you do things now so you have something to use to measure improvement against. Best Practices become the organizations best training aid for new-hires and is the guide for all. Best Practices change all the time as agile teams experiment and replace outdated practices with new and better practices. Taiichi Ohno of Toyota Lean Manufacturing fame is quoted as saying, "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. The standard work is only a baseline for doing further kaizen. It is kai-aku [change for the worse] if things get worse than now, and it is kaizen [change for the better] if things get better than now. Standards are set arbitrarily by humans, so how can they not change?" All you need do is replace "standard" with "Best Practice".

 

 

 

Tweet