RE: Looking for Agile Experience

I think that is over-generalizing.

At many medium and most larger shops, in-house development is billed (with funny-money) to a user department and tracked like cash expenditures. Hours are tracked to the nth degree as a cost control measure.

Agile is used exclusively in start-ups for example years ago Mark Zuckerberg started coding with little effort spent on requirements and all effort spent on coding.

As a company gets more established with 1000's of employees and boatloads of costs, IT treats software building like house building; ie finish the last blueprint before sawing the first lumber.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Raulerson
Sent: Thursday, October 24, 2013 3:02 PM
To: Midrange Systems Technical Discussion
Subject: Re: Looking for Agile Experience

Agile works much better for in-house development (where costs are to a large degree, fixed anyway...) than in contracted work, where cost control (i.e. billable hours) is usually much more of a concern. 

-Paul


On Oct 24, 2013, at 02:49 PM, Matt Olson <Matt.Olson@xxxxxxxx> wrote:

With a lack of requirements how does one estimate the time and cost involved in such project?

-----Original Message-----
From: John Yeung [mailto:gallium.arsenide@xxxxxxxxx]
Sent: Thursday, October 24, 2013 8:45 AM
To: Midrange Systems Technical Discussion
Subject: Re: Looking for Agile Experience

On Wed, Oct 23, 2013 at 10:11 AM, Richard Schoen <richard@xxxxxxxxxxxxxxx> wrote:
There appear to be shades of Agile, so we've picked up the bits that
seemed to make sense such as requirements before coding

Well, "requirements before coding" is actually more strongly associated with the waterfall development style than the agile style.
You could definitely argue that it is part of agile, but the emphasis of agile is on adaptability and responsiveness; and as such the requirements are much more likely under agile to change quickly or be revisited.

Whenever I hear people in IT (particularly in companies whose core business is NOT their IT) talk about requirements before coding, it's in the context of having as close to iron-clad specs as possible for a whole project prior to doing any coding at all for that project. The specs are typically only revisited if it is discovered that they are unworkable (and the IT people working under this model typically blame the users for giving them bad specs or for asking to change the specs after the work starts). This model sounds much, much more like waterfall, and practically not at all like agile.

If by "requirements before coding" what you really mean is "let's understand something (which is preferably some small piece) well enough to be able to write tests for it first (and let's then go ahead and write those tests first) before we do coding (for the functionality being requested)" then, yes, absolutely, you are talking more agile-style than waterfall-style. But that's a lot of extra verbiage that you're implying/assuming. In my opinion, far too much to distill to a three-word buzzphrase.

John
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.