Re: [scrumdevelopment] Matrix Comparison Plan-Driven Agile Development
- Boris Gloger wrote:
> Great answer, and you got exactly my initial reaction, when I was askedI would think that Agile as Risk Management would appeal to that person.
> this question, that I wanted to rephrase in my bad english.
> But on the other side, this answer is not really helpful if you want to
> convince someone who will look at the money aspects of project, right?
"A sequential project costs $1M to $4M. The same Agile project costs
$1.5M to $2.5M. How much do you want to bet that /this/ project done
sequential will cost less than $1.5M?"
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand
- ---> You mean the alternative, when I want to convince someone who will look at the money aspect, is to lie to him/her? I can't do that.If agile is not less expensive, then don't advertise it as less expensive. That can only put you into a bad position for later, when they count the money.It may be, however, that the money argument runs as follows: get it out sooner using agile approaches, and start collecting revenue earlier. Then run the numbers for that scenario.Or, get half of it out very much earlier and starting collecting partial revenue much earlier. The numbers for that should look much more attractive. But both of these depend on the marketability of early deliveries.Personally, I advocate agile approaches as lowering the probability of failure (a noticeable but generally unquantified cost in itself), and as being more efficient (here's your lower cost) because we dump a bunch of the costly bureaucratic stuff other projects are made to do.There's nothing in the agile manifesto that says "dump the costly bureaucratic stuff." This permits me to talk to CMM 3 / 4 / 5 agencies and say, "keep all the bureaucratic stuff, just move the people closer together, deliver a working increment every month, hold reflection workshops and attend to morale. You'll notice already you're better off." However, most of us agile types, when given control of a project, will instantly dump the costly bureaucratic stuff.I don't know how to assuage any financialIn a message dated 12/3/2003 12:24:36 PM Mountain Standard Time, magarrigue@... writes:
But on the other side, this answer is not really helpful if you want to convince someone who will look at the money aspects of project, right?
On Wednesday, Dec 3, 2003, at 18:30 Europe/Vienna, acockburn@... wrote:
Ouch - this is a scary request
In theory, a perfectly run sequential process should be less expensive than an perfectly run agile project, so don't go to the theory. In the same theory, agile projects are shorter. Which is more important to you?
However, as they say, 'In theory, practice is simple." It is only in practice that practice is not.
In practice, a perfect of either is hard to come by. If agile comes out less expensive, it is because it recovers from unexpected surprises less expensively.==============================================
President, Humans and Technology
1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
Phone: 801.582-3162 Fax: 775.416.6457
"Surviving Object-Oriented Projects" (1998)
"Writing Effective Use Cases" (Jolt Productivity Award 2001)
"Agile Software Development" (Jolt Productivity Award 2002)
"La perfection est atteinte non quand il ne reste rien a ajouter,
mais quand il ne reste rien a enlever." (Saint-Exupery)
>> (Alistair)Tell the truth if the question is asked...
>> In theory, a perfectly run sequential process should be
>> less expensive than an perfectly run agile project, so
>> don't go to the theory. In the same theory, agile projects
>> are shorter. Which is more important to you?
> You mean the alternative, when I want to convince someone
> who will look at the money aspect, is to lie to him/her?
> I can't do that.
There is a theoretical ideal process for any project.
If it were possible to know this in advance, then using it
from the start would be cheaper.
The person that has the best information to make the decision
on what is ideal is the person who is just about to enact an
element of the process.
Conclusion - the theoretical ideal process cannot be known
in advance, it becomes revealed just before it is enacted.
By empowering the person who has to enact the process,
you enable the possibility of achieving the ideal process.
Of course, there's no guarantee that it will happen, but
take any other approach and you can guarantee that it won't.
Starting from this point, we can consider what needs to happen
to make it more likely that the ideal process will be enacted,
and less likely that a bad process will be enacted.
any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
- --- In firstname.lastname@example.org, PaulOldfield1@c... wrote:
>Wouldn't "the truth" include:
> >> (Alistair)
> >> In theory, a perfectly run sequential process should be
> >> less expensive than an perfectly run agile project, so
> >> don't go to the theory. In the same theory, agile projects
> >> are shorter. Which is more important to you?
> > (Boris)
> > You mean the alternative, when I want to convince someone
> > who will look at the money aspect, is to lie to him/her?
> > I can't do that.
> Tell the truth if the question is asked...
- the value (competitive advantage?) to the business of early
delivery of the features with the highest return,
- increased quality due to customer involvement,*
- where developers are permanent resources: better employee retention
(this definitely is quantifiable),
- predictable delivery dates,
- more accurate visibility of development progress,
We need to develop concise and convincing ways to convey these
benefits to the people making the decisions. Does it necessarily need
to be in dollars? For those experienced with development, they may
simply need a reminder of what they know is true... but somewhere
someone not familiar with how development happens will want more...
It's a puzzle I'm working on now...
* In "Managing Software for Growth without Fear, Control, and the
Manufacturing Mindset", Roy Miller sums it up in the
introduction: "Growing software allows us to get the software we want
at the end... not what we thought we wanted when we started". I've
just started it, but it looks like a good read - has good reviews
from Agilists on Amazon, and is predictably panned by those set
against change :-)