Previously we discussed reasons why developers might feel that their project is process-heavy. “People over process” is a common refrain when developers are not feeling valued in their projects. Let’s take a look at an (extreme) example of what happens when there’s no longer a balance between people and process.
Remove Process Completely
As a thought experiment, let’s remove the process completely. For this scenario, we have 100 developers on a project and there’s no process. First, you need to ask what are they working on? Do the developers get to decide what they’re working on? A director might ask a random developer what they’re working on. The developer tells them they’re upgrading the platform to the latest versions of a library and it will take two months to complete. At that point, the director should determine if there are tasks with higher priorities that the team should be executing in those two months that would deliver higher value to the customer.
In the same scenario, you may have a key developer who’s working on the project and 90 people have to ask them questions. That key developer may be working on something and all of a sudden they get interrupted. While helping on that task, another question comes through from a different developer. At that point, it turns into interruption inception. The key developer can never actually focus and complete their work because they are continuously getting interrupted.
This violates the Kanban concept known as work in progress. To achieve efficiency, you want to limit the work in progress. When a developer is interrupted a few times after starting a task, the work in progress is delayed.
When you look at this scenario of just people and no process, it’s obviously not going to work. Individuals can’t take complex requirements and break them down into priorities independently. If there are 100 developers who have their own perception of what the priorities are, there will be 100 different views of what should be worked on at any given time. So we need to create a process.
Remove People Completely
Now let’s go to the other side of the equation and not even care about people. Let’s say we figured out a golden process that allows us to place any developer into any role in the project and they’ll know exactly what to do. We establish a process that can get the most out of every developer and can deliver software at the lowest cost possible.
That’s obviously not going to work for a lot of people. There’s a lot of value to the individuals doing the knowledge work. It isn’t some factory that can be filled with unskilled labor. Software development is very skilled labor – it takes a lot of knowledge and experience to come up with and maintain complex abstractions and solve problems in the software world.
Finding a Balance between People and Process
At the extreme end of the process, people don’t matter and that doesn’t work. At the extreme end where people are the most important asset and the process doesn’t matter, that doesn’t work. So we have to find a balance between the two.
What does that balance of process and people actually achieve? And why is that balance? When that balance is disturbed, why do developers say, “we’re not valuing people over the process here”?
When we look at agile, what are the things we’re trying to achieve? We want to find a way for developers to deliver the most value and feel fulfilled in delivering value to the customer as efficiently as possible. We’re not trying to maximize the efficiency of the development process. Instead, we’re trying to give developers the freedom to do good work and deliver that work without interruptions.
Having a process helps us with a couple of things. It helps us figure out what the priorities are. It also helps us protect our developers from interruptions so they can complete the work they started. The process needs to protect developers from constant interruptions, prioritization, and micromanagement. And last but not least, we need to give them time.
