Build trust: Time-and-Materials Contracts in Lean-Agile software development

What about contracts?

You’re probably wondering this if you’ve read through any of the posts from our Lean-Agile series.

With the growing complexity of software and devices, coupled with available engineering talent being stretched in many countries, a lot of companies look to outsource software development. But in defining that relationship between customer and supplier, client and vendor, the wrong contract can stifle the ability to work in a Lean-Agile way.

(As a business, we’ve changed our contracts to what we describe in this post, with the help of our lawyers. But we’re not lawyers and you should always check with your legal experts before changing the contracts you use with vendors.)

In this blog post, find out how Time-and-Materials Contracts lead to better working relationships when you’re Lean-Agile. Plus, why Fixed-Price Contracts still leave clients with all the risk.

In the left corner: Fixed-Priced (and Scope) Contracts

When it comes to suppliers, contracts are one of the central points in that relationship. For many organisations, contracts with vendors define every element of that business relationship—despite how strategic the relationship might be. From basic components to outsourcing highly sought after technical output—a Fixed-Price Contract is often in place.

But not all supplier relationships can be appropriately covered by a Fixed-Price Contract. Certainly not the relationship involving a supplier offering an outsourced technical output. An output that needs open discussions, sharing of information and close collaboration to succeed.

Still, it’s understandable why organisations try to make contracts so confining and why they also can’t imagine working in an Agile way, let alone Lean-Agile. As Mary and Tom Poppendieck explain in their book Lean Software Development:

“Without doubt, the biggest barrier to using agile practises is the sharp line between one firm and another. Each firm is expected to look out for its own shared interests, with the understanding that the other firm will be doing the same thing.”¹

Contracts must be “airtight” to ensure all eventualities are covered for on both sides of the contract. Risk often ends up with the vendor, despite the contract probably not being the best place to set out those risks (more on that later).

Though as Mary and Tom point out:

“In practice, the customer can’t really transfer the bulk of the risk. If the contract doesn’t work out, the customer will suffer.”²

If we look at that quote—and the follow the same logic—a theme does emerge. It seems simple but on examination, it’s incredibly complex:

Trust.

The not so Lean-Agile way to think about contracts a.k.a. we’re not buying pencils here, but we will act like we are a.k.a. we’re not building trust and collaboration

Sam’s team at Hyper-Mega-Corp Z is working on a new product. This time round, because of the technical quirks in the latest product, Sam’s team needs to enlist an external team of software specialists to collaborate with.

Outsourcing wasn’t Sam’s first pick but having looked at the expected timeline for the project, they didn’t have a choice. There was limited possibility of them recruiting the right people with the skills they needed to keep the project in-house.

Sam and Hyper-Mega-Corp Z negotiate a Fixed-Price Contract with Max from Outsourced Corp C to help with the software. The team at Outsourced Corp C had come in with the lowest estimate. The contract set out everything about the relationship between the two companies, leaving little room for compromise.

While work initially went smoothly, months in Sam started to get worried when project milestones for software started being missed. Sam tried to talk to Max about it, but Max didn’t have much incentive to talk about what was happening at Outsourced Corp C. The contract made sure of this.

And then when the software started coming their way, the changes needed were many and expensive. Suddenly Sam was seeing how it was that Outsourced Corp C had come in with such a low estimate for a low quality service. They made their money on changes.

It was too late to switch to another vendor.

Could this have been helped with a different kind of contract? A different way of working together?

When are Fixed-Price Contracts helpful?

There is a place for Fixed-Price Contracts, when a “arm’s-length relationship” is more appropriate. Jeffrey H. Dyer (who Mary and Tom draw on for their section on contracts) is clear on how to identify when you need Fixed-Price Contract. His book Collaborative Advantage considered how Toyota and Chrysler found ways of working with their vendors that led to them having a huge competitive advantage over other US car manufacturers for a time.

Jeffrey saw a place for Fixed-Price Contracts in manufacturing, explaining that the arm’s-length relationship created by this type of contract works best when:

• There are low value inputs
• Products are homogeneous and “open architecture”
• There is “a low degree of supplier-buyer interdependence”³

To help ensure the success of a technical product, which demands high value inputs from all sides, the above aspects are inappropriate building blocks for underpinning the business relationship.

In software, consider the difference between choosing a Software as a Service (SaaS) provider for an “off the shelf” application versus an outsourced bespoke offering. The SaaS offering with limited customisation is suited to a Fixed-Price Contract, whereas as the bespoke application with ongoing development would benefit from a more flexible approach.

As Jeffrey H. discovered in his research:

“In addition to lowering transaction costs, trust has a profound influence on information sharing in supplier-buyer relationships.”⁴

And if we’re to put our Lean-Agile hat on more firmly here: it doesn’t sound like quality is being built in.

