How do the following words make you feel?
“Management has decided that we need to introduce additional process to keep up with the operational demands of our growing business.”
Setting aside the whole “management has decided” part, let’s talk about process. Depending upon your experiences, you may have some immediate–and possibly strong–reactions to the mention of adding process. I get it.
However, I think most of us would agree that categorically labeling process as “good” or “bad” is an unhelpful oversimplification. Instead, we can think of process like an algorithm–it’s just describing a way of doing a thing. Is that specific way good or bad? Well, that largely depends on the details. How is it implemented? Does it solve the problem at hand?
Here are three scenarios that provide one mental model to think about process.
Parable one
Imagine someone sitting down to tackle a puzzle. What’s the first move? After dumping the pieces on the table, they take the time to flip each piece face up.
Why do they follow this process? Because it’s fun? Maybe–people like different things. But most likely it’s because it makes sense. They know that it helps them reach their goal of solving the puzzle.
The best software engineering processes should be like that–whether you find the activity inspiring or not–the results are beneficial. They support people by guiding them to the desired outcomes.
Parable two
Next, picture some friends setting up a poker game. Before shuffling, the dealer flips through the cards to make sure they are all face down.
Why? It’s just how the game works. As illustrated in the photo above, it doesn’t matter how good your hand is, if you insist on playing faces out.
Some software engineering processes are like that too. For example, if you want to play the SOC 2 Type 2 compliance game, you’re going to need a change management control. House rules. Auditor wins.
With that said, when picking a process to meet such requirements–and multiple options often exist–let the principle found in Parable One guide you.
Parable three
Here’s the last one. Someone pulls out a set of tarot cards. The cards are revealed, face up.
Why is this process followed? Some believe it unveils secrets about the future. However, this one’s a bit more up for debate, right?
And so I ask, Does the logic-driven world of software engineering have parallels with the mystical? Before you answer, consider: Have you ever seen story points cast to foretell a future delivery date? Likely so.
And what of the outcomes? When it flops, the people–not the process–are often faulted. On the other hand, when an estimate is accurate, some might justifiably wonder whether that is little more than coincidence.
Now, I’m not saying empirical approaches to estimation don’t exist. But I am encouraging readers to question whether that describes the approach they use.
And sometimes processes that start out following the principles of Parable One drift towards Parable Three. The once informed actions, repeated over time, can become empty recitations serving an unknown purpose to appease a long forgotten problem.
And your point is?
Processes are like tools in a toolbox. Pick the right one for the job. And keep your eyes open to recognize when the game changes. Don’t keep shuffling for poker when the cards get swapped out with a puzzle.