Very true. I’ve watch dozens of organizations adopt practices in order to have new rules to follow, but these organizations have tended not to make any lasting change nor realize significant improvements. At the risk of oversimplifying the situation, we all know from direct personal experience that merely following rules leads merely to accurately-projectable mediocrity.

We see it in poor customer service and mediocre product quality. “The system won’t let me do that” or “That goes against our policy” reflect this follow-the-rules approach. Sadly, many people interpret my emphasis on strict, diligent, fundamental practice as a new set of rules to follow blindly and forever. In the best case, they merely see me as a hypocrite and ignore me, but in the worst case, they follow my advice and it leads them mostly nowhere. I think they simply forget to use the rules most effectively: to learn.

Ward Cunningham’s Wiki
The Original Wiki

Here I have to resurrect an idea from our “distant” past – “distant” by internet standards – practices as “études” or “finger exercises” or, to choose the more modern simile, “kata”. You can read about this idea from the Dead Sea Scrolls themselves, starting at http://c2.com/cgi/wiki?PracticesVersusEtudes. This short article (2-minute read) reminds us to distinguish études from practices: we practise études to learn something specific, and perhaps we practise them regularly-but-infrequently even after we feel like we’ve mastered them, simply to keep up our strength; we adopt practices when we see value in doing something all, or at least most of, the time. We therefore start practising test-driven development as an étude, but perhaps decide later to adopt it as a practice (or not). Even if we don’t adopt it as a practice, we might test-drive something a few days per month to see what the technique has next to teach us about design or about testing. When I teach my World’s Best Intro to TDD, I ask the attendees to treat TDD as an étude while working through the course, with an eye towards deciding by the end of the course whether to continue to practise it as an étude, adopt it (on an experimental basis) as a practice, or ignore it entirely. I don’t want you to learn TDD so that you have a new set of rules to follow blindly for the rest of your programming career.

I encourage you to treat all practices this way. Don’t adopt a practice until you’ve treated it as an étude. This means choosing a timebox during which to practise. It means taking time to reflect on what happened when you practised. It means talking to other people about what you’ve experienced when you practised. It means documenting what you’ve learned. It means focusing on the technique while keeping an open mind about the results. It means using what you’ve learned from the practice to inform other aspects of your work. I think you’d do will to treat any practice this way, whether from Scrum, XP, FDD, DSDM, Kanban, or whatever method. Mostly importantly, it means focusing on what you can learn from a practice, rather than expecting it to function as a foolproof set of rules to follow indefinitely and inattentively. While I don’t believe for a second that this guarantees continuous growth and improvement, not doing this will absolutely guarantee a ceiling on your results, no matter which well-meaning rules you choose to follow. Even the ones I promote!

So, if you plan to adopt practices as new rules to follow, rather than as techniques from which to learn, then save yourself some energy and just keep following the rules you already have. You probably won’t notice the difference.