Scrum is not your process

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.

Background

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.

Your process may be something more like that shown here:Typical 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.

In conclusion

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.

 

Getting started

I’ve been learning about Agile, and employing its principles and practices, for a while now.

I was introduced to some of the tenets of eXtreme Programming (XP) in 2000 by a co-worker at a software development company. I liked what I saw, but didn’t get a chance to apply it much at the time. My next opportunity came in 2005, when I got involved in another software development effort that started out in the traditional “waterfall” fashion with a good-sized design document, but changed over to an Agile approach because we all knew that the requirements for the product being built were going to be changing constantly.

My personal discovery of Agile principles and practices renewed my interest in software development (in which I had been involved since 1977). Agile held a promise that I could actually be part of creating some fairly large software systems without them becoming inflexible and unmanageable with growth.

As I learned more, I began to realize something that many others almost certainly know: This Agile stuff has much broader application than just in the world of software. So I adopted a broader viewpoint, and began thinking in terms applying Agile principles and practices to productivity in general.

I’m a big fan of Eliyahu Goldratt’s Theory of Constraints, and find myself reading and re-reading his body of work. I like Goldratt’s clear and concise definition of productivity, and use it myself in practically everything I do work-wise.

Eventually I began training and coaching other people in Agile principles and practices, and developing hands-on exercises that help get the basic ideas across. I’m still doing that today, and intend to keep on doing it, hoping to reach larger and larger audiences.

I’m also hoping that this blog will serve to promote the exchange of ideas between myself an other enthusiasts out there. Please feel free to join the conversation.