{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://www.vidyasource.com/blog/mo-incentives-mo-problems/",
  "url": "https://www.vidyasource.com/blog/mo-incentives-mo-problems/",
  "mainEntityOfPage": "https://www.vidyasource.com/blog/mo-incentives-mo-problems/",
  "headline": "Mo Incentives Mo Problems",
  "description": "As government IT becomes more agile, it's time to rethink incentives in contracts.",
  "datePublished": "2016-01-10T00:00:00.000Z",
  "author": {
    "@type": "Person",
    "name": "Neil Chaudhuri",
    "jobTitle": "President",
    "url": "https://www.linkedin.com/in/neil-chaudhuri/",
    "sameAs": "https://www.linkedin.com/in/neil-chaudhuri/"
  },
  "publisher": {
    "@id": "https://www.vidyasource.com/#organization"
  },
  "image": "https://www.vidyasource.com/img/blog/biggie.jpg",
  "keywords": [
    "Scrum",
    "Government",
    "Project Management",
    "Software Engineering",
    "Agile",
    "Open Source"
  ],
  "articleBody": "As I help to [revolutionize how government buys IT](https://www.vidyasource.com/blog/all-we-do-is-win-win-win/)\nby teaching federal acquisition professionals to avoid spending hundreds of millions for\ndeliverables that don't work, I have stressed that the best  way to maximize value and save taxpayer dollars is to\nunderstand the principles behind agile software development and to construct contracts accordingly.\n\nIncentives (also called *fee*) have long been a significant part of government contracts--including contracts for software application\ndevelopment. When it comes to IT contracts, that needs to change as the government gets more agile. If you understand\nthe core principles of agile development, it's easy to see why.\n\nFor government contracting officers, incentives rest on two implicit premises:\n\n* **Adversarial relationship.** Since the vendor may not have your best interest at heart, you need to make sure the vendor\nis sufficiently motivated to deliver.\n* **The value of underpromise/overdeliver.** Though the contract specifies precisely what must be delivered to be in legal\ncompliance, you want to encourage the vendor to go above and beyond that bare minimum.\n\nBoth of these premises are irrelevant in agile development, so the notion of incentives is moot.\n\n[#mindblown](https://twitter.com/search?q=%23mindblown&src=typd)\n\nOn the adversarial relationship, in agile development you are all on the same team--literally. You are working together\ndaily--Product Owner and vendor, and all decisions are team decisions. As the team delivers production-quality software\nregularly for everyone to see at each (assuming Scrum) Sprint Review (along with metrics like velocity,\n[technical debt](https://www.scrumalliance.org/community/articles/2013/july/managing-technical-debt),\ndefects fixed, *etc.*), all stakeholders build trust with the vendor.\n\nOn underpromise/overdeliver, there is no set finish line of scope; scope is constantly changing by adding new user stories,\nreprioritizing existing stories, and splitting [epics](https://www.scrumalliance.org/community/articles/2014/march/stories-versus-themes-versus-epics)\ninto stories. So how do you overdeliver against a moving target?\n\nMeanwhile, each sprint the vendor commits to deliver as much as possible given [capacity](https://www.scrumalliance.org/community/articles/2007/august/perfect-planning),\nand the team signs off on the\nSprint Backlog as a whole--Product Owner too. So it isn't like the vendor can cheat on capacity or commitment even if it\nwants 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)\n(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)),\nby the end you've delivered as much as possible within either constraint.\nThere will almost certainly be more features left--thankfully only the lowest-priority ones. But even still it's like\nthe repairs on your house; you're never truly done. Overdelivery is impossible.\n\nSo the assumptions underlying the motivation for traditional contract incentives are irrelevant to agile development.\nAs agile thought leader Yoda once put it, \"[You must unlearn what you have learned.](https://www.youtube.com/watch?v=z4jeREy7Pbc)\"\n\nNow this isn't to say that the concept of incentive is totally bad *per se*. If you contract in 6-month release cycles,\nfor example, and the [Definition of Done](https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference)\nincludes doing all the things necessary for a seamless transition to a hypothetical new vendor (*e.g.* good documentation,\nhigh code coverage, *etc.*), the current vendor will be plenty incentivized to do a good job so it can keep working--whether that means\nwinning a re-compete, getting its option picked up, or whatever the contract vehicle specifies.\n\nAnd maybe the contract offers a financial reward if the same vendor makes it all the way from [MVP](http://leanstack.com/minimum-viable-product/)\nto to production release. Kind of like a [Family Feud bonus round](https://www.youtube.com/watch?v=Hm2HdJkgRWI) situation.\n\nThe interesting thing is to figure out how agile contracting comports with the\n[FAR](https://www.acquisition.gov/?q=browsefar). That's what our course for federal acquisition professionals and the\n[TechFAR](https://github.com/usds/playbook/blob/gh-pages/_includes/techfar-online.md) are for.\n\nAs 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.\n\nAnd 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."
}