We got this one wrong, us the IT people. We view process through a rather narrow prism, so much that we grew to value “Individuals and Interactions over Processes and Tools”. But process is way more than just a set of activities that get executed in a specific order.
Wikipedia alone has about 40 different disambiguation values when looking up “Process”. But the most concise definition is the following: “A process is a set of activities that interact to achieve a result”.
In many ways when we talk about a process we omit the latter part: “that interact to achieve a result”.
Start with basics
Take chemical processes, as an analogy. Say you want to make mayonnaise. You take an egg, oil, lemon, mustard, seasoning, and combine them in a very specific order. Should you change the order to activities, you might spoil the process, and get something, which might be tasty, but is ultimately not mayonnaise. That’s the set of activities involved in the process.
But the ingredients also interact to cause a certain set of chemical reactions. Without those interactions you will not have a mayonnaise, either. For example, if you used a boiled egg or a stale lemon, you are unlikely to achieve the desired result.
What more, if you get the ingredients and do -nothing-, other unplanned (and undesired) additional chemical processes will interact and prevent you from using those same ingredients for your desired gourmet mayonnaise. Your egg will go off, your lemon will become moldy, well, you get the point.
Content vs. Process
In the mayonnaise example, should you take a 3 months old egg, boiling oil, stale lemon and dried-up mustard, you are very unlikely to get any mayonnaise in the process. Most likely what you’ll get is hospitalized (if you’re lucky). The content was right. The set of activities was right. The conditions were wrong, hence the interactions were wrong too.
Time to bring this back to something resembling software.
Take 3 months old requirements, a group of demotivated individuals, a broken CI system and an angry customer, you are very unlikely to get high quality software in a few short iterations. No matter how good you’ve defined the set of activities to follow. No matter how successful other teams were with a similar set. The conditions are unsuitable, and hence, the interactions won’t yield the expected, or even a predictable, result.
Content – these are the “ingredients” to generate outcomes. In a software organization these are: feature requests (aka backlog), definition of done, strategy and so on.
The quality of the content in itself is a result of a process – activities and interactions.
Healthy interactions with the customer lead to better feature requests.
Intentional interactions with the PO lead to better Definition of Done.
Frequent, intentional interactions between customer, leadership and teams lead to well communicated strategy.
You get the picture.
What you don’t see
“It ain’t what you know that gets you in trouble. It’s what you know for sure that just ain’t so”. Mark Twain.
Content theories are not unfamiliar in the human, interpersonal domain, too.
Take, for example, Theory X, Theory Y. According to Theory X, people always want to avoid effort, and do as little as needed. It is the responsibility of managers to make sure that employees do their work, otherwise, they will prefer to be lazy. According to theory Y, on the other hand, people are internally motivated, enjoy their work, and are the most valuable asset of the company. Manager’s role is to make sure that employees don’t lose their motivation, and to foster the conditions to enhance it.
Of course, both theories are wrong, according to the process view. Both Y people and X people are a result of a process – activities and interactions, that take place, whether intentionally or not. Creating ‘bad’ conditions for motivation (result of process) “generates” X people, whereas fostering ‘good’ conditions for motivation (also result of process) “generates” Y people. Same people, different conditions yielding different “content”.
You may be convinced that person X is lazy, and person Y is god’s gift to companies. When in fact, the behavior of both is a result of processes – some are visible, most are not.
Let’s look deeper into processes.
We tend to look at process as mechanical, reproducible, predictable. Much like a computer process, or program. But most of the important processes are different – interpersonal, intergroup, complex, context sensitive. Most of all, invisible.
Here’s an example (based on a true incident):
A team member, Oscar, was fired, due to his low performance. He was not taking initiative, not eager to pull tasks of work, not contributing to the team’s success. While he was not sabotaging the team’s work, he was also merely reactive at best of times.
Few weeks later the team was recruiting a new teammate. The Scrum Master, Sam, turned to me, and he was puzzled: he proposed that the teammates will interview the new recruit. But none of the other team members wanted to help. This was their opportunity to shape their own future, but no one was willing to help make that happen.
During our conversation I asked Sam: What might you have “fired” from the team when you fired Oscar? What was in his personality that didn’t fit the team?
It was Sam’s turn to suprise me with his answer: Turns out that Oscar regularly plays Soccer in his free time, and he’s quite good at it too. Not only that, he is a keen caver, so he’s into extreme and team sports. How come Oscar, of all teammates, was the one to get fired because he was a low performer?
Here’s a clearly X person – just waiting for the opportunity not to do anything in or for the team, while leading a very active, motivating, Y-person-style personal life outside work.
Next Sam and I discussed what could lead people to lose motivation: cycles of layoffs towards annual reports, lack of clear goals for the product, an absent-present product manager, and numerous others. All are either organizational processes, or outcomes of yet other processes.
So our work turned to nurturing the team’s environment, rather than jumping to get the team to hire a new teammate themselves.
We like to put processes on a flow-chart, or on a value-stream map, hoping that this will reveal what we need to do and be able to replicate it.
However, just like an iceberg, what we see surfacing is the 10% that surfaces above the water. And the most important things are hidden from the eye, in the 90% of the metaphoric iceberg that is submerged beneath water level.
Understanding what’s below the water level
In order to reveal the content and process that operates below the water level, we need to act. We perform a set of activities, that interact with the “iceberg” that is our context (our workplace, a project, a product, choose your relevant context/s), and yields a result.
Sometimes the result will be desirable, and we can continue that activity so long as it’s effective.
Some other times the result will be undesirable, and we can either retry using an improved activity, or pivot and try something completely different.
And then repeat.
That, of course, is a process. It is also the premise of working within complex-adaptive-systems.
Which means that both process and content are the outcomes of more process. Hence process is always more important than content.
OK, So what?!
Good question. Maybe, after all, this blogpost has no merit. Maybe this is so obvious that everyone understands and acts according to these principles. Alternatively, maybe these “interactions” and “results” part of process is so overlooked, that we tend to forget it all too frequently.
So next time you come up with a feature development process, or a hiring procedure; or come up with the backlog for the next release, or with the agenda for your meeting – look for the 90% of the process that lurks beneath the water level.
For further reading on complex adaptive systems, try one of the following:
Or contact us for more specific reference or concrete advice