Technical Architect, SCJP, SCWCD
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Most market sector I've worked in has involved doing project work for a fixed up-front cost, fixed up-front time frame and a mutually agreed project scope.
The best way (i.e. meets customer's expectations and makes money for my employers) to do such projects seems to be to use "old fashioned" methodologies and a detailed up-front design and estimation. Going agile tends to be counter-intuitive and results in much more risk and generally making no money for my employers!
I guess a best approach might be a mixture of agile and more traditional methodologies, however that's not a message I've ever heard any pragmatic Agile evangalist ever preach?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Originally posted by Rajah Nagur:
[QB]As far as estimation is concerned, the beauty of Agile process is that the developer estimates the amount of time that will be taken to develop his module.
But in fixed bid projects, since the estimation is decided upfront, stirictly sticking to Agile methodology becomes a bottleneck.
The best bet would be to use the hybrid model i.e. take the best practices of Agile process (pair programming, TDD, continous integration, lightweight QA process ) and combine with say RUP (process workflow, activities definiton, estimation and template guidelines etc).
No single methodology fits any project. Tailoring needs to be done.
The end result should be always focussed on the successfull timely delivery of the project..(if all goes well and project is delivered then it really does not matter/nobody cares what process/ methodology was used).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Technical Architect, SCJP, SCWCD
Originally posted by Chris Nappin:
To explain my issue a bit further, to make money on a fixed cost contract the estimate must be very accurate.
Any overspend eats up the profit margin until the project is being done for considerable cost to the software development organisation.
The cost of a project is agreed well before any developers get involved - usually only sales, pre-sales consultants and architects would be involved.
This would be the "Inception" phase in RUP, right? These people have to produce an accurate estimate based on the scope of the project.
My question about agile is this - if deliberatly choosing a methodology in which the scope of the project is not known
and capturing detailed requirements and doing software design etc. is left until later in the project, how can the estimates be anything but more inacurate than the more "old fashioned" approaches?
No doubt I'm completely missing the point, but capturing the entire requirements in minute detail, then doing a detailed design "in stone" (and charging for "Change Requests" if the customer changes their mind) would be far more likely to turn a profit for the software development organisation.
Let me introduce a couple of solutions that I've heard of (but not seen in practice), does anyone know of any others?
1. The fixed cost buys a fixed amount of time, which is estimated to be sufficient for the customer's major functionality items but can't be guaranteed. Further discussion starts when the alloted amount of time runs out. Not something I know customers will accept, functionality is usually part of the contract.
Each major iteration is a separate contract with an individual price. Here agile comes to it's strengths as each successive iteration can be priced more accurately than the last, as the overall projects proceeds. Again, not something many customers will accept, as they have no idea what cost they are getting into when starting a project.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The cost of a project is agreed well before any developers get involved - usually only sales, pre-sales consultants and architects would be involved. This would be the "Inception" phase in RUP, right? These people have to produce an accurate estimate based on the scope of the project.
My question about agile is this - if deliberatly choosing a methodology in which the scope of the project is not known, and capturing detailed requirements and doing software design etc. is left until later in the project, how can the estimates be anything but more inacurate than the more "old fashioned" approaches?
No doubt I'm completely missing the point, but capturing the entire requirements in minute detail, then doing a detailed design "in stone" (and charging for "Change Requests" if the customer changes their mind) would be far more likely to turn a profit for the software development organisation.
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Scott Ambler:
You might find Comparing Approaches to Budgeting and Estimating Software Development Projects to be of interest.
- Scott
Technical Architect, SCJP, SCWCD
I get the impression that the initial estimation process (part of getting the sale) is generally not any different regardless of the methodology being used.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Chris Nappin:
A few interesting responses. I get the impression that the initial estimation process (part of getting the sale) is generally not any different regardless of the methodology being used. It's often this step that defeats projects before they start, so I'd be interested in any thoughts on improving this step.
And agile project management only deal with issues "in the small". Any estimates made during later phases of an agile project might be more accurate but have to fit into the original overall cost or timeframe, which could be wildly wrong.
I'm intersted in agile methodologies because I've witnessed a fair few projects fail on which I think agile approaches would have helped. However I'm still not sure how an agile project can be sold, on a fixed cost, fixed duration, fixed scope basis.
It's easy to explain to a customer who's been badly burnt by failing projects that agile approaches make sense and fixed cost/duration/scope is unrealistic, however for everyone else the lowest cost seems to win every time.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Originally posted by Rajah Nagur:
It is very ideal situation if the programmers/developers contribute to the estimation of the project.
In many *practical* situations, when the project is in proposal stage/funding stage/RFP stage, there is no team existing. A rudimentary estimation has to happen for the scope/size/tenure of the project. After this the programmers/PLs/designers/analysts join this project.
Since most of the projects in an accout will be the similar nature (For e.g. healthcare, financial services, online ecommerce accounts etc) and based on the prior experience many can come up with fairly accurate estimate behorehand and then manage the team and finish the deliverables.
This is what is happening in most of the cases..a highly experienced team (interacting with the customer) estimate the project timelines and then recruit/choose the team and give the deadlines. The team can then choose any methodology to execute project but within the limits of the timelines set.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
In many *practical* situations, when the project is in proposal stage/funding stage/RFP stage, there is no team existing. A rudimentary estimation has to happen for the scope/size/tenure of the project. After this the programmers/PLs/designers/analysts join this project. This estimation happens based on person's experience.
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Ilja Preuss :"
Well, if that is working well for you, there is no reason to change I guess.
Is it working well for you?
[QB]
Originally posted by Scott Ambler:
[QB]
This doesn't sound like a very practical situation to me. Although many organizations choose to work this way, in practice it proves to be a really poor way to work. My recommendation is to educate people on the implications of the choice to work this way, and my BRUF article should help to do that, and then let them know that there are better ways to work.
Just because something is the status quo in your organization, that doesn't mean it's a good way to work, nor does it mean that it's practical. If the person making the estimate was truly experienced they would know that working this way isn't a very good idea.
- Scott
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Scott Ambler:
I guess that my fundamental assumption is that you're willing to choose to succeed, which I have argued for years is a very difficult decision to make (people choose to fail because it's much easier to accomplish, then lie to themselves about why the failure occured).
- Scott
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Originally posted by Scott Ambler:
(people choose to fail because it's much easier to accomplish, then lie to themselves about why the failure occured).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Rajah Nagur:
Originally posted by Ilja Preuss :"
Well, if that is working well for you, there is no reason to change I guess.
Is it working well for you?
Not always (My personal opininon).
But I think folks in the IT world are used with this kind of System & they tend to find something good from it even if the project dooms. Human brain perceives what it wants.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mhh, and still from your previous post it sounded a little bit like you were defending that approach. Were you?
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Originally posted by Rajah Nagur:
I was defending in the sense because I was not thoroughly convinced *starting a project without any estimation* and also project always succeed when the developers/programmers contribute to the estimation.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Yufeng Su:
I think there is no definitely best methodologies for any project
no matter traditional methodlogy or agile, it depends on the scales of you project and the resources.
I think agile is suitable for the small or medium projects
which the developing or maintaining process won't be too long.
It counts much on the factors of humman, so the stabilities and the abilities of the humman resource is the most important for the delivery.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
It wasn't my idea to go to some crazy nightclub in the middle of nowhere. I just wanted to stay home and cuddle with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|