Good Process, Bad Process
“Process” is a word that seems to have a lot of baggage. Depending on whom you ask, process is either essential to delivering value, or something that gets in the way.
This is the wrong way to frame the issue.
What you really want to explore is whether the process is suitable for you. If the steps in the process don’t help you move faster, that process may not be for you. But having no process at all will definitely slow you down.
Two perspectives from startups illustrate the difference in how people react to the idea of process. In one case, a medium-size company asserted that they were too small for a process. Another smaller, early-stage startup expressed an interest in having a process so that the founders could focus on identifying needs and the team could build things more effectively, accelerating the time from idea to product delivery.
Is the difference in their definitions of process, or the perceived value?
From a definition perspective, at its most basic, a process is how a team decides what to do and how to do it. Every team has a process, but it may be more or less defined, more or less invasive, and more or less adaptable.
The steps in the process can constrain some decisions, allowing the team to focus on the work that adds the most value. Scrum can often be a good first step when there isn’t any sort of process definition.
Part of the reluctance to talk about process might relate to survival rules that are no longer valid. A bad experience with the wrong process may lead people to assume that a group can “just collaborate and get stuff done.” But that has limits.
As Jerry Weinberg wrote in Quality Software Management, Volume 2, we often need to rethink what lessons to take away from such an experience:
"Survival rules are not stupid; they are simply over-generalizations of rules we once needed for survival. We don’t want to simply throw them away. Survival rules can be transformed into less powerful forms, so that we can still use their wisdom without becoming incongruent."
Many of the common concerns about applying processes such as Scrum are often these kinds of over-generalizations.
For example, the criticism that a process doesn’t let you plan far in advance may be expressing concerns that things will change. In practice, having a plan helps people move independently and frees managers from micromanaging work. And when a plan changes, you change the plan.
Similarly, people may say the process slows us down, and, in the case of Scrum, there are too many meetings. This is certainly possible, and if it is, the process needs to change. But with Scrum, the goal of the meetings is to increase flow and reduce interruptions. By focusing too narrowly on an issue and working from perception rather than data, an aversion to process in the name of speed can actually slow you down.
Having a process doesn’t need to mean getting less done or being inflexible. A process is a way to increase communication, visibility, and transparency and speed up the team.
