Re: [AM] Article of Interest in CIO Magazine

[email protected] wrote:

<snip />
> However, the rapidly increasing importance of software, and the 
> increasing reliance on software to facilitate virtually every facet of 
> commerce, makes the development methodology to be employed an important 
> factor. 

Of course it is important, but only secondarily. What matters is whether 
the client gets what they need when they need it. If a client uses the 
development methodology as an important factor in deciding on a vendor, 
then the client is looking in the wrong place. I understand that they 
may have been trained to look there, but nevertheless it is the wrong 
place. This is Management 101: you get what you measure. Does the client 
want software? or a software process? My clients, so far, have wanted 
software.

> Further, while clients are still clients, and programmers are 
> still programmers, the reported benefits in productivity and quality 
> that are purported to accrue when they are combined in an agile manner 
> substantially exceed those that accrue when the relationship is based 
> upon a more traditional model. Is it, in fact, possible for clients and 
> programmers to remain in their traditional roles and expect the results 
> of their union to be any different than they have been in the past 
> thirty-some years? If it is, what benefits do the agile methodologies 
> bring to the table? If the potential paths from start to finish of a 
> development project are visualized as a triangle (ABC), agile 
> methodologies are perceived to provide a way to go straight from A to C, 
> without taking the longer path through B (relative to the development of 
> "working software", not distance). 

I don't understand any of this. To seem to think that I am a 
traditionalist or something. I am not; I am an Agile practitioner and 
have been for a few years.

You may have miscontstrued my comment. Clients should make business 
decisions; programmers should make programming decisions. How the 
programmers build software is a programming decision. The client and the 
programmers ought to agree on the level of communication they can 
sustain throughout the project, and the programmers have to work within 
that framework. It is certainly not my goal to see clients and 
programmers continue /not/ to talk to one another, as tends to happen 
with more traditional approaches.

> BTW, my postings in this thead are intended to elicit comments from 
> agile practitoners more experenced that I that might serve to answer 
> some of the criticisms that have been posted in this forum and elsewhere 
> regarding the benefits of the agile methodologies and the issues to 
> which they pertain. It is clear from these postings that some clarity 
> would be both welcome and useful. No offense is intended.

More experienced than what?
-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------