This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Getting Beyond Agile Best Practices
As working adults, most of us have limited opportunity to assimilate new skills and information. This is especially true for information that presents a disruption to established patterns that ease our already taxing cognitive load. So, while misbegotten, the search for ‘best practices’ for agile development is understandably popular. With plenty to do, and precious little time, most prefer the elevator pitch, the executive brief, the Cliff’s Notes version. Seeking agile best practices is essentially asking for a pre-sort: “help me fit this into a frame I already have so I can use it immediately with a minimum of effort”.
Unfortunately, this frame doesn’t fit the agile picture. A best practices mindset assumes that every problem is more or less the same; all that’s necessary to approximate success is the rote application of nostrums gleaned from the experience of your predecessors. This approach makes sense for some types of work – baking, for example – but unfortunately not for the type of work we encounter often in modern software, and certainly not for the challenges presented by complex product development.
But, you might argue, isn’t Scrum simply a collection of best practices for agile development? Apply the cookbook rule: When followed to the letter, does Scrum guarantee a viable, high-quality product? There are reasons why Scrum is the dominant agile framework, and why I enthusiastically teach and coach teams to use it, but the answer is no – it guarantees nothing. Scrum is best likened to a game, one played by development organizations in order to improve their processes and hopefully by extension, their product. But this improvement is far from guaranteed. Like football (“soccer” in the United States), it has rules and roles and artifacts that must be observed, but simple observation ensures nothing except that you’ve played a game of football. If your players are in poor shape, lack energy and imagination, and are uninterested in enjoying the game or improving their performance, this will surely show in an uninspired, boring match that isn’t likely to yield either good sport or entertainment. Likewise for Scrum; Among other things, it takes commitment, focus, openness, respect, and courage (these are, by the way, the official five values of Scrum) to ‘play’ Scrum well and to thereby realize its benefits.
So then, what are the agile best practices?
The first answer is: There are no best practices for agile development – at least not as best practices are commonly conceived – because the problems for which agile is intended aren’t solvable by prescriptions. The closest we have are the principles behind the Agile Manifesto. But if you’re looking for sure-fire how-tos, you won’t find any there.
Another (somewhat flippant) answer is: They’re all best – do them all. Probably can’t be any worse than what you’re doing now.
Another answer, one I think most in keeping with the empiricism embodied by agile values and principles, is: It depends – on you, your team, your product, and your organization. I recommend you try as many as you can, and find out for yourself.