What is “People Over Process”?

The “people over process” concept means that a team or department forms processes based on the workers, rather than forcing the workers to accommodate a pre-designed process. It is based on the first value of the Agile Manifesto:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Since many objections to Agile or Scrum are process related, this concept is fundamental to a successful team. It is also a large stumbling block for new Product Owners and Scrum Masters. For the sake of brevity, I am going to refer to the person responsible for implementing processes and procedures as the Scrum Master, but the actual title of the person does not matter.

How to value people over process

Remember that you already trust your teammates to create and maintain processes without questioning their methods. Every day each of us has to get to their office, perform work, take care of their family, obtain food, etc. In addition, most people have led or otherwise been a critical member of a team at some point in their career.

What not to do

The opposite of “people over process” is “process over people.” If you say the following things, you may be valuing process over people:

• “That isn’t Scrum” / “That isn’t Agile” (so we shouldn’t or can’t do it)
• “We have to follow the process”
• “Just trust me”
• “You have to do it because I am your manager/superior”
• “I am the Scrum Master so I make the decisions about the team’s processes”

Team members can also contribute to a “process over people” mentality. The team members may have spent years, in some cases decades, learning to adjust their work to the processes and tools they are given. Another problem that can occur is that even if the Scum Master tries to let the team make their own processes, the team may not agree on a set of processes because of different work habits, different backgrounds, etc.

When someone declares that they should follow a process even though the team does not agree with it, they are unintentionally indicating the following:

• The pre-designed process is more important than the team.
• The team’s opinions, knowledge and experience are not valuable or worthwhile.
• The team is incapable of self organizing.
• Neither feedback nor innovation is welcome.

This can lead team members to feel like they are forced to do Scrum, and everyone knows what happens when you try to force anyone to do something: cooperation breaks down, productivity diminishes, and workers leave.

How to Introduce a Pre-designed Process

Rules are always created inside of a context, and that context isn’t always kept as part of the rule. Since processes are a set of rules, processes are also designed inside of a context. So when you discuss a pre-designed process with a team, you should be able to answer the following and explain the answers to the team:

• Where did the process come from and why was it created?
• Am I basing the process on another team’s experiences?
• Why do I want to implement the process for this team?
• What would happen if we do something different?

The following are example scenarios, using complaints and issues I have seen in real Scrum teams. The purpose of these examples is to help make the path from “process over people” to “people over process” clearer and perhaps most importantly, attainable.

Example: “I hate the ________ meeting!”

The traditional Scrum process involves several specific meetings. If a team member or the whole team disagrees with a pre-designed meeting, they may have a valid reason for disagreeing with it. Instead of dismissing their complaints and insisting they do it “because it is Scrum,” try asking them questions to identify the other paths forward.

If the team feels like the meeting is redundant or unnecessary, try the following:

• Identify other ways they communicate the same information
• Go through the questions listed above both by yourself and with your team. Examine the questions and their answers honestly and make certain that each team member is able to share their thoughts.
• Identify circumstances where communication failure has caused problems. Do this on an individual level.

If they are still adamant that they do not want to do the meeting, and you are adamant that they should, try a trial period with the new meeting, and plan to (this is important!) return to the previous meeting schedule after the trial period is over.

After the trial period is over, arrange a short meeting to discuss how it went. The purpose of the trial period is not to prove that you are right, but rather to allow them to self organize, to learn, and possibly even prove you wrong. Not only will this allow them to see whether they like the new meeting, but it will also allow them to adjust it or maybe take parts of it and skip others. For example, maybe they really liked the new meeting – but think it should be every 4 weeks instead of every 2.

In summary, if you work with your team to create processes, you will be far more successful than if you force pre-designed processes on them.