To gain an understanding of what something is, it is often helpful to understand what it is not. This article outlines one of the important things that Scrum is not.
When training and coaching Agile practitioners, I often hear them use designations such as “the Scrum process” or “the Agile process” (by which they usually mean Scrum). Sometimes these are simply instances of using words casually, but in other cases it has turned out that what something is called substantially affects how it is thought about and used.
In my earlier training sessions, it seems that I met with quite a lot of resistance to the adoption of Scrum. After some digging I found that the primary source of such resistance was a general feeling that someone (typically management) intended to replace everyone’s existing work process with this new thing called Scrum, something of which they were (understandably) wary.
But once I made a regular practice of explaining that Scrum was not a replacement for their process, but instead a framework for inspecting and adapting that process, things tended to go more smoothly and the resistance pretty much went away.
You already have a process
You already have a process in place where you work. It may or may not be clearly defined. It may or may not be well understood. But, regardless of the work you do, you already have a process by which you turn some kind of input into some kind of output. Understanding your current process is important if you intend to make improvements to it.
Scrum is not your process
Let me repeat that: Scrum is not your process. That’s not to say, however, that Scrum is not a process. It certainly looks like a process in that it has well-defined steps which are performed in a specific order (i.e. Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective). If you must think of Scrum as a process, then you might consider it a meta-process, in that it is a process which informs you about the state of another (your) process.
As parts of a simple work process, these activities would need to be performed whether or not you use Scrum. Scrum can help you determine what things about that process might need to change (e.g. batch size, amount of work simultaneously in process, time between releases, etc.). Even so, Scrum isn’t intended to replace your process, but to augment it.
The founders of Scrum, as well as the current Scrum Guide, refer to it as a framework. I like that description, as it brings to mind some kind of skeletal structure or scaffolding that can be erected alongside your existing process in order to provide a vantage point from which to observe (inspect) the process and to change (adapt) it.
As frameworks go, I consider Scrum to be minimally intrusive. If you start practicing Scrum all at once, you will necessarily change some things related to your process (e.g. frequency of product releases, timing of meetings). In those cases, Scrum is not entirely hands-off as relates to your existing process.
I can easily imagine, however, a situation in which Scrum practices are brought online one at a time, in order to minimize disruption and make for a smoother transition. A team could, for example, start by adding Daily Scrums to their regular activities in order to begin inspecting and adapting work progress. Once that became routine, a team might add regular Sprint Retrospectives in order to begin inspecting and adapting the work process. And so on.
Organizations considering a transition to Scrum, and in particular those meeting with substantial resistance to such a change, may find that things go more smoothly if everyone involved understands that Scrum does not supplant any existing processes, but instead provides a point from which to view those processes in order to more easily improve them.