Tips, Habits, Customs and Agility

I was listening to a Planet Money Podcast about tipping recently. According to the story, the custom of tipping has persisted even though the reasons that the practice was established no longer apply. According to the Planet Money story both waiters and customers think that tipping is useful, evidence to the contrary aside. The discussion led me to think about practices some teams do in the name of following a process.

Habits and routines are useful because they free you to focus on the important tasks.  Rituals and processes take a somewhat irrelevant decisions out of your hands, and conventions make it easier for others to understand code and other artifacts.  And when you are starting a new approach to work, following the rules by rote can help you understand the method. But circumstances change, and when the reason for the ritual has changed, there are a few possibilities:

• The practice is still useful, for reasons you didn’t anticipate when you started it.
• The practice adds less value, but it doesn’t add any overhead so there is no harm in continuing.
• The practice leads the team to spend energy addressing a problem that does not exist any more and causes waste.

To avoid instances of the last case that take up too much of you time, it is important to periodically reflect on why you are doing what you are doing, and it it still makes sense in your environment.  As your team adopts new tools, new practices, take time to think about whether what you are doing still makes sense. Periodic retrospectives are one way to capture this, so it’s important to set aside time to review how you work. (And even to set aside time to review how you do retrospectives!)

Lots of teams (and individual) follow process  steps with good intentions, yet they end up causing unnecessary overhead. For example coding conventions that made perfect sense in the days of fixed length variable names, and text editors that add overhead when you have refactoring IDEs and follow clear naming conventions.

The podcast also reminded me of  one of of my favorite Gerry Weinberg quotes (which I referenced in Software Configuration Management Patterns):

 S_urvival Rules are not stupid; they are simply over-generalizations or rules we once needed for survival. We don’t don’t to simply throw them away. Survival rules can be transformed into less powerful forms so that we ca still use their wisdom without becoming incongruent_

 (from Quality Software Management: First-Order Measurement)

Traditions and habits have their place. But if you are doing something simply out of habit you can benefit from acknowledging that fact.