The 7 Rules of Agile Contracting

It’s happened to me. It’s happened to you. It’s ultimately going to happen to most of the government contracting attorneys out there. The sales lead or account exec sidles up to you or pops open a chat window and says, half furtively and half excitedly, “Hey, we’re doing Agile this time. Can you make sure the contract is an Agile one?”

(“Sure thing. I’ve had it doing jumping-jacks and tendus since 7 in the morning.”)

The Agile methodology is currently very much in-demand by government procurement authorities and state agencies. If executed properly, it bypasses the obvious pitfalls of the Waterfall method, where you are (I simplify here) getting feedback on the deliverable only after it is finished. By contrast, if you’re using the Agile methodology properly, the client can give you feedback through every stage of the development, and you can build on and incorporate that client input into all subsequent stages of the deliverable.

So what are the things lawyers and contract managers can look for to make sure the contracts they are preparing can handle Agile?

1.      Make sure the client is properly staffed: Agile won’t work if the client has not dedicated enough resources and manpower to this project. If the client is understaffed, they can’t sign-off on your deliverables in a timely manner. This will mess up the timetable through no fault of your own. This can be an especially vital point if your client is a governmental agency that’s not particularly well-funded or has been going through some recent RIFs.

2.      Have a robust Saving clause: You can spell out the client’s responsibilities as specifically as you want, but it’s of no use unless you protect yourself from their failure. Make sure the savings clause says that your company won’t be liable if the client does not fulfill its obligations. Not enough people from their side providing input? Their manager dragging their feet? Acceptance notices not coming in a timely fashion? Savings clause should specifically call out these and other situations, and be clear that you can’t suffer for the client’s shortcomings.

3.      Make sure the project is mapped out: What distinguishes a successful Agile project from another run-of-the-mill level of effort obligation is the mapping-out that takes place in the beginning so that both sides know how many sprints are necessary, how many points need to be covered by each team, and what the key milestones are. Make sure the main body of the agreement itself has these details, and resist the temptation to bury them in a dusty appendix somewhere that everyone will forget about two seconds after the contract is signed.

4.      Build in reporting requirements: The first time the client messes up and the team falls behind as a result, there will be a lot of temptation on the project manager to just look the other way and pretend there’s nothing wrong. Which makes sense, since she’s the person who has to deal with the client personnel every day, and it’s a normal human instinct to try and avoid unpleasantness as long as possible. Avoid this problem right at the beginning by building in stringent reporting requirements that will have to go to high-level executive sponsors every week. When in doubt, err on the side of the onerous.

5.      Have a competent project manager:  If you’re doing Agile, your project manager will be spending a LOT of time with your client, even more than she would be in other traditional projects. This is by design, because Agile only works if the sprint teams are getting constant and structured feedback from the client teams. However, what you don’t want is your project manager developing a serious case of the Stockholm Syndrome and always parroting the client’s line to you in internal meetings – effectively forcing you to negotiate with yourself. This’ll sound like a cliché, but one of the best ways to avoid this is by having successful project managers who have delivered on Agile projects in the past – you’ll then know they are aware of how to navigate this process successfully.  

6.      Provide accurate estimates based on completion of points: If your Agile project is effectively mapped out, you should know how many points you should be completing per sprint. Moreover, some of these points will inevitably have to be redone after every Scrum with the client. However, even taking this into factor, the number of points being completed at major intervals should maintain parity or stay close to striking distance of what the project outline calls for. Fall too far behind, and there’s no way the team will be able to catch up during the final madcap days of UATs.

7.      Don’t throw good effort after bad: As Agile projects near completion, clients inevitably begin thinking of more bells and whistles they can add on to projects. If they have creative lawyers, or if your project manager has fallen captive at this point (see #5), they can even make halfway-cogent arguments to your management team as to why the contract included that shiny new functionality all along. As the deal attorney and the designated purveyor of sanity – stay strong! Resist the inevitable calls to authorize additional levels of effort or extra scrum teams (unless, of course, the client agrees to sign an amendment and pay more).

Follow these seven rules, and the chances are that your Agile project will go smoothly, and you can do some well-deserved bragging about it at the next office holiday party. Ignore them, and you’ll join the long list of people who’ve seen their contracts take on lives of their own and become cautionary tales.