Process

No process is a process too. A bad one.

As process is a generic word, here is my definition:

A process is a set of correlated procedures that aim to solve a specific problem. Each procedure involves the work of one or more people.

This description fits most things we do at work everyday and, yet, we often ignore process design. The challenge is that building a process for solving a problem isn't as appealing as solving the problem itself.

For example, take bug fixing. Write a test to expose a bug, then fix the bug, and finally ship the fix to production -- this sequence has an immediate impact on the system. It's an exciting and fun activity. On the other hand, designing the process to report bugs and triage them doesn't sound as interesting. So what happens in practise is that most teams end up with a bug triage process they did not design. Which, in turn, means that they don't agree with some parts of the process. It's no surprise that they don't like working with it. Because no one chose it, the results are rarely good.

Processes are designed to solve a problem. One way to make them more appealing for your teams is to shift people's attention from the processes themselves to the problem they aim to solve.

If you make your team members part of the problem-solving activity, designing processes also becomes more inclusive. You get fresh ideas from the actual users of these processes. You increase your chances of designing more usable and enjoyable processes.

In this chapter, I focus on the processes that I believe have the biggest impact on the productivity and happiness of a team. Often productivity and happiness go together, but it's possible to run productive teams that are unhappy and inefficient teams that are happy. Teams that don't possess both properties tend to break after a few months. Well-designed processes help minimise the risk.