Agile Contracts


#1

I am currently working with a client who is undergoing a infrastructure renewal program in which all of their legacy apps will be retired by 2020. At the core of this strategic objective has been the decision to buy rather then build. At the same time, this client has decided to undergo an Agile adoption. Do you see the dilemma? The two tend to not play nicely together mainly because of contract negotiations. How do we structure our contracts so that we can put ourselves in a position to be Agile?

FYIā€¦I have read the literature on Agile contracts and the different approaches, but ā€œFā€ the theory. What has worked and not worked for you guys?


#2

Yowza. Been through one of those once. From my experience, the contract didnā€™t matter once the program started. Cost and time were fixed and the battle of who was running the program (the system implementer it was outsourced to, or the company that hired them) started.

The intent was to ā€œinstall out of the box and change business processā€. Three years later, in the directorsā€™ words, ā€œwe are just as fucked as we were before we startedā€

I was on the internal coaching team, we reviewed the RFP and added language around wanting the implementor to supply evidence theyā€™ve worked in an agile way, and other stuffā€¦and none of it mattered. The implementors came in and bullied their way of working on the organization.


#3

Hi mccallam2,

Buy rather than build, eh? ā€¦then your client is the customer not the implementer.

Think carefully about what it means to be an agile customer ā€“ a customer of agile teams. A few things come to mind:

  • Customers of agile teams ought to expect day-to-day contact with the Scrum Team(s) theyā€™ve hired.
  • Customers of agile teams ought to expect to see frequent ā€˜Doneā€™ software.
  • and be able to provide frequent feedback.
  • Customers of agile teams ought to expect the engineers have direct access to end-users whenever needed.
  • Customer of agile teams ought to expect incremental delivery and no big-batch dumps of new features (this is super important for end-users ā€“ most users are familiar with the apps on their phone updating multiples times per week and incremental change to user interfaces; users hate big-batch changes to their UI)

How to avoid pitfalls:

  • Your client ought to build a contract around quality of product and quality of communication. (Not around quantity and fixed dates.) Example: Definition of Done can be contracted; Sprint-length (1 week, 2 weeks) cycles of planning/implementation/deployment can be contracted; put in the contract: known defects, known security vulnerabilities, known performance problems will be prioritized immediately (no negotiation necessary) to the very top of the backlog. (This will keep quality high.)
  • Your client can ensure, in their contract, that testing is not deferred or delayed until after the Sprint.
  • Your client can demand frequent deployment and incremental delivery of ā€˜Doneā€™ software.
  • Your client can demand Sprint-based pricing with clauses like: "reserve the right to terminate the contract within 2 Sprints if quality or frequency of deployments drop below acceptable thresholds.

Having said all that, Iā€™m making some huge guesses about the types of product your client has chosen to buy ā€“ Iā€™m presuming they intend to replace many systems all which require some level of customization.

(Please let me know if Iā€™m on/off track.)


#4

Amen. Love this. Agree with all and if I had this advice a few years ago I probably would have done lots better. we also should have allowed for regular cadenced feature ideation processes and worked in the same alm tool to ensure transparency.

I would also add that at a large telecommunications company in Philadelphia who will not be named, contracts actually included a defined estimated story point delivery from the customer to the implementer to ensure that the implementer could have cash flow to keep people on staff. This turned into a story point for dollars scenario. Donā€™t do this.


#5

You know, I wonder if contracting out to a vendor in a way that resembles whatā€™s described here might be an opportunity to improve your clientā€™s own transformationā€¦

Itā€™s a lot ā€œeasierā€ to make demands on a vendor in this scenario than on your own management. A successful engagement with a vendor - one which has agility at the core of the contract - could go a long way towards changing peopleā€™s minds (or at least, showing them that ā€˜yes, this can actually be doneā€™).

Alternatively, if the project fails, transformation will face even more resistanceā€¦ so thereā€™s that :slight_smile:


#6

I found this article informative, in that it makes the case that itā€™s worth it to figure out how to structure a contract in an Agile way ā€“ in the Federal government, no less!
https://www.actiac.org/AcquisitionBestPracticestoProcureAgileITServices