Recommendations for an Agile contract

The following thoughts are based on my own experience working both as a supplier and as a customer of external development services.

Artwork courtesy of Laura Quattri. Used by Permission

Good Product Ownership is Essential

An effective Product Owner can dramatically reduce the risk of a project and increase your chances of success with your new product. A Product Owner is a decision-maker, so this almost always means the Product Owner has to work for the customer, not the supplier.

If you are contracting with an external supplier for software development, Scrum is a good choice for managing the process, if – and this is a big if – the customer supplies an effective Product Owner who engages and collaborates with the rest of the Scrum Team.

Learn to be a good Product Owner. Product Owner classes teach you how to manage the backlog, how to formulate and refine requirements, how to define and refine acceptance criteria, how to reduce the risk of the project, how to work with the team in the before, during and after each sprint. In short, it gives you the skills you need to lead a development project.

Each Development Team’s First Milestone

I have worked quite happily for years with a phased development contract. The original contract was a fixed scope contract with cost ceiling, but as we worked together and built up the level of trust, the surrounding text just withered away. Trust, a bit of boilerplate, the sprint contract and a quarterly sign-off from top management worked quite nicely.

If the team can deliver reliably every sprint, and given that the cost per sprint is fixed, then you can predict both your release dates and the total cost months in advance. The scope is defined on route, so you don’t know “exactly” what you are going to get. Too much pressure to deliver in a short time frame is usually counterproductive.

How to get the right scope quickly

“Money for nothing, changes for free” contracts can turn the advantages of the Scrum and Agile development processes into a competitive advantage.

By prioritizing and delivering business value incrementally, the chances of an outright failure are dramatically reduced. This advantage is passed on to the customer.

Furthermore, it’s a cooperative model, so it offers incentives to both parties to keep the costs down.
The early cancellation clause rewards the higher productivity achieved with Scrum teams. On the down side, this clause feels a bit like a ‘golden parachute’ which may not be politically acceptable.

This contract might work with a cost ceiling although I would be wary of losing the cooperative relationship.

The contract form lays the important groundwork for a successful project. And the Agile Manifesto got it right: working with the customer is more important than the contract. Whatever you do, keep the customer relationship positive!

Should you condition payment on the results of individual sprints?

Should you pay the supplier more if the Team delivers more? And less if they deliver less? In general, I don’t recommend it.

This approach encourages valuing quantity over quality. It encourages the Team to settle at a ,performance level that they can comfortably achieve. And if the Team does have a sprint that doesn’t produce any working functionality as a result, they may not be able to withstand the economic hardship it produces, especially if the loss is passed on to the individual members.

Suggestions for a Scrum Contract

Scrum is modeled on successful patterns of product development. Based on my experience working on both sides of the agreement, I would suggest addressing the following points to ensure that Scrum works as intended:

Scope

Define the purpose and goals of the project, leave the details to the “sprint contract.”

Respect for the Sprint Contract: Unless the Product Owner exercises their authority to cancel a sprint, no changes to the goal or team composition during the sprint without agreement among all members of the Scrum Team.

Roles

Product Owner: Provided by the customer. Having the supplier provide the Product Owner (“because no one on the customer side has the time or knowledge”) is extremely dysfunctional. Only the customer has decision-making authority.

Ensure the Product Owner’s authority as a decision maker in the project, including having the final say whether something is done and accepted; confirm that they have enough capacity to support the team; and are able to perform regular, extended visits to the supplier’s site. Extensive face to face collaboration between the Product Owner and the offshore Development Team is a success pattern.

Development Team Members: Provided by the supplier. The Development Team needs all the skills necessary to create a finished increment (a “feature team”) and does not take instructions from anybody but the Product Owner through the sprint planning process.

Scrum Master: Provided by the supplier. Having the customer provide the Scrum Master (“to maintain control”) is extremely dysfunctional. Who would protect the Development Team from an overzealous Product Owner or ensure that the Customer fulfills their responsibilities?

Chief Impediment Removal Officer: This role, which is not a role that Scrum defines, represents an independent communication channel between the Scrum Master and the customer. This person takes responsibility for resolving impediments that cannot be addressed by the Product Owner or the Scrum Master alone.

This is not about escalation. This is about ensuring that impediments get addressed and to prevent actual escalations.

Events

Sprint Reviews: Occur once per sprint and are attended by the Scrum Team and the stakeholders. It may be desirable to name key stakeholders who must also be present.

Deliverables: At least once per sprint, a potentially shippable product increment must be produced by the Team and made available to the customer. Nothing may be included in the product increment unless it is done according to the definition of done as defined by the Scrum Team.

Spending authorization: How much money may be spent over what period of time?

Termination: What to do if the team achieves a viable product before the budget is exhausted. What to do if the customer wishes to cancel or prolong the project. How much notice is required to cancel the development work?