Agile and contract bids
Whenever I talk about Agile Software Development with people who have a strategic point of view, a very pertinent question always comes up: What about fixed price projects? Establishing an initial relationship with a customer about creating a product is often perceived as a weakness of Agile methods.
After being asked the question very many times, I’ve started giving a fairly standard response, which is basically the same as Tom Gilb gave me when I asked him: Make the bid together with the first iteration of finished software. Here is the project plan for iteration 0.
The first thing I’ve noticed is that companies spend a lot of energy on making bids for a contract. This means that we have some money we could spend more wisely. If we have someone who understands the business reasonably on board, and we have the infrastructure to create a delivery in a few weeks and measure the cost of that delivery, we have an initial velocity. The bid to the customer will be based on that velocity. Week one: Stakeholder needs. The first thing we need to do to understand the needs of the user. (Refer to my article The Three Faces of Requirements for more on requirements). Gilb describes a plan for the first week, which basically puts the whole team together for a week to find the critical elements: The fifty or so stakeholders of a typical system, what the stakeholders value (system qualities), how to measure these qualities, and what design steps can be made to improve one or more of these values. From a technical point of view, understanding what other systems you will be required to communicate with, and how, is also something you want to do early. Having someone with good understanding of the business really improves the effectiveness of this week. The output of this week should be the set of product qualities and meters for these (as per EVO) and an initial product backlog. Week two: Build something. If you have a reasonably well put together architecture (see my articles on The Maven Application Server and Ruby on Rails if you don’t), you should be able in a week to put a hollow shell of an application on application servers and databases that can be used to demonstrate the product. You should have an initial installation of Fit, FitNesse or your functional testing tool of choice. You should also be able to set up a source code repository and a continuous integration server. Use the last half of the final day to look at the empty shell running on your servers and give yourself a pat on the back. Week three: Fulfill some requirements. Pick the most valuable things off your product backlog and get cracking. Make sure that you focus on building something to the state where it can be demonstrated, rather than start on a bunch of things. If you have the time and money, you can continue doing this for more than one week, but deploy whatever you’ve got at least as frequent as the end of every week.
Photo: iStockphoto
Week four: Wrap up and present bid. Revise the product backlog, and calculate or estimate your progress and cost on the stakeholder qualities from the initial delivery. Write up an offer with your understanding of the business needs (that is, the product qualities) and your essential technologies (programming language, server OS, database provider). Use the progress from your initial development as basis for the price offer. You can choose whether to give the calculations directly to the customer and whether you want to give a price buffer or discount based on how you want to interact with the customer. If the offer has to be delivered in writing, provide screen shots of your application and if possible, an URL where the customer can play with the initial version. But in this as in all things Agile, the more you talk to your customer, the better the result. Use the time you planned to spend on paperwork to actually create something, and prove your technological maturity in the process. Usually in a bid, the seller bears the cost of coming up with the offer. So too, when you’re actually building something. But you can decide to give the results of the first iteration to the customer for free, or offer it at an reasonable price. This way, you can actually provide value through the initial offer.
Comments:
[Aase Mestad] - Feb 18, 2008
I don’t think making a mockup/proof-of-concept will add much value to a fixed-price bid, neither that much of the effort in making a bid may be redirected to something like that.
Velocity on some selected use cases only tell you … the velocity on those use cases. The problem is finding how many function points (or whatevers) there actually are in the specification, and velocity won’t help you with that.
Usually you are supposed to supply a complete proposal for the whole spec, not just implement some selected use cases. So you still have to write the complete proposal, the “paperwork” that is supposed to be replaced by the mockup. In a bid you might include som “sugar”, like screenshots and a detailed narrative on selected parts of the solution, but that doesn’t take more than a day or two. This could be replaced by a mockup, but you might still want to write a description to explain to the customer how great this mockup is.
I just don’t see how a mockup/proof-of-concept of part of the solution can help answering the questions asked by the customer in a fixed-price bid.
Johannes Brodwall - Feb 18, 2008
Hi, Aase
Thanks for your comment. I see that you’ve probably worked on a few happier proposals than me. It always feels like the times I’ve worked on offers, it has spiralled into a fear-driven hole of documentation. 90 % of what paperwork I’ve helped create could easily have been thrown away without hurting the final proposal. It’s mostly bull* anyway. I’m happy to hear that your experience is different.
I agree that your initial velocity cannot be applied blindly to create estimates, but it’s provides a better foundation than any other estimation process I’ve seen practiced. At any rate, my hope is to move from the mindset of estimates to that of forecasts.
My goal is to open the door and estabilish a dialogue with the customer. In my experience, no real conversation starts when nothing is developed. The paperwork only creates good breeding ground for veiled misunderstandings.
Thomas Ferris Nicolaisen - Feb 17, 2008
Excellent and inspiring read. CC’ed it to our people who do this stuff :)