Agile Contracts- How changing the way you work with vendors can streamline your development

Apr 5, 2019

Despite these difficulties, most companies feel compelled to hire these Waterfall-oriented vendors because vendors have better expertise in a technology, process, or application. Companies invest in and trust the vendor to build the right things.

Those of you who have survived a SAFe^® Transformation may also be thinking that vendor selection meets all three characteristics of a centralized decision, according to Scaled Agile.

• Infrequent decisions that may require deeper consideration
• Long-lasting decisions that are unlikely to change
• Expensive decisions that involve large amounts of money or time

You don’t hire vendors very often, and you hire them for large initiatives that take a long time and cost a lot of money.

But if your company is going to invest in building the right things at the right time, then even with a centralized selection process, you should consider decentralizing your vendor management processes. Let your vendor worry about the details, while you maintain your product vision and ensure that your future development addresses your business needs.

If your company is operating in an Agile fashion, why would you continue to use a process that is decidedly un-Agile (infrequent, long-lasting, and expensive)? How do you manage agile requirements when you create a fixed-price contract that has clearly defined deliverables and a six-month timeline? The answer is: you don’t. Sure, you can break up the deliverables into Epics, Features, and User Stories; but, at the end of the day, you’re still operating against a fixed-date and won’t be able to respond to the instability in the development process, leading to long hours, missed deadlines, and delivering over-budget. Not only that, but there are many initiatives that will eventually demand significant changes such as changing scope, dates, or even changing the vendor themselves. If you’re on a fixed-price contract, you won’t be able to do anything about it.

Since it doesn’t make sense to deliver a fixed-date fixed-price contract in an Agile environment, we can look to another type of contract for inspiration: Time and Materials. A T&M contract is used when a vendor is paid on the basis of actual labor, cost of materials, and overhead. If you’ve ever had to renovate your home, or even just had a plumbing emergency, you’re probably intimately familiar with a T&M contract. But you might be wondering— how could this possibly apply to a technology vendor? Well, start by thinking about how you could pay a vendor based on actual labor rather than fixed-price. There are three approaches you could take:

• Pay by the hour
• Pay by the story point
• Pay by the sprint

Some immediate gains you would realize with any of the approaches listed above are:

• Increased control over your design – you can change your requirements at any time because the contract doesn’t stop you. As long as the cost is justifiable, fire away.
• Increased control over project cost – By not committing to a price upfront, you can pivot or streamline as needed. You may even be able to funnel your cost into the highest performers for a longer period of time, rather than distributing it across many others.
• Iterative development – The flexibility gained by having your vendor deliver functioning software that can be measured against every sprint is invaluable. Not only do you get working software that is an objective measure of progress towards your goals, but also your vendor has the opportunity to prove their value every two weeks. If they’re not measuring up, you have the flexibility to go to someone else.
• Small commitments – When you sign a contract for X hours/points/sprints rather than a fixed scope, you can manage your work much more efficiently because you have natural points at which you can pivot. Additionally, if your commitments are small enough, you may not need to go through a formal RFP process. Think about how much more quickly you can respond to changing market conditions if you don’t have to go through your own internal legal or purchasing processes.

One thing to note is that for any of these approaches to be truly successful, you need to have a highly collaborative relationship between the hiring organization and the vendor. Any of these metrics can be inflated, “my team does 30 stories a sprint and they’re all 20 points.” As long as no decisions are being made in a silo, and both parties are present and engaged in the agile process, you will be protected from artificial inflation.

Additionally, If you structure your contract so that you pay by the story point or by the sprint, you’ll realize an additional benefit:

• Increased control over quality – Given that in Agile, you only get credit when work has been accepted, you will only pay for the work that has been completed to the quality your Product Owner expected. Otherwise the work has not been accepted and will not be counted.

You may be thinking that this all sounds good, but how do you actually write an Agile contract? Your primary goal is to structure your contract so that you pay based on the amount of work actually delivered; however, there are other things you want to keep in mind when you are writing your contract as well. The point of an Agile contract is not to list out the requirements and specific deliverables, but rather to help define the working relationship between the client and the vendor. You may recognize this concept as similar to a team creating a working agreement. You want to not only define the relationship, but also ensure that the contract includes adequate protection and risk management strategies for both parties.

If you can embrace these guidelines, ensuring that both you and your vendor understand how you will work together, what metrics and measures you will use to assess project health, and how your monetary relationship will be tied to objective progress, you will be in a strong position to deliver your projects on time, under budget, and with minimal disruptions.

I know I’d like to be running that relationship.

Written by Saahil Panikar , SPCT

 

Saahil has been a leader in transforming organizations and teams by helping them master Agile and Scaled Agile best practices for over 10 years. He is a passionate Agilist whose thirst for continuous improvement led him to his first Agile Transformation in 2013 and has caused him to push the envelope ever since. He has experience working with large-scale Agile initiatives in a variety of contexts. He has worked with start-ups and small businesses, the Federal Government, and Fortune 100 companies.

 

More…