Three Terms in Software That We Should Consider Retiring 

There are some terms in common use in the software industry that, while originally well-intentioned, have since become damaging rather than useful. 

“Sprint”

Sprints were originally meant to create some focused time for engineers to give them space for concentration and deep work. They are only supposed to happen periodically, and in between less intense phases of planning and learning.

The unfortunate reality is that in most Scrum teams, the group ends up sprinting all the time.

Many Scrum teams have sprints as a constant fixture, filling entire calendar years in 2-week blocks. The amount of work done each sprint is measured and copious management time is spent analyzing and improving that velocity.

Guilt sets in when engineers don’t make all of their commitments in a sprint, causing end-of-sprint stress and rushed work with lower quality to make sure enough story points are offered at the sprint altar. And once a sprint ends, a new one starts immediately after the last one. Over time, this leads to a vicious cycle of team attrition, loss of organizational knowledge, and managers need to spend more time hiring, onboarding, and training, only to burn everyone out again. 

Long-term sustainable development is better done in pulses, alternating between a period of heads-down, non-interrupted engineering and a less intense “come up for air” phase of customer interactions, retrospectives, creative explorations, direct feedback, and learning.

Athletes can’t sprint all the time, and software teams can’t either. Another term to consider is “iteration”, which focuses more on the outcome of what the team accomplishes (iterative improvement of their product for their customer’s benefit) instead of focusing too much on the process of how they achieve it (through a sprint).

“Culture Fit”

Hiring and building effective teams is tough, and requires thoughtful preparation and process. The right hire can radically boost a team’s morale and productivity, but the wrong hire could catalyze destructive behaviors and cause a team to implode.

Some years back, the term “culture fit” gained prominence in the tech industry, and is now widely used by hiring managers and teams when discussing the kind of people they’d like to recruit. The term was coined with good intentions, and initially meant, “avoid hiring people who would negatively affect the team.”

Unfortunately, the term “culture fit” biases teams to look for people like themselves, and away from others who might have a different socioeconomic, national, or linguistic background, gender, race, culture, or perspectives. Some teams confuse “fit” with “match”, and many teams suffer from having too many members with matching backgrounds, and not enough diversity.

A team that is highly diverse will be more creative in their problem solving, while also better represent the users of their own products.

In addition to thinking about “culture fit,” teams should consider whether a new team member will be a “culture add.” What will the new team member bring to the table that is new, different, or enhance the team’s diversity to make it stronger? If you find your team using the term “culture fit” frequently, try to be explicit about what that really means, to ensure people are not leaning on this as a cop-out and building a team that may suffer from staleness and sameness.

“Root Cause Analysis”

Incidents happen. Downtime occurs. Applications fail. After these things have happened, organizations usually try to learn from the experience and try to prevent the same problems happening again. For many people, a “root cause analysis” has been their go-to approach for this evaluation.

A root cause analysis is doomed to have limited effectiveness before it has even begun. It’s flawed even in its name, because it presupposes a single cause of failure. Humans love to feel control over a situation, and having a single cause to blame is satisfying and tempting. A single cause might seem fixable with a measurable amount of effort, time, or money. Worse still, sometimes that “cause” ends up being a person who then suffers all of the blame for the incident, and potentially loses their job.

Unfortunately, the world is never as simple as having single causes for occurrences. There are always multiple contributing factors to a failure, and root cause analysis (or its close relative, 5 Whys) simply doesn’t take that fact into account.

A software application is a complex system, with its code being only one part. The humans who interact with it play a hugely important role, as do their incentives, the information available to them, their stress, and much more.

Taking a more holistic view of the components – both technical and human – that interact to create situations is a more effective technique. Systems Thinking is a discipline that emerged from decades of analysis of how people and things interact, and it is much more valuable for determining causal factors leading to failures. The aviation industry long ago adopted approaches related to Systems Thinking, human factors, and safety science, to its immense benefit.

An outcome of a root cause analysis might be, “The database was deleted because of human error: an on-call engineer typed the wrong command.” Such a reductionist approach of looking for a single cause has led to a reduction in learning, and a blame-filled result. It might also lead to the disciplining of that employee. A more complete analysis would determine why such a powerful command was available, or how that command was runnable without anyone else’s involvement, or what other things the staff were working on at the time, or how tired they were. Only after building a complete view of the whole system – where “system” refers to the combination of humans and software and anything else with influence – can the underlying problems truly be understood.

Terms are important in our industry, and sometimes what starts out as being helpful can progressively become less useful, or even toxic. It is incumbent on all of us to periodically take a look at  the terms of our trade with fresh eyes, just as much as we address things like buggy code.

Further Reading:

• Sustainable Development
• Culture Fit vs. Culture Add: Why One Term Actually Hurts Diversity
• Thinking in Systems, A Primer
• The Problem with Root Cause Analysis

Photo by Aaron Burden on Unsplash.