Questioning "Best Practices" for Software Development |
||
A very popular term within the IT community is "best practice". It's a wonderful marketing term, how could someone possibly argue about adopting a best practice, but does the concept really make sense? I'm not so sure. There are many examples where a practice that is considered "best" in one context is questionable within another. As professionals, it seems to me that we should strive to understand the context which we find ourselves in, and then apply the practice which is best within that context. In other words, we should really be focused on "contextual practices", not "best practices".
|
|
When you observe what's going on within the agile community it becomes clear that many "best practices" really aren't. For example, consider the following practices:
Ideally, we should talk about best practices at all but instead should talk about contextual practices. Depending on the context, sometimes a practice is "best" and sometimes it's not. Calling something a "best practice" implies that it's a good idea all of the time, something we inherently know to be false. Having said that, the term "best practice" clearly has more marketing value than the term "contextual practice", and in this industry we know that marketing typically wins over truth, something that is clearly not a best practice. The Agile Scaling Model (ASM) helps to provide insight into the context which IT teams find themselves in. It describes 8 scaling factors, and implies two others, which provides this context. The factors are:
|
The point is that different teams find themselves in different situations, different contexts if you will, and therefore will tailor their approach to reflect that situation. They will adopt practices which meets their needs and tailor those practices accordingly.
I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer. A full description of what I do, and how to contact me, can be found here.
Copyright © 2005-2010 Scott W. Ambler
|