<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Thinking inside a bigger box - Latest Comments in Agile and contract bids</title><link>http://thinkinginsideabiggerbox.disqus.com/</link><description></description><language>en</language><lastBuildDate>Mon, 18 Feb 2008 18:13:25 -0000</lastBuildDate><item><title>Re: Agile and contract bids</title><link>http://www.brodwall.com/johannes/blog/2008/02/17/agile-and-contract-bids/#comment-1798839</link><description>Hi, Aase&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Johannes Brodwall</dc:creator><pubDate>Mon, 18 Feb 2008 18:13:25 -0000</pubDate></item><item><title>Re: Agile and contract bids</title><link>http://www.brodwall.com/johannes/blog/2008/02/17/agile-and-contract-bids/#comment-1798838</link><description>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. &lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aase Mestad</dc:creator><pubDate>Mon, 18 Feb 2008 16:11:32 -0000</pubDate></item><item><title>Re: Agile and contract bids</title><link>http://www.brodwall.com/johannes/blog/2008/02/17/agile-and-contract-bids/#comment-1798840</link><description>Excellent and inspiring read. CC'ed it to our people who do this stuff :)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ferris Nicolaisen</dc:creator><pubDate>Sun, 17 Feb 2008 16:39:21 -0000</pubDate></item></channel></rss>