Process – AgileEvangelist

Many agile coaches are strongly allergic to the term “process” when applied to Scrum, and you should be very careful not to refer to Scrum as a “process” in their presence.

But is Scrum a process or not?

The Scrum Guide refers to Scrum as a “process framework”, which I assume is meant to imply that a process can be built upon and within this framework but that Scrum itself is not a process. The Scrum Guide then goes on to refer to the “Scrum process” or “the process” several times. So I believe that this invalidates the strict “Scrum is not a process” rule already.

I believe that many people hate the word “process”, because it is a word that is heavily used in a waterfall context, where every little step of the development path from first product vision to final product delivery is described in painstaking detail. Practically every action that needs to be taken before, during and after each milestone is clearly described in process descriptions, and huge amounts of documentation are generated to satisfy these process descriptions. Obviously, Scrum does not do this, so Scrum is not a process in this classical sense. I think this has lead Jeff Sutherland and Ken Schwaber to call Scrum a “framework” rather than a “process” – because Scrum is hardly as prescriptive as typical waterfall processes. The prescriptive content of the Scrum Guide is 16 pages long. I have seen process descriptions where the table of abbreviations already took up more than 16 pages.

So no, Scrum is not a process in this old highly prescriptive command-and-control sense of the word.

But nevertheless, Scrum is a process. A “process” in its dictionary definition is simply a series of actions. Scrum clearly is a series of actions. You start with a Sprint Planning. Then you hold Daily Scrums during the Sprint. At the end of the Sprint, you have a Sprint Review, and then you conclude with a Retrospective before starting again with another Sprint Planning. This is clearly a series of actions, i.e. a process.

I believe that is where for many people the confusion comes from and why both sides of the argument have a point. Perhaps it is simply a “Know your audience” kind of situation. When speaking to a project manager who spent the last 20 years managing waterfall projects, it might be a mistake to refer to Scrum as a “process”. But I trust a Scrum Master to know what they are talking about when they call Scrum a “process” and that there is no problem with the Scrum Guide referring to the “Scrum Process”.

When people speak about diversity in the workplace, they usually refer to building teams from people of diverse backgrounds. However, I would like to write about a different kind of diversity that can be highly beneficial: Having a diverse set of approaches for how to organize the work within an organization – or to use a shorter term: process diversity.

To illustrate the meaning of this term, I would like to describe two different fictional companies going through an agile transition:

Company A took a very structured approach to their agile transition. They spent several months thinking about how to organize the teams, how to distribute the work, how the teams should interact with each other and with the various stakeholders. Their project handbook clearly describes how teams are expected to conduct their Scrum ceremonies and what kind of output is desired from them. It also contains a template for a task board that the teams should use and explains how to use the chosen software tool to make the task board available in digital form.

Company B did not care quite that much about coming up with such a detailed process description. There is great variation between how the teams organize their work in Company B. Some use Scrum, while some use Kanban. The task boards in each team look completely different. Some teams use burndown charts, others use burnup charts, while others use neither. Some decided to transfer their task board 1:1 into the software tool, while others track only the higher-level user stories there. Some teams do their dailies in the usual “Everyone answers three questions” fashion. Other teams decided to use other less presciptive formats. One team decided that they want their Product Owner to take an active role in their daily, but other teams have clearly decided against that.

So which approach do I prefer? Personally, I strongly lean towards Company B’s approach.

I like to explain my reasoning by pointing to biological evolution. The only way how species could develop new useful traits is through a diverse gene pool which is caused by mutations. If all members of a species were identical, there would not be any kind of evolution, and the whole species would either succeed in its given environment, or the whole species would fail.

I believe it is the same for companies. Evolution of positive ideas, practices and frameworks is more likely to come from a diverse process landscape. For example if every team structures their task board differently, then the teams can learn from each other, adapt good ideas from other teams and avoid making the same mistakes as other teams. I strongly feel that Company B will have huge advantages over Company A in the long run, even if the differences between the teams might lead to problems every now and then.

Obviously, wanting to benefit from process diversity implies that teams are willing to learn from each other, and you will have phases where teams converge towards common approaches. But the teams should always be encouraged to diverge again by running various experiments to enable another round of process diversity followed by collective learning and process convergence.

Tag: Process

Is Scrum a Process?

Process Diversity