If you’ve ever worked on a large software development project, chances are you’ve heard developers say “people over process.” People over process comes from the first value of the Agile Manifesto, “Individuals and interactions” over “processes and tools.” It is the most quoted and most memorable value from Agile. It also clarifies what we as developers value: process is important but people come first.
When developers claim that a project doesn’t value people over process, it is akin to a car making a loud noise. You might be able to guess what the cause is, but oftentimes you’ll need to take a look under the hood. Developers and project leaders need to ask questions about the project and processes to uncover what’s actually causing them to feel this way.
What things could be going wrong? We’ll discuss some reasons why developers may think a project doesn’t value people over process:
- There aren’t blocks of time to sit down and develop.
- They don’t feel ownership of the process.
- Too many meetings are scheduled throughout the workweek.
Development Time
When we look at a 40-hour workweek, developers want uninterrupted time to actually do their work. Ideally, a five to six-hour block of time where a developer can just sit down and complete the assigned work.
Imagine working for one hour, breaking for a meeting, and then trying to get into the same workflow you started earlier. Before you know it, another two-hour meeting breaks up the day even further. With so many meetings, developers struggle to get back into that concentration zone to get things done. They often feel like they don’t have enough time to do their work the way they want to.
Process Ownership
As a project leader, you want to find out why your developers are saying people over process. You’re trying to find out what’s wrong with the process. Sometimes, it’s because developers feel like they don’t own their process – instead, the process is mandated. One of the values of Agile is being able to reflect and iterate to improve your process.
A team of DevOps engineers will have high-priority tasks constantly arriving in their backlog. They may not have the luxury of thinking two weeks in advance – they might be thinking two hours in advance. Kanban will work really well to help this type of team continuously prioritize the backlog, visualize the workflow, and limit work-in-progress to keep things moving to completion.
A fullstack development team might want to use Scrum to have a two-week uninterrupted window of time to focus and complete the work without any priority changes.
Sitting down and identifying the process that works best for the team is essential for developers or anyone working on a software project. If the process is being dictated to them, they will feel like they don’t have any control over the process. So they start feeling like they have to be part of the process first. People should have some ownership over the process that they’re using.
Meeting Overload
Returning to the 40-hour workweek, what does a developer’s schedule look like? Scrum is prescriptive but it’s lightweight. Between daily standups, sprint planning, and retrospective meetings, it only takes about three to four hours a week for the process. That’s about 10% of a developer’s workweek. Scrum isn’t the most lightweight thing, but it’s a minimum set of activities to keep the development process running smoothly. A lot of people have implemented it and do it well.
Now let’s say we have multiple teams that are scattered throughout different parts of the world and we want to coordinate these teams. With Scrum, at its base, 10% of a developer’s time is already invested in meetings. When extra meetings are added for planning multiple sprints in advance or looking at dependencies between teams, you can figure it will take up another 10%. So now we’re at 20% just for the development process.
Since we all work in companies, meetings for company updates or town halls are often scheduled which can easily bring another 10-20%. You can see that it’s easy to get to a point where 50% of a developer’s time is already taken up by the process, company, organization, and department-level meetings.
Before a developer can even sit down to do their work, half of their time is already allocated to meetings. Now when they go to do the work they might have to meet with product owners, business analysts, architects, user experience, quality assurance, or other development teams to discuss the details of the problem they are solving.
People First, Process Second
Often when people are first introduced to Agile, the values imply that processes are bad. It’s easy to get the impression that people are most important and teams should have as little process as possible (read our People or Process Thought Experiment). That’s not the case.
When the Agile Manifesto was written, the process was obviously important. But when it comes to a conflict between people and process, people have to be trusted. It’s important to find good people, trust them to do a good job, and trust that they have the right intentions. So when we talk about people over process, people come first and process comes second. But that doesn’t mean processes aren’t important.
Finding Balance
When we implement Agile processes we’re looking at protecting people: giving them ownership, protecting their time, and making sure they’re not interrupted. They have a process that gives them control over the work they’re doing and they’re able to complete it without interruption. This is what balance looks like.
When developers say people over process, there’s something breaking that balance. Either they don’t have the time, they don’t have the ownership, or the process is not working for them. Maybe there aren’t a lot of meetings, but those few meetings are scheduled in a way where they don’t have big blocks of time to sit down and work.
Pinpointing the Problem
When people say people over process, there’s something interrupting that balance: they don’t have the time; they don’t have the ownership; the process is not working for them; it’s too heavy. At the project leadership level, you need to figure out what’s actually interrupting them. Developers, too, should feel empowered to uncover what is not working in their process and address it at the team level first. Getting down to the actual details of why they feel the process is not working and addressing those issues will bring balance back to the team.
