Success is a funny thing.  When we started Scrum, I think we got the go ahead because management didn't think it would work.  They cut us some slack to try something new, but 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.  But they don't really want to sell Scrum.  They just want to sell the results.  Part of the problem is that although we have worked very hard to explain the basic practices of Scrum and Agile processes, most of the folks trying to sell our services (and our "process") still don't get it. 

I recently attended a short-list interview for a large county government GIS contract.  We were in the top three vendors selected to compete for the contract.  Dave Bouwman (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 more about processes than try to put them on great big slide presentations).  When I got to the pre-interview walk through of the 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 waterfall, there were other boxes representing where we would have contact with the client.  The only contact prescribed for the client during the work execution was for program financial status and schedule status. 

I asked where in this melee of boxes on the flowchart our Scrum process fit.  The answer I got was "Oh, in the work execution box of course'.  Wow!!!  I couldn't believe what I had heard.  The whole thought process was that Scrum was just a little development process that worked inside the larger project management framework...just another little cascade in the larger waterfall.  This program would have multiple projects running at one time, all working in a waterfall framework, with only the work execution "boxes" utilizing Scrum to develop software.  For all of our hard work, we still hadn't convinced the management team that Scrum was an entire project management process.  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.

Fortunately for us, we had a set of backup slides with our Scrum process diagrammed out.  The interview panel asked how we would manage our projects and I was able to show the slide and give them the Scrum elevator speech.  They were interested in how Scrum would provide them valuable, useable software in a relatively short period of time.  They asked several follow up questions and were genuinely interested in the process.  Our 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 as well.  However, he took the default position of saying that whatever suited the client, be it Scrum or a more traditional waterfall approach, we would provide it.  He wasn't being a jerk.  He was just trying to sell our services and 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 methodologies and Scrum in particular are scary to most people.  Some mistake its 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 believe Scrum is truly just a software development methodology that fits neatly into one of their waterfall boxes.  However, Scrum is a powerful project management process that works for many types of projects.  I know of people in other industries using Scrum for anything but 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 get it wrong.  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 by Rebecca Traeger (available from the Scrum Alliance website).  He's coming around slowly.  Before we took off, he commented that he see's the value in Scrum, "It's basic common sense.  How could it not work?"  In my head 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.