Tony is in charge of methodology development and deployment for a large professional services firm, EngageX. He and I have known each other for 10 years—ever since I licensed my company’s process automation software to EngageX for automating its methodology. I was sure that Tony would want to hear about Scrum, so I called him and arranged for a meeting. Tony is one of the shrewdest people I know, and he quickly grasped the concepts and benefits of Scrum. But he wanted to know how Scrum addresses fixed-price, fixed-date contracts. These were the bread and butter of his firm, and the ability to estimate the contract and bring it in on schedule at or below cost was critical. His customers wanted to present a problem and have someone tell them exactly what the cost of solving it would be and when the solution would be delivered. In competitive situations, the firm with the best combination of reputation, low cost, and early date would get the business. Most of these customers had been burned more than once, and the trust required for collaboration between them and EngageX, or any other development organization or professional services firm, was unlikely, at least in the initial work.
I had to admit to Tony that I didn’t know how to use Scrum to address his business. Scrum’s principle is “the art of the possible,” not “you give me what I paid for, when you said that you’d deliver it.” For several years after my meeting with Tony, this problem rolled around in my head and just wouldn’t go away, until finally I realized that Scrum had no silver bullet—it had to go about addressing fixed-price, fixed-date contracts exactly the way any other process would, including the defined, heavyweight methodologies. There simply was no way around analyzing the customer’s requirements enough to understand the scope of the problem and designing enough to understand the number and complexity of the architecture and design artifacts. What a terrible realization! This meant adding a waterfall phase to the front of the Scrum methodology that would produce documentation. That was terrible, and what possible benefit could Scrum provide after it had been so corrupted?
The more I thought about it, the more I realized that—even though Scrum couldn’t be used in its entirety—EngageX or any other organization bidding on fixed-price, fixed-date contracts could use Scrum to gain competitive advantage in bidding on fixed-price, fixed-date requests for proposals (RFPs). This approach could lead to collaboration between EngageX and its customers that would then lead those customers to see the benefits of Scrum. The approach is described below and has been used in several situations.