When quality isn’t allowed to slip

If you recall in our earlier post, quality is a key part of the Lean-Agile way of working. Mary and Tom frame quality as a key principle in Lean-Agile, as part of “build integrity in”. It is understood as perceived integrity and conceptual integrity:

• Perceived integrity involves the elements of the software or product that the end-user sees and interacts with. It includes the display and user interface that they engage with, and how it feels to use it.
• Conceptual integrity includes the elements that are going on beneath, the things the user will never see or engage with (those technical, code parts only software engineers ever see).⁵

Conceptual integrity is key

But, as we discussed in our previous post, conceptual integrity cannot be skimped on. It is at the root of any product, ensuring the whole functions in both the short and long-term. Gamble with it and you risk creating waste and failing to build in integrity overall.

Traditional contracts and quality in intricate projects don’t go well together…

… But Lean-Agile and quality do.

Let’s think for a moment about some of the core elements most contracts are trying to pin down.

Consider the Iron Triangle

When we think about most Iron Triangles, it looks at three constraints behind most projects, with quality limply sitting in the middle:

A Fixed-Price Contract will attempt to pin down scope, cost or time. Quality is included, but without the understanding of how the other three will affect it—it ignores the problems that come up again and again in multifaceted projects.

In engineering for intricate projects, you don’t know your unknown unknowns. These can range from hardware and software challenges to the motivations of stakeholders. Without the room to adapt to these as the unknowns become known, quality suffers, waste is created, and the Iron Triangle is suddenly no more.

To work in a Lean-Agile way where:

• Quality isn’t compromised
• Customer and vendor are aiming for zero waste
• Trust is rooted deeply
• Adaptation is possible

You’ll need a different kind of contract.

In the right corner: Time-and-Materials Contracts…

… Done in a Lean-Agile way. Here the contract is concerned with time and the materials used.

Time-and-Materials shifts the bulk of the risk from the vendor back to the customer and would seem like it could create a situation again where “self-serving [behaviour]”⁶ can happen. That the contract will make “the customer dependent on the vendor”⁷. But when you apply Lean-Agile to all of this, things become far more tolerable for the customer, and in the long run it becomes the lowest risk option. Here’s how.

Agile/Lean-Agile leads to a position where the vendor is always delivering value to the customer and the customer is no longer held prisoner by the contract. The onus falls to the vendor to continually deliver value throughout the project. Because software development and testing are done in short sprints (two to four weeks), the vendor will always have something of value to show for the money spent—an iteration of the project. Iterating over short timeframes works, as long as the customer is clear (at the start of a sprint) what the most valuable features are that the vendor can deliver in that time. And “there must be ongoing collaboration” between all parties.⁸

All this is about enabling trust and communication—using techniques like Three Amigos, retrospectives, Kanban, demos and other Lean-Agile tools and practices. This facilitates transparency and short feedback loops, halting problems before waste can happen and quality starts to slip. Meaning vendors and customers—stakeholders and all—are working together.

So, what should a Lean-Agile, Time-and-Materials Contract do?

Here the contract has the flexibility to deal with those unknown unknowns. The contract and accompanying documents should look to enable Lean-Agile working practices.

In fact, the main contract should aim to control a subset of concerns of a more traditional contract:

• Intellectual Property
• Payment terms
• Responsibilities for compliance (and similar legal issues)

And instead you should build a new, trusting, quality focused relationship using alternative agreements, such as:

• A risk register
• Project management practices
• A Quality Agreement

Each of these encourages collaboration between the customer and the vendor when issues arise. When that Iron Triangle has fallen over, you talk.

Build trust and put quality first

It takes time for client-supplier relationships to develop. But taking practical steps to ensure that all parties are on the same page and can work together is a step in the right direction.

Check out our further reading section, below, for more advice on how you can make your projects more Lean-Agile.

References

¹ Mary Poppendieck, Tom Poppendieck, Lean Software Development: An Agile Toolkit (Crawfordsville, Indiana: Addison Wesley, 2003), p. 161.

² Mary Poppendieck, Tom Poppendieck, Lean Software Development, p. 166.

³ Jeffrey H. Dyer, Collaborative Advantage: Winning Through Extended Enterprise Supplier Networks (New York: Oxford University Press, 2000), p. 19.

⁴ Jeffrey H. Dyer, Collaborative Advantage, p. 96.

⁵ Mary Poppendieck, Tom Poppendieck, Lean Software Development, p.125.

⁶ Mary Poppendieck, Tom Poppendieck, Lean Software Development, p.167.

⁷ Mary Poppendieck, Tom Poppendieck, Lean Software Development, p.168.

⁸ Mary Poppendieck, Tom Poppendieck, Lean Software Development, p.168.