1

We're looking into agile increasingly at my company but I think it works better for some projects than others.

We have one product that is all ours and we control the roadmap. This is obviously perfect for agile.

However, a lot of our work involves putting in a proposal or bid against other vendors for custom development. Clients typically expect documentation on what they can expect and they want to know the budget up front. Is this really a good fit for an agile process? Contract negotiations and documentation are on the wrong side of the agile manifesto but they are also part and parcel of trying to win new business.

Of course you and I know that the specs can never accurately refelct what the users really want. At best it will be 80% right and then there will be requests for change at the end. We also know that the estimates will be difficult to get right but when you're dealing with big corps they always want a fix cost and for the small vendor to take the risk if it goes over budget. Of course in the end they have to pay for changes so it's not really a fixed budget but how do you convince a client of this when other vendors are promising they can deliver?

So on the one hand an agile process would give a better end product but on the other if you don't produce documentation and a fixed budget it's going to be difficult to win the business.

Are there examples of agile working in this environment?

Ben Thurley
  • 149
  • 7
  • "If you don't produce documentation and a fixed budget it's going to be difficult to win the business": Well, it seems reasonable for a client to say "I am not going to spend more than X" (e.g. because they cannot spend more money than they have). So I would expect that any methodology can give at least a rough estimate of the total costs. – Giorgio Dec 17 '15 at 12:04
  • @Giorgio how do you square that with an agile process that embraces change? You give a fixed price but accepting the changes could cause the costs to spiral. Who takes the hit? – Ben Thurley Dec 17 '15 at 12:18
  • The duplicate is fair enough. I did search but that one didn't come up. Thanks. – Ben Thurley Dec 17 '15 at 12:20
  • "You give a fixed price but accepting the changes could cause the costs to spiral. Who takes the hit?": How about: "These unplanned changes have the additional cost of ... $" The customer then chooses if they want them or not. – Giorgio Dec 17 '15 at 12:48
  • 3
    The problem is that non-Agile methods also have trouble with this. – RemcoGerlich Dec 17 '15 at 14:06
  • 1
    @RemcoGerlich: Any method has problems with predicting the future: it is indeed a difficult task. – Giorgio Dec 17 '15 at 14:41

1 Answers1

4

Estimating and bidding is one thing, making the contract is the business of managers, sales persons and attorneys, but how you develop the software after you got the contract is a separated issue. And the (initially) written down requirements in the contract as well as the price should IMHO not depend on the development methodology. Your contract might be partially different because when you plan for agile development, you want to commit the client to participation, but that's not directly related to the other points.

Lets assume you negotiated a price worth of 4 months of development effort, you made a very detailed contract and start developing waterfall-like. You stick exactly to the words of the contract, and after three months of development you deliver the first release. Now it is the first time the customer sees what he will get, he notices the errors/different possible interpretations of the contract, and it turns out half of the product must be thrown away or redesigned in full to turn the product into something usable - much more work than one month. In the best case you both agree about the misunderstandings, and set up a new contract, in the worst case the customer tries to blame you for all the misunderstandings and tries to get all the changes for the original price.

Now compare this to a more "agile" approach: you start with a contract as well, maybe not so detailed, maybe exactly as detailed as before, but also worth four months of development effort. After two weeks of development, you deliver the first release and the customer gives you early feedback how good you matched the requirements. So you can compare the feedback very early to the contract. If necessary, you can re-negotiate with the customer if he has brought new requirements on the table. There will probably other requirements of the customer which turn out "not-so-important-as-written-in-the-contract". They can get a very low priority, and you do not develop them with every bit and detail, and the customer will probably agree to this.

So in both cases you make an initial bidding and estimation, and in both cases you give the customer a documentation "what he can expect to get" beforehand. The difference in "Agile" is it gives you much more opportunity to react early to the customers wishes, match your estimated effort better, and adapt the contract or the documentation (in consensus with the customer), if necessary.

Note, in both cases, it can turn out you wrote too many requirements into the contract for the estimated working hours, that is a always a risk - quoting Nils Bohr, "Prediction is very difficult, especially if it's about the future". Agile development, however, will (hopefully) help you not to waste too many extra hours for developing the completely wrong product.

Doc Brown
  • 206,877
  • This is an interesting idea. The answer to the duplicate question is basically give up and use agile for the on-going support work. I'm not sure you can call it agile if your starting point is a fixed quote and a massive spec but to use a more incremental approach over one delivery at the end could benefit. – Ben Thurley Dec 17 '15 at 12:55
  • @BenThurley: I do only see a slight difference between both answers. When both the sales persons and the customer want to see a detailed spec before the first line of code, let them handle it this way, that is similar in both answers. My recommendation, however, is, as soon as the coding starts, go agile, get feedback ASAP, do not generally "defer changes to be handled under the support contract", that wastes your time and money as well as the customers. Instead, apply an active change management, handle changes as an opportunity to hit the target more precise. – Doc Brown Dec 17 '15 at 15:22