Overlapping Behavior

March 19, 2019

Examples of redundant structures that overlap and support each other can be found everywhere in nature. Examples include: human vertebra, protein interactions in cell function, and network communications. In engineering, structural redundancy refers to the ability of a structure to retain its function without catastrophic consequences. To state it only slightly differently, it’s the redundancy of function that enables the structure to survive assault or crisis. Redundancy is therefore a desirable engineering attribute for a resilient system.

Redundancy is something that I use when weightlifting. When I lift a heavy weight, I rely on the following:

  1. The structural rigidity of my skeleton
  2. The dynamic rigidity of my muscles
  3. The hydrostatic rigidity of my abdomen as I use controlled breathing during the lift
  4. Wearing my belt

All three of these elements serve to stabilize me and provide a solid base for lifting heavy. Each contributes to the others and provides additional strength or stability. Some are essential, like skeletal rigidity. If I lose that, I’m totally screwed. However, to a greater or lesser degree, the other elements, like muscular and hydrostatic rigidity can fail, and I will suffer varying degrees of lesser consequences without necessarily breaking anything. In fact, it happens all the time. I fail to breathe correctly, and I still get the lift. I fail to tense up in the right places and I may still get the lift. Or not. It’s usually not catastrophic because there are multiple overlapping systems involved.

Do we get the same benefits of structural redundancy when it comes to behavior, and more specifically, our habits? When it comes to scheduling and planning, it’s not uncommon to have both a calendar and a “to do” list. You might even supplement those with your email backlog. All three of these habits or tools help serve to insure that you get stuff done in a timely manner. We also have quite a bit of redundancy in our communication. For instance, there is voice, email, voicemail, collaboration tools like Slack, Skype, and others. There are social media tools like Twitter, Facebook and Instagram (although I’m at a loss to come up with what useful purpose these serve – social cohesion?). So there are many overlapping behaviors or habits we have that enable us to get work done reliably during the day.

Here’s the cool part: the benefit of redundancy is that we can still succeed even if one of those mechanisms fails. Is your email server down? Try facebook. Or Twitter. Or heaven forbid, go “old school” and give them a phone call. Stuff will still get done. This kind of redundancy is at the heart of all systems that we think of as very reliable. When we have a set of redundant, highly reliable habits, we have a name for that too: discipline.

So if you want to build a team that delivers stuff reliably. The kind of team that gets things done in a crisis. A team that can be relied upon to deliver. Consider using redundant systems of habit. Use sprint planning AND release planning. Use daily stand-ups AND weekly checkpoints. Use retrospectives AND product reviews. Take advantage of multiple redundant habits and you will become respected for your discipline.

A Call to Practice

November 7, 2010

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.