How Lightweight is a Lightweight Process?

Posted in Management

A couple weeks back, as I was reading another big-mailing-list email about how we’re instituting a new set of processes to meet a set of implied standards, I saw that the author reassuringly stated that his implementation was lightweight. And in fact, outside of NASA’s admittance to running a tight software ship, I can’t recall any process, as described by its creator, as anything but lightweight.

Process is a funny concept. In creative professions (e.g., most aspects of software development)—in a Western, individualistic society—the cultural default is to refuse adherence to process, except when chaos and inefficiencies reign, in which case process is begrudgingly accepted as long as it’s not too strict. The label we’ve collectively settled on is “lightweight”, which has been rendered meaningless when it describes everything from rigid Agile frameworks to the preprogrammed complex rulesets around Holacracy. In fact, the term is now used more as a literary signal meant to preemptively quell process anxiety than any real description of what said process entails.

So if “lightweight” is synonymous with “good” when it comes to the world of process descriptions, then here’s my definition of what a lightweight process really means:

  1. People understand what it’s trying to do
  2. People agree it’s an improvement
  3. People will modify and tweak it to suit their needs

That is, it matters less how much stuff is required; what matters is that its implicated practitioners understand the directions and why they’re set, and have the autonomy to mold it to their work/life styles. Assuming people agree on its purpose, process adherence should come naturally.

For instance, take the humble standup. Most agile-practicing teams swear by this meeting the first thing in the morning, and at a high level, the justification of getting to know what others are doing makes sense. I have implemented this myself, seen others implement this, and have also worked with teams that resisted its existence. To map standups to the points above:

  1. Standups aren’t supposed to be status update meetings, but it’s easy to fall into that trap. The main value of standups isn’t even in learning what everyone else on your team is working on, but more in looking for collaboration opportunities between team members.
  2. Standups are an improvement to communications mostly if the team doesn’t already talk regularly through chat, Slack, or stay in close physical proximity.
  3. Standups can be time-constrained, can be focused on just specific pieces of work, or can happen at other times of the day or even in reaction to events (e.g., getting word back from an external team that unblocks work).

And if the actual process isn’t all that complicated? Well, that’s just a happy coincidence.