Scrum | Government | Project Management | Software Engineering | Agile | Open Source Mo Incentives Mo Problems January 10, 2016

Neil Chaudhuri (He/Him)

LinkedIn

As I help to revolutionize how government buys IT by teaching federal acquisition professionals to avoid spending hundreds of millions for deliverables that don’t work, I have stressed that the best way to maximize value and save taxpayer dollars is to understand the principles behind agile software development and to construct contracts accordingly.

Incentives (also called fee) have long been a significant part of government contracts—including contracts for software application development. When it comes to IT contracts, that needs to change as the government gets more agile. If you understand the core principles of agile development, it’s easy to see why.

For government contracting officers, incentives rest on two implicit premises:

• Adversarial relationship. Since the vendor may not have your best interest at heart, you need to make sure the vendor is sufficiently motivated to deliver.
• The value of underpromise/overdeliver. Though the contract specifies precisely what must be delivered to be in legal compliance, you want to encourage the vendor to go above and beyond that bare minimum.

Both of these premises are irrelevant in agile development, so the notion of incentives is moot.

#mindblown

On the adversarial relationship, in agile development you are all on the same team—literally. You are working together daily—Product Owner and vendor, and all decisions are team decisions. As the team delivers production-quality software regularly for everyone to see at each (assuming Scrum) Sprint Review (along with metrics like velocity, technical debt, defects fixed, etc.), all stakeholders build trust with the vendor.

On underpromise/overdeliver, there is no set finish line of scope; scope is constantly changing by adding new user stories, reprioritizing existing stories, and splitting epics into stories. So how do you overdeliver against a moving target?

Meanwhile, each sprint the vendor commits to deliver as much as possible given capacity, and the team signs off on the Sprint Backlog as a whole—Product Owner too. So it isn’t like the vendor can cheat on capacity or commitment even if it wants to. As a result, because the best agile contracts are fixed-date or fixed-budget (which by the way isn’t the same as fixed-price), by the end you’ve delivered as much as possible within either constraint. There will almost certainly be more features left—thankfully only the lowest-priority ones. But even still it’s like the repairs on your house; you’re never truly done. Overdelivery is impossible.

So the assumptions underlying the motivation for traditional contract incentives are irrelevant to agile development. As agile thought leader Yoda once put it, ”You must unlearn what you have learned.”

Now this isn’t to say that the concept of incentive is totally bad per se. If you contract in 6-month release cycles, for example, and the Definition of Done includes doing all the things necessary for a seamless transition to a hypothetical new vendor (e.g. good documentation, high code coverage, etc.), the current vendor will be plenty incentivized to do a good job so it can keep working—whether that means winning a re-compete, getting its option picked up, or whatever the contract vehicle specifies.

And maybe the contract offers a financial reward if the same vendor makes it all the way from MVP to to production release. Kind of like a Family Feud bonus round situation.

The interesting thing is to figure out how agile contracting comports with the FAR. That’s what our course for federal acquisition professionals and the TechFAR are for.

As these ideas permeate government, the only downside is that I won’t be able to make as much money, and a fella’s got to eat.

And by eat, I mean buy one of those new 8K HDTVs showcased at CES.