--- title: "Mo Incentives Mo Problems" description: "As government IT becomes more agile, it's time to rethink incentives in contracts." canonical: https://www.vidyasource.com/blog/mo-incentives-mo-problems/ type: article published: 2016-01-10 author: "Neil Chaudhuri" tags: ["Scrum", "Government", "Project Management", "Software Engineering", "Agile", "Open Source"] image: https://www.vidyasource.com/img/blog/biggie.jpg --- # Mo Incentives Mo Problems > As government IT becomes more agile, it's time to rethink incentives in contracts. - Canonical page: https://www.vidyasource.com/blog/mo-incentives-mo-problems/ - Structured data (JSON-LD): https://www.vidyasource.com/blog/mo-incentives-mo-problems.json - Published: 2016-01-10 - Author: Neil Chaudhuri - Topics: Scrum, Government, Project Management, Software Engineering, Agile, Open Source As I help to [revolutionize how government buys IT](https://www.vidyasource.com/blog/all-we-do-is-win-win-win/) 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](https://twitter.com/search?q=%23mindblown&src=typd) 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](https://www.scrumalliance.org/community/articles/2013/july/managing-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](https://www.scrumalliance.org/community/articles/2014/march/stories-versus-themes-versus-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](https://www.scrumalliance.org/community/articles/2007/august/perfect-planning), 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](http://www.innolution.com/blog/three-key-agile-risk-management-activities) (which by the way isn't the same as [fixed-price](https://www.scrumalliance.org/community/articles/2014/march/good-bad-and-ugly-of-agile-fixed-price-contracts)), 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.](https://www.youtube.com/watch?v=z4jeREy7Pbc)" 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](https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference) 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](http://leanstack.com/minimum-viable-product/) to to production release. Kind of like a [Family Feud bonus round](https://www.youtube.com/watch?v=Hm2HdJkgRWI) situation. The interesting thing is to figure out how agile contracting comports with the [FAR](https://www.acquisition.gov/?q=browsefar). That's what our course for federal acquisition professionals and the [TechFAR](https://github.com/usds/playbook/blob/gh-pages/_includes/techfar-online.md) 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](http://www.wired.com/2016/01/8k-tvs-coming-to-market/) showcased at CES. --- Vidya is a certified small business in Northern Virginia that modernizes legacy systems, builds enterprise AI, and designs cloud and data architecture for commercial companies and federal agencies. Vidya documents its delivered engagements in case studies and publishes courses, tutorials, and articles for engineers and the people who lead them. The company name is Vidya. Its website is vidyasource.com. Start at https://www.vidyasource.com/llms.txt for the index of everything Vidya publishes, or https://www.vidyasource.com/contact/ to talk to Vidya.