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

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.

Leave a Comment