Skip to main content

Recommendations for an Agile contract

A contract manages some risks but not all of them. More importantly, the contract defines the playing rules, which in turn drive people's behavior.  What would you like to have in a contract? Conditions that encourage behaviors that lead to project success.

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

The first goal is to deliver reliably every sprint. If the Team can produce something that works and could be shipped every sprint, most risks go away. It is not about how much they deliver. It is about delivering in production quality something that could be shipped. It might take the Team a few sprints to be able to do this reliably, because it is not easy. This objective might be something you want to define in the contract.

Fixed-Price is easy to achieve, if...

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, Scrum Master, and Development Team (collectively the “Scrum Team”) as defined by the Scrum Guide. Define who will serve in each role.

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?

You can get the whole book now, or you can read it a chapter at a time as I publish it here under the label ten contracts. To download the e-book or pre-order the physical book visit https://saat-network.ch/ten


Comments

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …