When developing code, most of us would rather spend time writing code or talking to users to understand their problems than to spend time on process. Process does not need to be a dirty word, although most developers would disagree.
Processes Suck
Most processes imposed from outside the team suck. Partially, that is due to the belief by those doing the imposing that they know better than the people actually doing the work what the correct process should be. Any process that does not take into account the actual team and work they are doing will not be particularly effective. Adding more to a bad process, necessarily makes it worse.
Many processes adopted inside the team suck. This is often because the people developing the process have not really thought hard about what they need to be doing versus what they think they should be doing.
Processes are Vital
If a team intends to be productive, they will need some level of process. A really good team uses the minimum amount of process needed to be effective. Any new process that is considered for addition must either make the team more effective in a measurable way, or remove an impediment that is slowing the team down.
Good processes for deciding how to handle deciding on tasks, testing, code review, version control, design discussions, pairing/mobbing and so on can be quite helpful. Having the team agree on approaches to these fundamentals reduces arguments or people working at cross purposes. The key point here is having the team agree.
Moreover, people aren’t usually very good at setting up a useful process. So even if the team agrees on a process, they should be prepared to adjust if the process isn’t working.
Good Process Won’t Fix A Bad Developer
Many of the times that process is imposed from the outside, the goal is to fix a bad developer or team. If someone is not working with the team (or the team is not working with the company), no amount of process will change that. Sometimes peer pressure within a team can mitigate bad effects, but the bad actor(s) will need to be willing to make an effort.
If someone refuses to follow a process that the rest of the team has agreed to, they will probably be a net negative for productivity and should be moved to a different role (or moved on).
Bad Process Can Chase Off A Good Developer
Although good developers can be effective with multiple kinds of process, a really bad process can cause good developers to leave. If this bad process continues for long enough, the company can end up chasing off all of the effective, experienced developers. This might leave you with only the people who will put up with anything or the desperate that cannot leave for some reason.
Formal vs Informal Process
I can’t remember where I first heard it, but I have seen this aphorism proven again and again: “The formal process should not prevent the informal process from working.”
As a general rule, it seems that most work is accomplished through an informal understanding of how the team works. Most conflicts are handled by quick conversations. Lots of education happens in a similar ad hoc fashion. Design happens through experimentation and white board sessions, unless it involves large architectural concerns or interfaces with other teams/companies.
This process works despite having little process to define it. In fact, it usually works well enough that no one notices that there isn’t a defined formal process.
Formal process helps when things get hairy.
- Who resolves an impediment caused by someone outside the team?
- How do we resource design problems when the team doesn’t quickly settle to a single approach?
- What do we do if a developer and a reviewer reach an impasse on how a piece of design should be implemented?
- What are the criteria that decides if a critical fix is needed outside of the normal process?
Having the team define explicit processes for resolving issues like this makes working with opinionated and knowledgeable people possible. Defining the easy stuff too strictly however prevents your team from working, instead of checking off a list of rules.
The Bottom Line
Process is both a hindrance and critical to the functioning of any team. The process must be well-defined and solid enough to give structure when the team needs it. It must also be flexible and able to change when necessarily to enable the team to succeed.