Who would want to admit that they are not agile? Not startup CEOs, nor corporate CEOs. In the rush to total digitization, everything from corporate strategy to food service contracts is now expected to be “agile”, able to respond rapidly to customers and disruptive competitors alike.
While much is made of why agile practices are worthy (see our previous Agile Practices: Keep This, Spike That post), relatively little is said about how to write a contract for agile development services.
Here’s my cheat-sheet for helping your lawyer craft an agreement that improves productivity, quality, time to market, value realization, all with better governance and working relationships.
The Problem with Lawyers, Business Executives and Agile
Both your lawyer and your software supplier have something in common: They are both representing your interests as their client. For a practicing lawyer, that’s a professional obligation, and why they need to be members of the Bar.
For an agile services supplier, it’s a bit more complicated, which is where good agile contracting practices come in.
Lawyers are trained to use the law to protect your firm from contractual risks of all types. Surprisingly, most lawyers have little interest in the business goal of a contract, especially in large corporations. (Why? Because they are not evaluated on business outcomes, just whether they protected the firm when something goes wrong.)
Business executives are very concerned with business outcomes, but they prefer to get their desired outcome by shifting risk to suppliers. After all, the software suppliers are the experts in their field — right? So get competitive bids, drive down acquisition costs, and sue the bastards if they screw up.
Both lawyers and business executives are therefore inclined to want contracts with:
- fixed scope
- fixed price
- fixed schedules
- competitive bidding
- tough penalties for underperformance
The fixed scope/fixed price contract mindset is squarely at odds with agile/lean principles. Contracts that enforce static outputs are more likely to result in poor software, or projects that never complete. And punitive terms only encourage ass-covering while diminishing trust. Building software is not like building an apartment building.
Teaching Lawyers and Business Execs Agile/Lean
Agile methods were created with the understanding that software projects are necessarily a collaborative learning experience for both client and supplier. Firms need to accept that good software is the result of highly effective communications and collaboration, and that many traditional hard negotiating tactics are likely to result in poor software and higher costs. Scope almost always changes during software projects. For agile methods to work, firms need to accept that software requirements (i.e., scope) will be volatile.
If your lawyer is new to the agile software business, have your lawyer visit www.agilecontracts.org, a site is written by lawyers for lawyers.
Agile Development Contract Goals
The goal of an agile contract is a successful project. That doesn’t mean other legal issues are not important, they are. But the project’s success is paramount.
A recent McKinsey article on IT sourcing [https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/five-ways-to-unlock-win-win-value-from-it-services-sourcing-relationships] rightly identifies “win/win” contracting as essential to modern software & digitization efforts. When trust and collaboration are essential and change is inevitable, services contracts must encourage all parties to share in the gain — and the pain.
As a general rule, customers should bear the risk of “what” software is being built, and suppliers the risk of “how” it is being built.
Best practice #1: Separate Business Risk from Software Work
Most of the concerns your lawyer will have do not not relate directly to software development. Put all these concerns (data protections, intellectual property, liability, termination, etc.) in a single Master Services Agreement, which then refers to Statements of Work.
This approach has the benefit of limiting legal involvement (and hourly lawyer bills) to the issues they are best trained for, while software work statements are addressed to the technical manager best trained to oversee software projects.
Best practice #2: Define Scope at a High Level
The agile process itself is designed for continuous definition of requirements and artifacts per sprint. Any scope language in a Statement of Work should stick to the big stuff. Course corrections are built into the agile process.
Change control in contracts is always a fraught subject, and expensive to administer, so stick to scope statements where big fundamental changes will be obvious, and not quibbled over. Two examples:
- A scope statement should not specify visual design specifics or any aspect of a user interface, except in general terms — e.g., the software needs to operate on IOS and a web site.
- A scope statement should say a software product is going to be sold B2B, because a change to B2C brings on a whole host of changes in business model and non-functional requirements.
Best practice #3: Emphasize Delivery Process Not Detailed Deliverables
Long lists of detailed deliverables are counterproductive. They imply that all important artifacts can be known in advance, instead of encouraging the development teams to collaborate and define the best, most efficient means to deliver software.
Put your efforts into defining your delivery process within the Statement of Work. Specify the parameters of your preferred sprint, scrum and other agile practices, such as the length of your sprints. Play particular attention to the roles and responsibilities of scrum masters, architects and other participants will contribute.
Above all, take the Product Owner role seriously. (If you don’t understand why this role is so important, then you should not be attempting agile development in the first place.)
Emphasizing process over deliverables keeps your team’s mindset collaborative and forward looking. Discuss what requirements, documents and other artifacts will get you great software. Make your contract management as close to agile project management as possible.
Best practice #4: Define Acceptance at a High Level
The original agile goal of “always have working, shippable software” is unworkable except for trivially small software projects. You cannot afford to perform contractual acceptance at the end of every sprint.
In general, your Statement of Work has three choices when defining Acceptance:
- Use the agile team’s definition of “done” at the project’s onset in the first sprint;
- Incrementally and collaboratively evolve “done” along the way;
- Time box the acceptance period by the customer, and the repair period by the supplier.
Again, you need to trust a good process to get you good results, not the contract.
Best practice #5: Time and Materials, Not Fixed Price
Fixed price contracting is largely incompatible with agile because it encourages suppliers to watch their wallet, not their team’s performance. There are better ways to control costs:
- T&M capped — set a limit, and have the team manage scope to that overall budget target
- T&M capped per sprint or release — finer control, but more overhead
If you are the client, pay promptly, except in cases of gross malfeasance. You don’t want your supplier watching his wallet.
Best practice #6: Sharing the Gain and any Pain
Collaboration and trust is enhanced when both client and supplier share rewards. Most customers want to retain all the profits from their software, and not share the upside, but bonuses for hitting milestones can be effective. Startups may grant some equity options in exchange for discounts, if they value their cash burn more than their equity.
Customers need to realize that some people issues come with the territory. Great software is the result of high-functioning teams, so suppliers should make it easy for their customers to reject resources that are not performing to expectations and receive a refund.
Some larger firms use vendor management systems that require transparency supplier profits. That may make sense for staff augmentation needs, but not high functioning agile teams. Anyone familiar with military cost-plus contracting knows how these systems can be gamed, with horrendous accounting overhead and $100,000 toilet seats.
Best practice #7: Go Easy on Downside Protections
- Termination: Should be easy for clients to cancel contracts with relatively short notice. Keeps a supplier on his toes and laser-focused on customer satisfaction. Protects firms when business conditions change beyond their control.
- Liability: The more onerous, the more incentive to ass-covering by suppliers. LImit to gross negligence.
- Warranty: See liability. Should only be required for unprofessional behavior and efforts, insertion of unauthorized code, etc.
- Intellectual Property: Customers should insist on work-for-hire, and suppliers should recognize their role is a builder of IP, not an owner. Exceptions can be made for certain share the gain/pain scenarios (e.g., revenue sharing).
- Non disclosure: Just go with standard stuff; the Apple “cone of NDA silence” approach with constant threat of litigation conflicts with open discussion, collaboration, trust, etc.
- Insurance: Very reasonable to require your supplier to insure the behavior of their resources. In regulated industries, insurance against financial malfeasance and cyber risks is often justified.
Concluding Best practice #8: Contracts Don’t Create Trust: People do
The degree of collaboration required for good software development puts a huge premium on compatibility. Clients and suppliers need to develop trust in each other, which takes time and effort.
Both parties should plan to build and develop trust at a human level, which takes time. Don’t fall in love instantly, take the time to “date” your potential supplier and build that necessary foundation. The size or industry stature of a supplier may be irrelevant when it comes to your particular project if the people involved just cannot get along.