By Chris Spagnuolo
Success is a funny thing. When we first started using Scrum, I think we got the go-ahead because management didn't think it would work. They cut us some slack to let us try something new, but were sure we'd be back to waterfall before we knew it. Now that we're using Scrum and producing quality, valuable software on time and under budget, everyone wants to know how we did it. They also want to start marketing it and selling it to potential clients. Fabulous, right? The problem is they don't really want to sell Scrum; they just want to sell the results. Although we have worked very hard to explain the basic practices of Scrum and other agile processes, most of the folks trying to sell our services (and our “process”) don't really get it.
For instance, I recently attended a short-list interview for a large, county-government GIS contract. We were among the top three vendors selected to compete for the contract. Our lead architect and I were asked to provide input on our software development practices. We had a few slides about our development environment, a few on our relevant project work, and one slide on Scrum. The Scrum slide had no text, just a diagram illustrating the Scrum process that we borrowed from Mike Cohn at Mountain Goat Software (we like being lean and like to talk about processes rather than try to put them in great big slide presentations). When I got to the pre-interview walk-through of the proposal team's presentation, the Scrum slide was conspicuously absent from the main presentation. In its place was a very impressive-looking program and software development workflow diagram—lots of boxes with labels like initial concept discovery, statement of work, draft work order, kickoff, work execution, testing, acceptance, and closeout. They were all lined up with nice little arrows connecting them in the traditional waterfall fashion. At punctuated, pre-determined points along the path, there were other boxes representing where we would have contact with the client. The only contacts prescribed for the client during the work execution were program financial status and schedule status.
I asked where in this melee of boxes our Scrum process fit. The answer I got was, “Oh, in the work execution box of course.” I couldn't believe what I had heard. To management, Scrum was just a little development process that worked inside the larger project management framework, just another little cascade in the larger waterfall. The way they saw it, they would have multiple projects running at one time, all working in a waterfall framework, with the only exception being that inside the work execution boxes teams would utilize Scrum to develop software.
We had been talking about Scrum as an overarching process for everything for months now. We had been emphasizing not only client communication, but very active client participation in the Scrum process, not just project financial/schedule status reports. For all of our hard work, we still hadn't convinced the management team that Scrum was an entire project management process.
Fortunately for us, we had a set of backup slides with our Scrum process diagrammed. When the interview panel asked how we would manage our projects, I was able to show the slides and give them the Scrum elevator speech. They asked about a half-hour of follow-up questions about Scrum and were genuinely interested in the process, especially in how Scrum would provide them valuable, useable software in a relatively short period of time.
The senior manager on the interview team backed our Scrum play and added some good insight into how our GIS development team was effectively using Scrum on other large-scale projects. However, he took the backup position of saying that we would provide whatever suited the client, be it Scrum or a more traditional waterfall approach. He wasn't being a jerk. He was just trying to sell our services—I understand that.
The point of all this is that it is very difficult to break the almost institutionalized acceptance of the waterfall approach to project management. Agile practices and Scrum in particular are scary to most people. Some mistake their relative simplicity for inadequacy in terms of project reporting and project management. Some underestimate the value of the iterative approach and the inherent increase in client communication and satisfaction that it provides. Most are just pre-conditioned to believe that if we don't understand everything up front, we can't run a successful project. So, I'm not upset with our management team. I know why our Scrum slide turned into a little box on the larger waterfall slide. They truly believe Scrum is just a software development methodology that fits neatly into one of their waterfall boxes. However, what we must continue to impress on them is that Scrum is a powerful project management process that works for many types of projects. I know of people in other industries using Scrum for projects that are much different from software development. I met a woman at a training class a few weeks ago who is using Scrum on real world construction projects for large hospitals. I've even heard of people using Scrum to plan their weddings.
So, keep selling Scrum to your management teams. Keep educating them. Keep correcting them when they misinterpret Scrum. But do it in a manner that helps them to understand and accept Scrum over time. It's our job as practitioners of Scrum to help others understand the process as more than just a software development methodology. We need to become Scrum evangelists of sorts, bringing the real message of the efficiency and value of Scrum to the non-believers.
On our flight home after the short-list interview, I referred our manager to Ken Schwaber's book Agile Project Management with Scrum. I also handed him a whitepaper called “A CIO's Playbook for Implementing Scrum” that I downloaded from the Scrum Alliance website. He's coming around slowly. Before we took off, he commented that he sees the value in Scrum, “It's basic common sense,” he told me. “How could it not work?”
I thought, “It's basic common sense, how could you still not get it?” Instead, I just smiled and said, “Yup, you're right!” and kept my hope up that he'd actually read the whitepaper and the book someday.
