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

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

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.

Answer 2

Our PM practices are still catching up to the agile approach of delivering software. Most of the time, erring on the side of caution, the initial contract defines high level objectives but attaches constraints on functionality with foreseeable technical challenges. Certain major delivery milestones, i.e. alpha, beta, final, are defined and priced in. Additional scope is defined as change requests which supplement the original contract. It's a learning experience as we moved away from traditional waterfall approaches; the biggest problem I've seen is that some things like regular deployments are difficult to price in because you never know how much time addressing the "feedback" from an iteration is going to take. We've had "this is awesome, we're moving along well!" and we've had "here's a list of 200 defects"; there's a varying degree of understanding of what the purpose of frequent releases are among clients.

Answer 3

The only agile projects I have ever worked on were either In House, Time and Materials (T&M) or Pay per Cycle projects.

The trouble is, as you have pointed out, that there is a risk of a project failing/ending early. However, isn't that the same as any project? If you go T&M you take all the risk, if you go Fixed Price the customer takes all the risk. By going Pay Per Cycle you are taking most of the risk, but are passing small chunks of it onto the customer one cycle at a time. As it happens neither you or the client want to take any risk at all, which is why you have posted this question.

The trouble is taking risks is what business is all about, the more risk you take the bigger the profit when it comes off, but also the bigger the loss if it doesn't. If the risk is too great for you to handle the only solution is to find someone else that can take the risk off your hands, but you are going to have to pay them. If neither you nor the client are prepared to take it then there are probably only two answers:

1. Get some rich fool to underwrite the risk (i.e. get insurance).
2. Spread the risk out amongst a number of people until the risk each one takes is so small that it is acceptable.

I think this second option is what makes Contactors so popular. Because they are easy to get rid of, they end up taking the risk of an early project termination. As the risk would be spread between a number of them, the risk is spread to an acceptable level. They will charge you more than an Employee because of the extra risk, but that is what you get for trying to avoid the risk yourself.

Answer 4

Our contracts hasn't changed since we switch to agile, the client still want to receive build at major milestone and is too far to be directly involved at each end of sprint. The product owner doesn't have to be the person at the other end of the contract, it can be an executive manager. The product owner is in constant communication with the needs of the real client, he evaluate the needs to show it to the client. Still it will be a lot easier to that person to communicate with the client if he has frequent releases.

Answer 5

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 6

The last thing you want on an agile project is fixed scope (generally what is contained in a contract on a traditional waterfall project). What you do want is an agreement to a fixed schedule with a fixed size team working against a prioritized product backlog.

If you force your business partner to define a fixed scope during initiate, they will stuff all they can think of in the contract. Not because it has value, but because it will be hard to make changes later and they might need it.

One can provide a high level estimate for a set of features requested by the business partner. However, the team, composed of IT and a product owner accepts that scope and priority will and can easily change during the implementation of the features. By keeping focus on working on the most important features first the team becomes value driven not plan driven. If anything does fall off the list it is of lesser value and has been displaced by something the team learned to be more important.

A contract for fixed scope locks the team into making scope decision when they know the least about the features. Focusing on priority and allowing priority and scope to flex between iterations ensure what is delivered has value.

Instead of signing a contract for fixed scope with the business, attend an agile boot camp with your business partner. The class should outline the agile process and the role of the product owner. If the business accepts the agile approach you ready to begin development. Build you product backlog, prioritize it, provide a high level estimate, build a release and iteration plan and start delivering value.

The way we executed the relationship is to first send the business partner to agile boot camp. Then we trained the business partner to be a product owner. Then we built the backlog, provided a high level estimate and fixed the size of the team and time boxed the development. Within two weeks the first working software was demoed. From that point on the business partner was in and understood the value of making change as they learned more. Any discussion of a fixed scope contract was soon forgotten.

Answer 7

The way we are handling this is quite productive.

Our clients basically purchase iterations. Clients sign off on a contract saying "X 2-week iterations". There is a process of client education (as common with all agile projects I have worked on) to help the client come up to speed with the planning process and the idea that what they actually get at the end of the development process is not concrete at the start of the project BUT that they control what final outcome will be.

Our team has been working together for nearly six months, we have solid technology base we have developed ourselves to minimise risk. We have a pretty solid grasp of our ongoing capacity in terms of velocity - this helps us make predictions about the number of iterations required to meet the desired client outcome.