Get certified - Transform your world of work today

What an Agile Contract Looks Like

Do's and don’ts before you sign your name on the dotted line

05/13/2015 by Andrew Lin

Congratulations! You just got a project to build a new product. It is new (well, any project by definition is unique, so it is new by default) and something you've never done before. You don't have the talent on your team now, and you need to find and work with an outside consulting firm. You did your due diligence, you checked their references, you spoke with their team, and they told you they're doing all their projects using Agile/Scrum. And you're thinking, "That sounds good -- hopefully it's not too good to be true, because if it's too good to be true, it's probably not true." Next thing you know, there is a Statement of Work and/or contract for you to sign.

So here is the question: How do you know the consulting firm is really running Agile/Scrum? Not Waterfall or Water-Scrum-Fall or Scrum-But?

An Agile contract should -- or should not -- have the following attributes (this is for your reference only and hopefully will help get you started):

  • It should not be a contract with the total price of X amount of dollars for the whole project to be delivered in X months/years. This would be a very clear sign of that you are about to sign a contract for a Waterfall project. It doesn't matter how much "planning" or how many "requirements" you do before or after you sign the contract -- you know the requirements will be changing and you will get change orders all the time. And if you sign a contract for the whole project with a fixed amount of dollars (cost), fixed length (time), and big requirements (scope), then it doesn't matter what you call it: It is a Waterfall project.
  • It should have several releases and iterations, which means several contracts. You get something done, you sign the next one, work on it, get more done, and then on to the next.
  • Make sure it's your project, not the consultants' project. Actually it's not your project; it's the Scrum team's project, and everyone on the Scrum team is accountable for its outcome.
  • Make sure the consultants participate in your Scrum events (release planning, sprint planning, Daily Scrum, sprint review, and sprint retrospective), or you participate in their Scrum events. If they are remote, ask if they can be on site. If not, turn on that webcam (yours and theirs) and leave it on all the time, so you can collaborate with them all the time. It may look a bit weird in the beginning, but it really helps.
  • Pay attention to details. If something goes wrong, who is responsible for what in the contract? We understand "customer collaboration over contract negotiation," so simplify the contract. The contract itself doesn't provide values, any activity that doesn't provide value is a waste, and any waste is a crime. So minimize your resources on this activity. However, you do need to pay attention to details. You don't want to end up in arbitration because of a failed project.
  • Make sure you add "money for nothing, change is free" to the contract. This concept is from Jeff Sutherland. "Money for nothing" means stop the development when the cost exceeds the values it will bring, because developing 45 percent of the features that no one will use is a waste. "Change is free" means you should be able to swap product backlog items (PBIs) if they have the same points. This allows changes between you and the consulting firm, and we all know that "responding to change over following a plan" is one of the Agile values.
  • If you see something like "no change is allowed unless a written change order is signed by both parties" in the contract, you know it's a Waterfall contract.
  • Be careful with any contract that says it's going to take six months or longer. The contract should follow the release, which is usually three months. If the team does not produce any working software after three months, there is something really wrong and you need to stop and inspect. You should inspect daily and make sure you're building increments every sprint.
  • If your consultants give you a Gantt chart, you should run away. If they use Post-its, that's better.
  • Ask the consultants to be onsite/colocated with your team if possible. If not, ask for one or two weeks every month.
  • If you work with more than one consulting firm (for example, design is firm A, development is firm B), make sure everything you do -- all Scrum events, all the communication and collaboration -- involves everyone.
  • Consultants and your team should be able to work like one team together. Make sure you review the consultants' resumes, LinkedIn profiles, etc. Do they have the skill sets and Agile mind-set? Have they worked on Scrum projects before?
  • Write your requirements using user story format and estimate them using story points. If the consulting firm is trying to capture all the requirements with all the details on them in the first month or so, then you know this is a Waterfall project. Standardizing the requirements using user story format will help a lot, especially if you have hundreds of items later.
  • Come up with the MVP (minimum viable product) and work on this first. Don't try to do everything, don't try to build the 45 percent of the features that no one will use. And to have a good MVP requires a good product owner.
It will also be helpful to know that you don't need to use Agile/Scrum for every project. According to Dave Snowden's Cynefin framework, if your project falls under the "Obvious" or "Complicated" domain, your approach will be "Sense - Categorize - Respond" or "Sense - Analyze - Respond" and you can follow PMBOK to plan your project.

If your project is "Complex," which means it's dynamic and changing, then using Scrum may be your best option.

Scrum takes two days to learn, 10,000 hours of practice to be a master, and a lifetime to be a sensei. Scrum is not a silver bullet, but with best practices and shared knowledge, it will reduce your risk. Remember: Keep calm, be Agile, and do Scrum. It's going to be great.