Good comments, and some skepticism, greeted my article about 6 things that you can skip to accelerate a software project.  Mirko wrote “You are crazy”.  A more serious criticism came from MikeB, who, like many others, works for customers that want fixed specifications with firm time estimates.  He wrote “What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'.   Find me a customer that will accept that, and I'll retire right now.”

Timelines and budgets, in my opinion, are the easy part.  You can do a good job with a fixed price/budget, and a fixed timeline, if the deliverable isn't fixed.  So how do you get away without promising a fixed deliverable to a demanding client or sponsor?  You fix the important part.  You create a roadmap, a prioritized list of feaures, where the important things are sorted to the top.  You guarantee a minimum level of capability, and then you go from there.

Then, the whole thing fits together.   Agile methodologies deliver releases on a fixed time cycle.  So, they give you a much better chance of hitting your delivery date than non-iterative methodologies.  Your expenses are based on the time required (mostly, cost of labor per week), so if you can deliver on time, your budget is easily fixed at (cost per week) * (number of weeks).  You take some risk by guaranteeing a minimum deliverable, but that's your job.  At some point, you have to step up, and be good at what you do.

The thread is copied below.  At the end, I present our battle-hardened (but not foolproof) Assembla Consulting recipe for delivering a product on a fixed price / fixed time basis.  And, in extreme circumstances, I suggest this simple scheduling algorithm.

posted @ Friday, May 01, 2009 2:51 PM by MikeB
Hrmm - you develop software for a web platform that customers subscribe to. What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'.  Find me a customer that will accept that, and I'll retire right now.  The Agile approach sounds all peachy - but in the business world... hmm...

posted @ Friday, May 01, 2009 3:08 PM by Andy Singleton
MikeB, I don't understand your comment. Agile or not, you have prioritize the features that you are working on for customers, and tell them "yes, we will do that" or "no, that is not on the roadmap." You have yes's and no's whatever your methodology. 
 
If you give a customer an exact time of delivery to an exact specification, and then miss the date, you are actually causing a worse situation than if you don't give a specific date. Under the agile methodologies that I propose, you do better for this customer in two ways. First, you move faster, so you have a higher probability of hitting any given date. Second, you can get them a release on a specific date, if that turns out to be important, by not committing to a fixed spec. 
 
I usually work with a fixed timeline, fixed budget, and some flexibility on the spec. So, perhaps Assembla's work does fit into the type of customer relationship that you are imagining. 
 
However, there are a lot of customers that like the idea of getting software when it is ready to be released, soon, but with no timeline. That's the policy that Google uses, with their soft launches and endless betas. Google is one of the biggest software companies in the world counted by either revenue or users, so it's clear that they have found a large number of users that do subscribe to their "we'll get it done when we get it done" approach, as long as the basic underlying service continues to work.

posted @ Friday, May 01, 2009 3:21 PM by MikeB
I see your point Andy - or, really, I -want- to see your point. I love the agile concept - however, again, I'm not sure that it works when a customer is purchasing a deliverable product from you. That is, when we're not building a product internally, or as a beta, to be released later for sale to a community (like Assembla and Google products).  
 
Let me try to explain my thinking (correct me where you see me wrong) - So in your case, you can certainly work the agile approach because you know that whatever changes you make to the solution are out of your own pockets. If its a worthwhile change, where you see the potential to increase price or number of sales, you'll choose to add it in. 
 
Contrasting this though with customers coming to you for a specific product to be built specifically for them - they need to know what it is going to cost; they'll require it - 15+ years in this business I've never seen different. Maybe I'm doing somehting wrong, I'm always one to listen to critique...  
 
So, how can we give a price tag and at least a close timeline if we start so loosely and allow change along the way. 1) we never know what it will cost us to build it and 2) the customer will never know what it will cost them to have it made. 
 
I know I'm probably in an old school paradigm, but I am able to look outside the box... I just wish I could make more sense of this - I'm even having a tough time explaining it here. But really, I do appreciate your feedback on this as I really do want to visualize this working the way its supposed to. I just haven't found a customer to support it - they have to know how much money they are going to spend - just like everyone else. 

posted @ Friday, May 01, 2009 3:42 PM by Andy Singleton
MikeB, it can work if you assume that the specification is not fixed. At Assembla Consulting we work on fixed cost, fixed timeline development projects, and here is how we quote it.   

First, we make a roadmap, a list of features sorted in priority order. Whenever possible, we pull features apart so that we can deliver a simple feature first, and add to it later.  
 
Then, we read down the roadmap and we draw a line under the minimum feature set that we think will make a useful release. That's our guarantee. We take some risk to guarantee that you will get that much, within a fixed budget and timeline. There should be a high probability of going considerably beyond with the same budget and timeline.  
 
Then, we decide on a timeline that includes a first useful build, a beta release, and usually, a full production release. These timelines range from 8 to 26 weeks, and typically are more controlled by the business schedule than the development team.

Then, we design the team or "level of effort" that we think we need. Admittedly, this requires a rough estimate of the work to be done. The team has a certain weekly cost.  
 
The budget is equal to the cost per week, times the number of weeks. 
 
Then, we work on the roadmap in order. We assume that the roadmap will change approximately weekly if we see opportunities to improve the product. We release daily for the development team, weekly for the client, and to bigger groups on the dates promised. We try not to make a decision about when to release, but instead, discuss who should see the release, depending on its level of maturity.  
 
With this technique, the exact deliverable is not fixed, but you have a fixed budget and timeline, and you always get a useful product.  
 
This method is not appropriate for someone who absolutely requires a fixed spec - probably because their budgeting process is so unwieldy that they only want to go through it once. However, it produces a MUCH more reliable timeline than other methods, and it leaves open the possibility of getting a better product than you initially specified.

posted by MikeB
Very good clarification Andy, thanks. This has spurred a great conversation. I have often wanted to hear how another business owner utilizes this agile approach. I'll take a little time to re-read and further absorb your response - I may reply or may not reply again - but your post allowed me to air something that has been bewildering me for some time. heh  
 
It was particularly useful hearing a response from a business owner and developer, rather than simply from a developer high strung on agile.