Agile Contracts – Question 1

Adela asks this question: Imagine we have a brand new project. And we must bid on it, and we want to use the agile-scrum method.  How should that work?

This is a good question.  I will answer it quickly here. Too quickly.  I have partly answered it in my book, Agile Release Planning. And partly elsewhere.

Why is it a hard question?  Because business and life itself wants us to do what is impossible: to perfectly predict the future. Also to know everything in advance.  While we will wish those two statements were true (well, at least part of each of us will), they never will be true.

So, let’s make the case fairly simple.  Imagine that the project is what one Team can complete in 6 months.

I recommend Agile Release Planning (as explained fully in my book).

The Team (including the ‘business stakeholders’ or SMEs or customer reps or whatever you call them) do the following:

1. Clarify the vision. Quickly.
2. Build the product backlog in user story format, divided into roughly 50 stories.  Not too large, not too small.
3. Identify Business Value on each story.  Via priority poker. Using the best BV people we can find (about 5 of them).  In about 1 hour or so.
4. Identify the Effort for each story.  Using planning poker. Again, using the right people for this (namely, those who will do the work).
5. Identify the R Factor (BVP/SP) for each story.  Make the benefit-cost ratios more explicit.  Order the work now by R Factor.
6. Consider Risks, Dependencies, Learning, Minimum Marketable Feature Set, and other issues. Re-order the work as needed.
7. Do the scope-date trade-offs. In other words, identify the ‘release’ cut-offs.
8. Estimate the velocity of the team and identify when each release will happen.
9. Do a communications ‘plan’ and add appropriate contingency (aka padding, buffer, etc.)
10. Identify the ‘fix it plan’ to fix the biggest imperfections in the plan, starting tomorrow.

OK, let’s imagine further that the client asks for a fixed price.  After Step 10, we have to give a price to the external customer.

Well, let me modify that. After Step 10, you have a plan, and you can see the problems with the plan.  You must decide how much time (work) you will give yourself to make the plan better.  Maybe a few days, a week, maybe longer.  But then you must give a ‘quote’ (as it is often called) or proposal.

Now, the first time you do Agile Release Planning, I think you will get a better (slightly more accurate) scope-date-budget than you do using your current method.  Still, for the first or second time, I do recommend doing it both ways, comparing the results, and learning from that.

By the third time, I predict that you will be happier with this agile approach than your current approach.

Will the agile approach on day zero ever be ‘perfect’?  No.

Always include a guess at the contingency (buffer, padding). And always that guess can be too much (not a big problem if the customer agrees) or too little (a big problem if it causes us to go bankrupt). Notice that we as a vendor are biased to want to win contracts, and hence often ‘close our eyes’ and go with too little ‘padding’.  Often.

In any case, once we get a signed contract, I recommend running the project in an agile way.  Again, this cannot guarantee success, but it will enable us to manage the effort to success (or a lower loss).

That’s the summary of my answer in one short blog post. I am sure I left many questions unanswered.

 

« « What if Scrum is not working for you? || Agile Contracts » »