How did you sign a contract to an Agile project? (not how you think you would, how you did) [closed]

Question

To execute an Agile project you first need a contract. No contract – no project! No project – no Agile, SCRUM or whatsoever!

The contract, if we are talking about mid to big projects, must have well defined safety triggers. I.e. customers want to be very much sure, that if we agree on ending a project in time = T, budget = B and scope = S we do not end up with time = T×2, budget = B×3 or scope = S/2.

On the other hand we, as a company who delivers the product, do not want the project to end unexpectedly. I.e. if after some iteration customer says "Now I see that this is actually all we needed. We stop now." and the project was planned for another 2 months, than we have people without planned work. If 3–6 people is not a big problem, 15–25 might be a real issue!

Yet I did not find any real example of a contract with safety features in it that would allow the project to be executed in full Agile manner (stated or not stated to customer as such). Standard saying I find on many forums – talk to customer, explain to him that this is much more productive way of work etc. does not convince neither me nor my management. Not that we do not believe in Agile being actually a better way of doing it. It's just that gaps in safety triggers are so obvious that none of our client buys it AND we do not like them (gaps, not clients ;) ) either.

PLEASE no "it would probably work this way …" – I've read tons of that. Only interested in "For us it worked this way". No doubts, skip all the confident info in it.

P.S. As far as I can tell, standard iterative, feature driven approach suggests customer paying after each iteration (number of iterations) and being able to stop the project both by customer and project executor after any iteration without saying much about the consequences, rather than saying "it would fail anyway, so the earlier – the better" (which is correct, but not very helpful when signing the contract).

Answer 1

I work in government.

We recently ran a software development procurement process and selected three vendors to work on an Agile project. Some notes:

1. We were already 75% sure we wanted to run an Agile project because we knew our requirements were ambiguous and because it was a public-facing web project with a significant design element. So I'd say that it helps a lot if your client knows about Agile and buys in from the start, even if they don't actually practice it in-house. Note that acceptance of Agile is growing in (some) government circles, so this may get easier.

2. One safeguard we used was to contract a very experienced (independent) SCRUM master to work for us and handle the software project management duties on behalf of our team lead / architect / usability guy. We spent a lot of time finding this person, and selected them from three great applicants. This was costly but worth it.

3. Once we had selected our vendors and broadly agreed their roles (design, front-end, back-end), we put together a quick MoU outlining our intention to proceed, the likely budget of the project, the likely size of the team from each vendor, a commitment to have a full contract signed by the end of the month, and a time & materials agreement in the interim.

4. Then we jumped in with a technical planning / sizing session and got that side of things going. No dev work or design was done in this time, but we did a lot of sizing and high-level estimation.

5. By the end of the month we put together contracts for each vendor (one was late, but that was ok). One vendor put forward sample contracts that we might use, one based on payment by thirds of the project; the other on completion of sprints. I think in the end we did completion of sprints (billed monthly), using some of the vendor-suggested language in the payments section of our standard contract template.

Overall we were okay with this approach (despite acknowledging some risk) because we didn't think there was a huge amount of actual technical risk in the project overall, and because we had a lot of confidence in the procurement process and in the vendors we had selected.

In the end this was a very successful project, and we have since started using SCRUM in-house for other projects. I think having a great team was key. We were confident in the vendors - not only that they could do the work, but that they were a good fit in terms of their attitude to working as one team, and in terms of there being well-defined roles for each (i.e. they would not be competing for the same money).

If our vendors had not been so good, we would have had a few more reservations about entering into a contract like this, but running procurement is almost as much an art as a science, and we knew we had chosen the team with the best fit an attitude from a pool of other high-quality respondents.

We have since rolled over all three contracts for a second year of development, though I'd say it s not going quite as smoothly this time (new SCRUM master, different team composition) it is still a great project to be involved with.

You may also find this interesting: Outsourcing Agile.

Answer 2

Since I work primarily on intranet apps this hasn't been too much of an issue with me. However, I often do apps for other departments and sometimes, especially when the project is large, we do sign a memorandum of understanding (MOU) with regard to the project scope, (expected) duration, and cost. Since I work in an agile way, none of those things are fixed, which is often hard to explain to other departments that haven't worked this way before. Typically I will include a description of the process itself -- a couple of paragraphs -- explaining how the project is a cooperative venture between them and me, that together we determine when we're done.

By the time the MOU is actually written, I've already invested a number of hours in the project discovering what the requirements are (these are handled at a standard hourly rate). Based on that coupled with an estimate of my velocity and similarity to previous projects, I give an broad estimate of the amount of time and cost for the required features -- again explaining, that the real cost is determined by which features we actually implement and how long it really takes. This takes a fair amount of trust, but since we've been working together to develop the requirements I usually have that with the individuals that I'm dealing with directly. I often try to leave the actual estimate out of the MOU, but will include it if their manager's insist. I do try to give them a budget number.

My experience is that once the project starts and you start delivering value to the customer, they are rarely unhappy. Typically, they ask for (and pay for) more than the original project scope. Often, we both agree that some of the original features are not required, but I always expect that. After all, they really have no way of knowing for sure until they actually see things in operation what it is that they really need. More often than not, we drop some features and add others based on the actual development. I suppose if we didn't there wouldn't be any point to using agile methods.

I think the key issue is trust. I'd suggest working with a new customer on smaller projects or explicitly breaking a large project into smaller projects to develop trust. Once they and you know that you can trust each other to build the right product with the right features, I think the risk -- and there always is one -- of the customer pulling out abruptly is minimized.