Agile in the real world
Let's suppose you have been saving to buy a new apartment, and you approach building firm as the building is still being build. The sales person says: "The building should be finished in two years. However, we just started working with Agile methodology, so we can't promise you windows, doors or a sink"
Would you pay your life's saving to this person?
But that's what Tom Hollander suggests: "Nobody should promise exactly what will be delivered at the end of the project"
I have recently listened to a screen cast dealing with Ruby On Rails, and it began with similar explanation of what is Agile development, leading to the same conclusion.
I'm a big fan of the Scrum method, which is Agile, but only when it comes to the way the team is working together.
Most developers I've met know the exact specifications of a computer before they buy it. They know the various systems in the car they intend to lease or buy. They know the exact contrast of the LCD TV they just purchased.
But when it comes to software, they claim "specs is speculation".
Wrong.
Specs is specifications, and that what's brings in the money.
A customer is expected to pay huge sums of money - of course that customer requires some sort of a promise, in the form of specs.
Saying "I can't promise exactly what you'll get for your money" can only work with open source projects, not in the commercial world.
You may use Agile to modify milestones along the way, but you need to commit to an end result.
Just imagine your customer saying: "well, I can't promise exactly how much money will be delivered at the end of the project".....
3 comments:
If you've ever built a house from hiring an architect to completion you'd know what breaking ground on a house is done without knowing all the details of the finished "product". Building a house and buying a house (and any other product) are different processes. Building a house does not begin with a complete specification of the final product, it begins with the essential aspects of the house (structural architecture) many of the final decisions are made up until closing day (colour of paint, fixtures, etc.).
Subcontractors that *do* try to complete an specification including all details before breaking ground are wasting their time and are in for grief. You can't expect that by the end of the project every single product will be available in the timeframes you need it or won't be discontinued, for example.
Software projects are the same. You must accept that despite base-lining what the product will do at the end it will likely be different. If you don't accept that, you're in for grief.
To a certain extent I agree with Tom, you can't promise at the beginning of a project that the end result will be what is currently specified. I believe you must be pragmatic and say this is what we will start working on (i.e. a baseline spec.), and build a change control process to ensure the project and scope don't go completely out of control.
Sorry Adi, but you misrepresented my post, or perhaps I wasn't very clear. It's fine for a customer to demand specific scope items and to hold the development team accountable to deliver them. My point is that it is unrealistic to promise the complete set of functionality that will be in the final deliverable - if for no other reason that the customer will never know exactly what they want upfront (even if they say they do, they will always change their mind!).
Your argument about knowing the specs of a computer or a car doesn't work for me, since the number of available options for either of these is very low (the engineering process is over by the time you put the order in). For a yet-to-be-built software system the amount of variability is vast, and while the customer will have a good idea what they want, there is still a huge amount of amiguity that cannot be anticipated upfront and must be resolved during the development phase.
I'm not arguing against specifications - they are a great way of communicating the current understanding of the requirements and design. The key point here is that the requirements will change, and pretending that you know everything in advance will do more harm than good.
Tom
Peter, in many cases someone is buying the product (suppose your company is a sub-contractor), so that someone doesn't care you are "building" it - they want to set the payment and delivery dates in advance.
Tom, I agree the specs may change, as long as the customer introduces the changes.
I don't think you can come to the customer and tell him: "well, we didn't predict correctly the effort required, so pay up 30% more. Oh, and the project will be delayed..."
I don't think you can tell a customer "I refuse to make any estimation because I'm Agile". Most of the time you still need to set some specs and commit to a time frame and cost.
Post a Comment