A Call to Practice
Recently I’ve been thinking a lot about the way that we practice our profession. It’s probably because my daughter recently started Taekwondo and I watch her practicing her Pumsae or Kata during each class. For her, this practice is very real and disciplined. There is very little ambiguity. I realize that in software development we use the term “practice” pretty loosely compared to a lot of other disciplines. It’s not that we don’t use the term often, in fact we seem to use it every chance we get. It’s as if by repeating the word “practice” we might somehow actually arrive at that professionalism that so many desire. Call it a form of magical thinking. My favorite term of practice is “Best practices”, which are often neither best nor practiced. Best practices belong to some sort of terminological hall of fame alongside “military intelligence” and “near miss”. So what exactly is this beast called practice?
Wikipedia defines practice as:
Practice is the act of rehearsing a behavior over and over, or engaging in an activity again and again, for the purpose of improving or mastering it.
That seems like a pretty good starting point. So, if I’ve got this right, practice is a preparatory event that we do over and over again in order to improve. What do we do that might qualify? Well, we have an entire pile of Agile practices that we might choose from:
The planning game
The daily stand-up
The retrospective
Test driven development
Pair programming
etc.
Those are all practices right? But how often do we really practice them? Once every two weeks you say? Every day? Perhaps. But that’s not what I’m asking. You see, I think there is a meaningful difference between just doing something and practicing something. To me, practice implies a kind of deliberate inquiry. There is an expectation that we will experiment when we engage in practice. We might slow things down in order to identify weak spots. Or we might stop at various points to review our state, whether it be our posture, our attitude, or even our mindset. Often when we practice there is a mentor or coach – someone whom we trust to critique our performance and help us to identify areas for improvement.
So given this new criteria, let me ask again. How often do you practice your agile techniques? Well, to be honest, if you are anything like me the answer is: not all that often. In fact, almost never. So what does that mean? Well, for me it means that although I do many of these practices over and over again, I rarely do them differently. Certainly not with a whole lot of introspection and review. So do you think those practices improve much as a result? Of course not.
Something tells me that I should get started. At least if I want to be really good at what I do. It turns out that for some of these practices I’m in luck. People have come up with activities like coding dojos where you can practice TDD and Pair programming. That’s fabulous, but what about the others: planning, stand-ups, and retrospectives? I have a few ideas, and I’m looking for more.
You see, in the end, I think we call a lot of things practices and what we really mean is “things we do”. We don’t really practice them, not in the disciplined sense. So this is my call to action: find the practice in what you do. Engage in real practice with thoughtful deliberation. Find the techniques that we can all practice, the metaphorical scales that we can use to improve our technique – to become the very best at what we do.