When approaching this subject, I tell myself that it will take time to see a real answer emerge and that probably several, or even many posts will be necessary. Currently all the IT service companies are wondering how to ride the “agile wave” but are running into a crucial problem: contracting. By the way, even though he devotes a chapter to it, Ken Schwaber quickly dismisses the question without really providing an answer.

Historically, the entire project relationship between a client and an IT service company is based on a commitment to results -the fixed-price contract- (I’m not talking here about time and materials, that’s something else). Pre-sales is an eminently strategic moment where the scope of this commitment is definitively set, particularly financially. From this flows a whole series of aberrations, for example:

• The IT service company indeed delivers 100% of its commitment but the client and the company misunderstood each other and only 30% of the functionalities will actually be used…
• The client would like to sign with you because you’re the only one who truly understood their need! but unfortunately as a result you are 30% more expensive than the competitors and purchasing has eliminated your candidacy. No matter if subsequently the purchased product doesn’t correspond, or if the client will have to face a multitude of amendments…
• Your client requests a user management interface, you imagine 3 or 4 management templates and the associated functionalities. Wrong, they simply meant injecting an SQL script into the database… As a result you are far too expensive sir. You were nevertheless the right contact, but the writing of the specifications muddied the game…

Sometimes, and fortunately much more often than one might imagine, if the pre-sales phase hasn’t been fatal, everyone has enough maturity to reorganize the developments, functionalities and objectives within this leaden shroud represented by this commitment to results that is the fixed-price contract.

I won’t go over it again but it’s clearly partly to address these problems that Agile methods are encountering such success. With transparency and involvement being the key words, we avoid many pitfalls, we focus on ROI, etc etc. Very good. but how to bill for this? How to explain to your client: at the end of our collaboration you should have this and that, instead of the much more reassuring: at the end of our collaboration you will have this and that. Even if, and I’m convinced of it, what you should have will have much more value than what you will have, difficult to make them swallow the pill! Especially with certain prejudices around IT service companies, and the reality that they are companies like any others that live off their profits.

I’m setting aside for now the question of responsibility (another complication of Scrum contracting which requires that responsibility be borne by the team and by the product owner-the client-). Go explain to your client that the project failed because of the product owner, that is to say themselves… I’m also setting aside for now the questions of contracting for public tenders…

In short, how to contract a Scrum project (equivalent to contracting a classic fixed-price project) between an IT service company and a prospect?

A method is currently emerging. This is only a step and it only partially addresses the problem. However, it seems to rally a bit all the actors. I find an echo of it in this article (thanks Christophe). It involves conducting a Sprint 0, or an initial study that will allow:

• clearly defining the functional scope: without misunderstanding
• defining the proposed technical/architecture solution
• organizing a calendar of sprints and the list of functionalities associated with each one
• eliminating all opaque areas

The objective of this “sprint 0” is to obtain a sufficiently precise evaluation that it can provide enough guarantees on the should have at the end of the project. A study that should moreover define what we call “end of the project”… In short, despite this study, and knowing the heavy commercial history that pre-exists, you still have a big risk of hearing: “well since we now have enough visibility we can contract a fixed-price type commitment to results ? no?”. There, it’s up to you to re-explain all the relevance of using agile methods and organizing billing by cycle of 2 or 3 sprints.

Finally, we can estimate roughly that this sprint 0 requires a workload of 5 to 10 days (some will tear their hair out that I could give, ex-nihilo, in a vacuum, such figures…). Conducting this sprint 0 naturally also implies that you have already won an initial commercial stage.

Nothing is simple with Scrum, except Scrum itself.