By his own admission, Ron Jeffries 
is no salesman. That's a good thing, not because he lacks anything of value to sell, but because it enables him to spend a bit more time each day applying his considerable brainpower to more constructive activities, such as, for example, helping to write the Agile Manifesto .
But I think he misses the mark when he says "How do we sell Extreme Programming?" is the wrong question to be asking. On the contrary, it is a critically important question. We do need to "sell" Agile, and XP, and all that. The new way has far to go before it becomes the industry norm. During the present transitional period, members of the Agile community must be able to explain to the skeptical and the wary exactly how and why the Agile approach can help them.
Ron doesn't like the question because he thinks the word, "sell," implies "the would-be buyer doesn't want whatever we're offering" and because "very few people really want Agile / XP, and those who do don't need us to sell it to them." I think he is completely wrong on the first point, and partially wrong on the second.
The word, "sell" implies nothing about the would-be buyer. There is nothing about the word that says anything about whether the would-be buyer "wants" the product. To "sell Agile" only means to help others understand whether and how the Agile approach can help them meet their needs. Ron is right that nobody "wants" Agile or XP as such; the approach and the methodologies that support it are only means to an end. To say people "want" Agile is like saying they want a motor, a set of brakes, and a steering wheel, when in reality what they want is to go from point A to point B, preferably in reasonable comfort and without getting wet in the rain along the way.
The end - what the would-be buyers want - is an effective, efficient, productive software development organization that brings quantifiable business benefit to their company. Those of us who have done this work both ways understand where Agile fits into the big picture, but most IT professionals don't...yet. We'd better be able to "sell" it.
Okay, so how do we go about it? To say, "go out and sell Agile" smacks of the old Monty Python bit about the How To Do It show:
"This week on How to Do It we're going to show you how to play the flute, how to split an atom, and how to irrigate the Sahara Desert. But first, here's Jackie to tell you all how to rid the world of all known diseases."
"Well, first of all, become a doctor and discover a marvelous cure for something...and you can jolly well tell everyone what to do so there'll never be any diseases ever again."
"Thanks, Jackie. Great idea."
Yeah. Great. Okay, so we're agreed the would-be buyers don't "want" Agile or XP particularly. What do they want? They want quantifiable business benefit. Fine. What does that mean, and how do we know when we've got some? Technical professionals tend to think of "benefit" in terms of software efficiency, solution elegance, user friendliness, and other soft factors. The problem is that soft factors are hard to measure. A programmer can tell by looking at code whether an application is easy or hard to maintain. How can that factor be quantified? How can it be connected with the development methodology that was used to build the application? The question of how to "sell" a development project approach becomes very sticky very quickly.
As knowledge workers, we understand that one of the best ways to deal with a question that's too sticky is to change our frame of reference to make the question disappear. In the new frame of reference, the set of questions is different, and possibly easier to address. In this case, we must stop thinking like technicians and start thinking like businesspeople. Businesspeople don't care about software performance, code maintainability, and all that jazz. The sticky question disappears. In its place, a new and simpler question arises: How can I reduce my costs and increase my revenue? The new frame of reference also provides us with a single unit of measure that is well understood by everyone: Money.
So far, we know we have to find a way to demonstrate that the Agile approach enables an organization to reduce the costs of IT projects and, where applicable, improve revenue generated by the solutions delivered. We also know the unit of measure we must use to demonstrate these benefits is money. So, who needs to be convinced, and how do we do it?
It turns out you don't have to convince your boss. IT management is not a key constituency in this case. That's good news, because IT managers are likely to be more firmly committed to the waterfall approach than anyone else in the organization. They're the ones with PMI certification . They're the ones interested in CMM Level 5 . They know about the motor, brakes, and steering wheel. Businesspeople only know they want to go from point A to point B cheaply and quickly. They'd rather travel in reasonable comfort, and they'd rather not get wet in the rain along the way, but the truth is that if the trip is cheap enough and quick enough, it's all rock and roll to them. They're the main people who need to understand the value of Agile, and they need to understand it in terms of money. Therefore, obviously, what you need is a business unit manager who is ready to try something new.
I suspect it's still a bit unclear how to proceed from this point, if you're working in an organization that hasn't officially embraced the Agile approach on even an experimental basis. How in the world are you supposed to find a business unit manager who is ready to try something new, willing to go around the bureaucracy to do it, and prepared to hand you money to pay for it? Even with all that, how are you going to find the time and resources to do a project "on the side," when your management is already keeping you busy full time? Finally, where are you going to find a small team of colleagues who know enough about the Agile approach even to attempt such a project? This is all a pipe dream, isn't it?
Actually, it isn't. At the company where I'm now employed, we've been building an internal Agile practice for the past couple of years. The group started life with a skunkworks project undertaken for a business unit manager who needed something of limited scope done quickly and cost-effectively. At the time, we had never heard of Agile; we only knew the established project methodology was overburdened with process and was not satisfying our customers. We were open to alternatives. It happened pretty much as described in the preceding paragraph, except that we didn't really have to do the work "on the side." Fortunately, our immediate manager was keen to try an alternative project methodology that might offer better results than the waterfall approach, and his manager trusted him to give it a shot. That first effort was successful, and the Agile practice has been gaining momentum ever since.
That's how you "sell" Agile in a skeptical organization: Demonstrate its value by delivering quantifiable and visible business benefit. You will need the following:
- A business unit manager who:
- has the authority to make budgetary allocations autonomously,
- has experienced poor results from the IT organization using traditional software development methods,
- has a good personal working relationship with you or with your immediate supervisor, and
- has a business need that calls for an IT project of limited scope that he/she is willing to risk on an unproven approach.
- A proposed project that:
- is of limited enough scope that a handful of developers can handle it,
- would require considerably more time to complete using the established project methodology, for whatever reason,
- involves high perceived risk but low actual risk,
- will yield significant financial rewards for the business unit if successful,
- will be highly visible to other business unit managers and to senior corporate management, and
- can be built and deployed on hardware and network resources already available to the team, so that the corporate procurement process need not be involved,
- An unambiguous method of quantifying and comparing the estimated project cost and timeline under the established project methodology, and comparing that with the actual cost and timeline of the Agile effort. The best way to get the estimates for the traditional approach is to have the business customer submit the proposal to the IT department and ask for a project estimate through the company's standard procedure, as he/she normally would do for any proposed project. Those estimates will be better than any you could come up with on your own for two reasons: First, since the established project estimation process is followed, the estimates will be reasonably accurate and tailored to your organization; second, opponents of the Agile approach will have a hard time disputing their own estimates, in case they try to call the comparison into question later on.
Why should the project have the characteristics listed above? Won't any project do just as well?
Any project won't do just as well for the simple reason that the Agile approach is not a one-size-fits-all magic cloak. It is well suited for certain types of projects, and less well suited for others. Since your goal is to "sell" Agile to a skeptical organization, you need a project that will elicit the most favorable results possible, especially with a view toward cost comparison with a traditional project. This isn't something you can "fake." Your chances of success are improved by choosing a project that naturally lends itself to Agile.
The scope of the project must be within reach for a very small team; maybe as small as four. You will be able to find only a few colleagues in your organization who are up for the challenge and who can spare the time from their regular assignments to participate in a skunkworks project. You will also benefit from having a couple of experienced Agile consultants on board to show you how to run a project using one of the Agile methodologies, Extreme Programming , Scrum , or Crystal . This is the kind of skill you learn by doing, not by reading.
Waterfall methodologies do best on projects that have well-defined requirements that are unlikely to change in flight; that build solutions based on well-understood technologies; and that are generally predictable. Agile methodologies do better on projects that have only broadly-defined requirements at the outset and the expectation that requirements will change as the customer learns more about how the solution is going to play out; that introduce new technologies to the organization; and that involve a high level of uncertainty. For your Agile demonstration project, look for a business need that conforms to the latter model. The unpredictability, undefined details, and perceived risk will drive the traditional project estimate higher, making the eventual comparison of costs and timelines all the more dramatic.
The combination of high perceived risk and low actual risk occurs when a proposed solution involves technologies or products that have not already been established in the standard technical infrastructure the IT organization supports. Look for an opportunity to introduce a new technology that is not technically difficult to implement, but that has not been used at your company before. This will drive the traditional project estimate higher without increasing the actual difficulty of your project.
Because the waterfall approach calls for risk avoidance through careful and detailed planning, any project that involves new technologies and/or high perceived risk will require additional start-up time. Look for a business need that is time-constrained. This will help emphasize the benefit of the Agile approach when the traditional estimated timeline is compared with the actual Agile timeline. The opportunity cost incurred by the start-up delay in the traditional project will increase the cost differential between the traditional estimate and the Agile project's actual numbers, since there is no start-up delay in an Agile project.
At our company, the first Agile project involved the development of a web application that interfaced with an internal mainframe system and an external network-based service, and that supported wireless client devices. The business opportunity was time-constrained in that the company wanted to supply its field representatives with the tool in time for the spring sales rush in the market segment they were targeting; this all started in February. They anticipated an immediate return of $700,000 with annual revenues of around $4 million. If we missed the spring sales rush, we would lose the current year's sales as well as losing market share to competitors, with an estimated opportunity cost of about $2 million in annual revenue.
The official IT organization had no previous experience supporting wireless clients, and limited experience interfacing with mainframe systems. They padded their estimates accordingly. The external service provider was willing to write a custom interface to their application, requiring four months' time and a cost of about $150,000. The alternative was to screen-scrape the provider's application, which the IT group did not wish to do. Finally, they proposed to buy and install dedicated servers to support the solution, including hot failover support despite the fact the cost of downtime and probability of an outage were both very low. In the end, the IT organization proposed building the solution in ten months at a cost of about $850,000. This estimate left the business unit with an opportunity cost of $700,000 the first year and $2 million per year afterwards; the company would have lost $150,000 the first year, and then made about $2 million per year for the duration of the solution's lifetime in production.
With a team consisting of one lead, one business analyst, and two developers, we undertook the same work following the Agile approach and using the Extreme Programming methodology. We screen-scraped the external provider's application. While this was technically inelegant, it had the advantage of eliminating the 4 month delay and $150,000 cost of the proposed custom interface. The two developers both had experience in Java, web applications, and mainframe systems, so we were not delayed by the fact we had to interface with a legacy mainframe system. A wireless server was already available in the test lab as part of a separate project to enhance the company's support for its employees' mobile business phones. It was readily adapted to the role of serving wireless clients for the new application, and fit smoothly into the company's network security environment. The bottom line is we delivered the solution in six weeks, in time for the spring sales rush, at a total cost of about $73,000.
Once that project was completed, the business unit manager talked up the new approach with her colleagues and peers in the company. Soon enough, the IT department had more requests for projects to be done with the Agile approach than it could handle. There's no better salesperson for Agile than a satisfied customer.