individuals and interactions over processes and tools;

Good processes and tools support teams. Bad ones destroy them.

Individuals are good, but if you look at the world through a post-meritocracy lens, you understand that individuals aren’t the primary driver of success. Everyone needs to work well and drive the project forward, but everyone also needs to work to move the team forward.

There are plenty of Theory of Constraints examples where individual progress can be at the expense of team progress, because they use their own code style, or they don’t have time to document or coach, or when there’s a queue for testing, and the rockstar developer is too precious to do QA and unblock the release.

Good processes help the team work together. They provide guidelines for the team, like a code of conduct, a standard operating procedure or a definition of done. They describe how things are done here so everyone has a shared expectation and a shared goal. That’s how agile teams become more effective.

Processes serve the people and the interactions, not the other way round, and should be open to extension or modification when they no longer serve them.

Good processes help individuals fall into the pit of success, whether documented or automated. Static code analysis helps every reader and avoids those subtle mistakes. Conventional commits help whoever is tracking down a production issue at 3am.

We don’t want heavyweight processes. We want them small, adjustable and easy to follow. But we want processes that support everyone on the team. Make all meetings online in a hybrid team. Have a set of standard criteria and questions for interviewing potential new team members. Reduce the bus factor with documentation processes so team members can have medical treatment, or visit family abroad for an extended break, or support extended adoption leave for new parents.

Don’t let an individual bend the team. Let the team embrace the individuals. And build whatever minimum process keeps those individuals supported.