Scrum and Tenders - do they mix?

Hi Dave,
first I see your situation positively, because you and your vendors agree on the way you want to collaborate.
Reacting to changes is more important than a contract, as you know. However a contract is still important.
A good practice for this situation is the following (known as agile fix bid):
You start with your partly defined Product Backlog.
Your vendors do a relative estimation for the items (where possible).
They choose one item and do all the refinement work for it. They decompose it, estimate it in hours (this compromise is needed for the following) and dollarize it.
Now they extrapolate their estimate to the whole Product Backlog and have a number for bidding.
When you set up the contract, you add two paragraphs (known as money for nothing and changes for free):
1. You (as the customer) can cancel the project at the end of any sprint for any reason. In this case, you only pay half of the remaining budget.
2. You (as the customer) can remove items from the backlog and replace them by items of the same size. You can do that at any time, as long the items are not yet in progress.
I hope you will share your experience with us.
Best, Ludwig

We're currently exploring the same, we use to conduct most of this work internally, but as this is quite big its been put out to tender. At the first they took a very traditional waterfall approach to this, and wrote something called the "Functional Performance Specification", which is basically a requirements document we'd give to a company to formulate their bid. This has got pretty ugly and I've been asked to try and look at reducing it to something a bit more transparent. It currently stands at 90ish pages!

Because I work in a public sector organisation, we do have to produce a certain level of documents to meet our standardisation. Our feeling is that we'd do the bare minimum and represent out requirements as a series of "Epics", we'd be hoping to embed some of our software engineers into the organisation that wins the tender to provide support.

I'd be curious to hear how you get along at at finding a bidders as a lot like your organisation our tender process is pretty set in stone. Keep us updated!

Cheers,

Greg

> Here's my question, how can I get or expect
> to get agile bidders to provide a quote when
> the tender process is set up for companies
> who set phases and cost per phase (even
> though these aren't likely to be realistic)? 

I expect you'll get quotes, but they'll be from bidders who know the fixed-bid system and how to milk it in terms of Change Requests. A supplier can double or triple their quoted commercials through CR's.

Are you aware of this, and is there enough of a budget to finance the CR's when they arise?

Thanks for your responses.

Greg touches well on the issues I'm having - I'm working in a public sector environment and tender process is set in stone. Ian - thanks for the reply, i'm more than happy with change, that's the whole idea of product backlogs so no issues with that. This is going to be a fluid project which is why I've said scope is not set in stone. You mentioned fixed price tender - this isn't fixed price, we're expecting bidders to quote which is where my problems arise.

Let me re-phrase the issue:
1) Tender process is set in stone and can't be changed - bidders expected to provide a quote for work - this isn't a fixed price tender
2) We expect scope and requirements to change, so the specification gives some ideas as to what we want, but part of the requirement to is assist in speccing out work
3) I'm aware that whatever is quoted cannot be particularly accurate as we haven't given fixed requirements as we expect requirements to evolve. However, a waterfall supplier can simply quote £x for requirements, £x for dev, £x for testing, etc.
4) Agile works best when you can get a price per sprint, or a price for a set number of sprints - this allows scope to change in the backlog, however....
5) We CANNOT accept a tender response that quotes either £x per sprint, or £x for a total amount of sprints. The tender process means that a supplier has to break down actual costs (as in point 3 above). Chances of these being accurate are low, I'm aware of that, and budget will (probably) go out of control due to change (as Ian pointed out). However, the tender process is fixed.

Let me reiterate the example - we've got a second phase with a budget of £x for additional development. No scope, no spec, we want to spend the money and get the best functionality we can for that money. A Waterfall supplier will pull a figure from the air, split this by phases and quote. An Agile company can't - they'd give a price per sprint. This isn't acceptable for the tender - we need a total quote. Fixed price contract is not an option - we have to get best value on pricing as well as quality

This might be impossible to resolve (it feels like it!) but I can't be alone in this. Just about all public sector procurement follows the same rules so others must be going through the same. There's a huge risk that a waterfall supplier will be selected as no agile suppliers will be able to quote.

Looking at the bigger picture, this is a huge issue for agile in general and it feels like some organised lobbying needs doing to look at changing tender procedures. In the meantime, i need to sort this asap.

Any more ideas?

> You mentioned fixed price tender - this isn't fixed price, we're expecting bidders to
> quote which is where my problems arise.

No, I mentioned fixed bid, not fixed price. The two are not the same, although I'm aware that the terms are sometimes used interchangeably. In fixed bid you collect the bids and choose the best contender. There's an article on the Scrum Alliance website which describes this situation:

http://www.scrumalliance.org/community/articles/2007/september/why-fixe…

In either case, the system can be played by suppliers who know perfectly well that requirements will change, and that Change Requests are an opportunity to increase the value of the project. This is often where they expect to make the *real* money.

Quite dated discussion, and it continues to be interesting. Is your problem not best solved that you agree some bonus for useful work being done at each stage, define the stages as early as possible, and until then work with whatever proposal you get, provided that you always can opt to accept this proposal?