Joe’s real agile contract

Adela asks: “Please send me some information [on] the details contracts shall contain [for] those projects where the methodology is Agile.”

To talk more clearly, let’s imagine a situation.  Imagine you are a ‘development firm’, ie, in response to external client needs, you develop custom software.

Imagine that the client contacts your firm. He knows and trusts your firm fairly well already.  He has heard of agile, but does not know it well.

You discuss the situation with your main contact and his people.  You explain agile some, and specifically, that you need to develop a product backlog in order to give a price (a budget) and some rough dates. (He needs this rough information to determine if the project is viable.)

The first thing I want is to do is ‘Joe’s Agile Release Planning’ with the client’s people.  I have talked about that a lot on the blog and in my book, Joe’s Agile Release Planning. My summary here:

1. Meet for a day and

• define the Vision
• develop the Product Backlog
• estimate Business Value
• estimate Effort
• calculate the R Factor
• review Risks, Dependencies, Learning, MMFS, and other factors
• Order the Work
• Do the scope/date cut-offs
• Finalize the Day Zero plan

The client may be tempted to spend 2 weeks or 2 months to have a ‘requirements gathering’ phase.  Maybe for a couple of days.  But try to talk them out of it.  (Usually this delay for a 6 month project is not worth the trade-off. Doubtful even for larger projects.)

2. Tell them you will give them a team to do that work.  100% dedicated to doing that work.  He must give you a Product Owner, 100% dedicated to working with that Team. (How dedicated the PO and others at the client might be is subject to some discussion.  For now: maybe not always 100%.)

Explain that the Team will work X hours per week (eg, 40), and have normal vacations and holidays. This will not change. (We will never do a Death March.)

This team has a cost per sprint.  Which you give to the client. (That price includes your profit.)

The client can now see the rough costs for the features in each release on the product backlog. Make sure the client adds in some ‘contingency’ for each release.  Or maybe you should directly add that ‘contingency’ or whatever you call it.

You discuss the conditions under which the people on the Team might change.  The basic idea is that he ‘owns’ (in only a good way) the people on the Team.

You help him understand the magic of the Team.  And that your Team has special magic (assuming it does).

3. You ask the client, “Do the benefit-cost ratios for each release look good to you?”

He will almost always say ‘yes’.  At least for the first few releases.

4. You say, ‘Let’s talk about the Contract.’  At this point you propose that he pay for each sprint on essentially a time and materials basis.  He can change the product backlog at any time (for now, let’s say he cannot change the stories in the sprint, during the sprint).

We will estimate the work in story points.  Since he can see the velocity, and he knows the cost of the team per sprint, he can see the cost per story point.

5. If at any time this does not seem good to him, he can stop.  He must give us X months notice before stopping.  (I will say 2 months. Negotiable.)   When he cancels, we will immediately help him take all the then working product, and help him put that in production if he wants.

6. He only has to pay us for the sprints we work.  He is not locked into a long-term contract. Thus, we have high incentive to be doing the best we can each sprint, to keep him working with us. We have to deliver every sprint.  And our team is 100% dedicated to him, and only his work.

He knows from the past with vendors, that often they would be pulled off his project to work on another project.  So, he likes the 100% dedicated.

7. You explain that our team may need some specialists.  Either from his company or our company.  We will try to give him advance notice of any special skills needed, and their cost (if our people).  In any case, this will also be reviewed on a ‘sprint-ahead’ basis, to assure the team is not stuck.

You also estimate now any known specialist work, and give the client that estimate.

8. Our team will have a 100% dedicated ScrumMaster (assume it is a Team of 7, including their PO and our SM).

Also, 1/4th of the baseline budget of the Team will go into an ‘impediment removal’ fund.  (We have included this already in the price of the Team.)  So that the team has some money to remove impediments.

The client and the Team will discuss how and when this money is spent on removing impediments.  This is not money he can ‘take back’.  But it is money he can help us spend to improve the velocity of the Team.  Including the ‘fun’ of the Team.

Overall, we expect that, with higher innovation and higher productivity, the client will get more business value.

9. You remind the client that success is very dependent on getting good business value information and good detailed requirements information into the team promptly.  You discuss the issues around that.  You explain the importance of the PO he is providing.

10. You explain the value to him of the inherent adaptability built into this contract.  And how it minimizes his risks.  And gives us an incentive to optimize his values (early release, high business value, only do the essential things, adapt to change).

Then you ask: “Does that sound like a fair contract?”

***

Note: For some readers, the contract described above may appear to be impossible or totally unrealistic. And, for your clients, it may be. But be aware that other firms and other clients are indeed doing contracts on essentially this basis.  You can too, with enough learning, enough discussion, and enough trust.

 

« « Scaling Workshop Montreal || Impediments – Charlotte in-house course » »