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 and a hard question.  I will answer it quickly here. Too quickly.  I have partly answered it in my book, Joe’s 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. And to know everything in advance.  And, while we all forever 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 (the work) is about what one Team can do in 6 months.

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

The Team (including the right ‘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. Roughly all that work divided into about 50 stories.  Not to 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.
4. Identify the Effort for each story.  Using planning poker. Again, using the right people for this (namely, the people who will do the real 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, Min 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 buffer (aka padding, contingency, etc.)
10. Identify the ‘fix it plan’ to fix the biggest imperfections in the plan first.
11. Start ‘release plan refactoring’ — where we refactor the release plan every sprint based on new learning.

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

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. And 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 we guess at the buffer or 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 better 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.