Culture Before Process
June 27, 2024
Engineers love to talk about process.
Whether the process concerns running a team, development methodology, or even deployments, we are always talking about the “right process.” And it makes sense. A process is pretty similar to an algorithm, and writing algorithms in the form of computer code is what many of us do all day.
Some engineers hate processes, while others seek to find the best process possible. Debates between Agile gurus about what Agile is seem endless, let alone which form of Agile is best.
Engineers will also blame the process (especially a development process) when a project or product starts to go awry. Many engineers can sadly relate to late or chaotic projects due to a lack of process. “We never got clear requirements,” “Requirements changed without us knowing,” or “The deadline was set before we gave estimates!” are common protests for when a project is late or rife with bugs. Some engineers will comment on priority, claiming it wasn’t clear what work was more important within their team and a better process for prioritization is needed.
When projects like this finish (if they ever do), retrospectives often follow. These retros are often tense as the development team often feels this is the only forum to voice their frustrations, while product owners may feel they might need to justify why they made certain decisions.
Inevitably, the meeting will produce a list of action items relating to “improving the process” to avoid the same chaos in the future. Teams might suggest trying a new method, such as Scrum or Kanban, while other teams might want to double down on the axioms of their existing process. Some teams might suggest more meetings while others might desire less, feeling that the team spends too much time in meetings to get work done.
In any of these cases, scrutinizing the process is right and good.
But I think it’s putting the cart before the horse.
The Process is Rarely the Problem
In my experience, the process itself is rarely the problem. After having worked for a decade in the industry across small teams, large teams, cross-functional teams, etc., and across a few different companies, I can tell you each process has its failure points and shortcomings. Whether it’s the delivery methodology (Agile), the company’s product requirements gathering process (or lack of it), or even the process of assigning work, they all will eventually hit some form of issue.
For example, I’ve seen Scrum teams spend hours (literally) debating how to break up a story so it fits within the next sprint. The team knew their capacity couldn’t accommodate the entire story, so they were stuck taking on either less or too much work. While I’m a fan of increments and short development cycles, it seems odd to rework how a story or development task is defined to fit neatly into an arbitrary time window.
I’ve also seen Kanban teams oblivious to their progress on a project. It can be easy to ignore all other work besides work in the “TODO” column. Small interrupts find their way into the TODO column, and since there are no formal backlog refinement or estimation meetings, teams don’t realize they’ve been off track for two or three weeks.
Product requirements are a good one, too. I’ve seen twenty-plus-page requirements documents (full of contradictions!) that someone spent a lot of effort on, only for them to be thrown out the window in a thirty-minute meeting. I’ve also seen a product requirements document that was less than a page long for an incredibly complex set of work that left too much ambiguity. Both documents came out of the same process, too.
Inspecting the Process Misses the Point
Often, when things go wrong, people start looking for a solution. And to find a solution, you need to find the problem. The problem with “problem hunting” is that you will likely find surface problems and not real issues. It’s like treating symptoms vs. finding the disease.
We must be careful to apply the appropriate lens of our inspection of “what went wrong” and not be too quick to prescribe the wrong medication. We must be patient and ask many questions to uncover what is happening.
Let’s say you have a team of engineers that delivered a feature late. It wasn’t late by much, but enough that it missed a promised deadline to customers. You do some inspection and realize there was a lot of rework during the development of a feature due to missing or changing requirements. You might immediately say, “We need a stronger process for requirements gathering.” But did you ask when and why those requirements changed? Is it because the product owner couldn’t make up their mind? Maybe.
Another situation, though, could be that the product owner realized they needed to change the requirements but had a hard time communicating them. Should they update the director first or the team building the feature? Do they need to write another document, or should they talk to the engineers directly? Process might help here a bit, but a culture of high transparency and collaboration would be more vital.
Additionally, what if there was rework because the team also had competing projects that touched the same codebase? It can be hard to understand how each project will interact until you finish one, which could cause rework. Following a perfect requirements-gathering process with a pristine document won’t matter much if there is a lack of focus and a culture of “throw it over the wall” between the team and product owners.
In each of these cases, a perfect process won’t fix the cultural problems beneath.
Culture Builds Process
You’ve likely heard the phrase ”culture eats strategy for breakfast” (or some form of it). The idea is that the right culture will find ways to overcome obstacles and solve problems much better than a grand strategy.
I think the relationship between culture and process is the same as between culture and strategy: no process will ever build a healthy culture, but a healthy culture will undoubtedly build the right process.
But we keep hoping that instituting a particular process or methodology will “fix” all of our development problems. We need to learn how to work well together by finding common ground, sharing knowledge with our team, helping each other as much as possible, and collaborating towards solutions (no matter how rough an idea might be).
When we make improving the culture our goal, we will discover the tools, meetings (or lack of them), and everything else we need to be successful. When we don’t, we add the wrong tools, create the wrong meetings, and get in our way.
By shifting from talking about process to talking about culture, we will inevitably find what works for the team. And since every team is different, every process will be different.
And that is the point: there is no silver bullet.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.