Culture of Processes

I work in agile environments for close to the entirety of my professional career. So you say I am lucky. However, I never felt the environment agile for plenty of reasons. I’m quite sure that I will elaborate on them in other posts, but for now, I would rather concentrate on one aspect only.

To what extent do processes drive the working environment? How much is the working culture based on processes?

But before I would get lost in my monologue, let’s define the meaning of the word “culture”. It’s an umbrella term for social behaviours, norms, habits, actions you expect to carry out, and how individuals in the enclosing group do things. The culture can vary between the groups and of course, such a group can be and actually is a company too. Each company has its own culture driving how people work there. What do these folks consider for “this is who we are, this is how we get things done”.

The Agile Manifesto without any hesitation states in the first line that we value “Individuals and interaction over processes and tools”. Then how is it possible that companies declaring themselves agile are full of processes? Where are the individuals and the interactions between them?

I fully understand that processes are the key to success in certain professions and industries. Let’s take a pharmaceutical company as an example. There is no need for any degree of freedom. You need strict policies and processes to ensure the same quality of medications produced over time. But software engineering is not like that. It’s more like a discovery.

The waterfall approach is (almost) constantly failing, not without reason. The more complex and the bigger the software to be developed, the more uncertainty and complications it has. In such situations, the company forced processes are counterproductive. They do not guarantee any quality or other attributes to be met and are typically the first thing the development team tries to bypass if possible. Let me give an example.

The company enforces that developers shall not push code changes to the main branch. Instead, you should use pull requests and code reviews. However, the policy does not distinguish situations when only a tiny typo is to be corrected, or the application is so small that one developer develops it.

Now here is the million-dollar question. Do you do a comprehensive and meaningful code review because someone puts a gun to your head or when you believe this is the right way to do it? Also, typically such processes are enforced by non-technical persons in the organizations. In better cases, they were developers long ago but not practicing anymore and represent decades-old mindsets about our fast-changing profession. They are also not responsible and accountable for the impact on the ongoing development activities. Both the responsibility and accountability stay with the development team.

Sticking to the code review example, sound professional software engineers do code reviews because of their previous experiences and lessons learned. Because they know that it ensures higher quality and increased return for the business on their investment. It is so fundamental that they do not even think about skipping it for significant changes. It is just not an option for them. But they would also not bother each other with a minor typo correction on the contrary case. Instead, they do what makes sense and skip what does not.

As a solution, I truly believe in the culture of professionalism on the flip side. If the organization embraces those development teams who follow good practices, constantly develop a good engineering atmosphere, and remove the non-fitting staff, the results can be astonishing. Eventually, it takes years of constant investment, including hiring the right staff, community-building efforts, recognition, knowledge-sharing forums, support of learning, etc. As the years pass, slowly but steadily, you will have incomparably better software products. Not because of the gun at the developers’ heads but because they want to build it that way. They enjoy what they do. It fulfills them and makes them proud, which in the end, as a side effect, gives the desired better software products.