On one of the earliest Scrum projects I coached, a developer said something that has always stuck with me about all this Scrum and agile stuff. We were beginning to move beyond the original skunkworks project towards more of a company-wide integration and ran up against some roadblocks. Yes, the usual ones… We were commiserating over Skype one day when the developer asked, “Why do we have to tell everyone what we’re doing—it’s easer to do than say”

As a card-carrying member of the “apology before permission” club this hit me like a bolt from the blue. And from that moment on, we began simply to implement Scrum practices without calling attention to it. I have no doubt that we didn’t fool some of the people most of the time but that wasn’t the point. The point was that we were developing customer delighting, valuable software.

The Scrum Words Get in the Way

I think one of the biggest obstacles to implementing Scrum, at least initially, is the language of Scrum itself. It starts with the name Scrum—invariably in a training class, someone will ask, “What does SCRUM stand for?” Though every trainer has a stock joke for this common misconception (and some have two or three), we eventually explain that Scrum isn’t an acronym at all.

And that’s not the only question that comes up in most training classes:

“Why call it a sprint if one of the goals is sustainability?”
“Doesn’t backlog send the wrong message?”
“Scrum Master? What do they do?”

The language and ceremonies can seem hard to digest. So what I often do is explain the concepts without the confusing language:

1) What do you want to do from the point of view of a single user? (Tell me the story of what you want to happen.)
2) I’ll keep track of all the things you want to do and you can help me decide what to do first to get the most business bang for your buck.
3) Let’s get together everyday for about 10 minutes and talk about the progress we’re making.
4) Every two weeks (at least) let me show you what we did and you can make sure we’re going in the right direction.

Without introducing new language, I’ve just described concepts that are universally appealing. Who wouldn’t want to work like that? And that’s the point. Once you start doing Scrum, rather than talking about it, you realize that while its name and terms might be hard to say, it’s relatively easy to do. So if you find yourself bogged down in explaining Scrum, stop talking and start doing. You might be surprised by how quickly people begin to come around to a new way of working.