addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [newtech-1] Re: Pros and Cons of Ruby on Rails vs Coldfusion on Coldbox vs Microsoft Visual Studio

From: Mike B.
Sent on: Thursday, February 21, 2013 9:17 PM
Sometimes you have to fire the client.  I know, easier said than done when there are bills to pay, but I've had luck calling the bluff.  The right client shapes up and you move forward in a productive way for all concerned.  The wrong one would have been a money/time/reputation killer anyway so you move on quickly in to the next "right" one.  It's a hard to quantify opportunity cost thing.


Mike


Sent from my iPad

On Feb 21, 2013, at 7:42 PM, Andy <[address removed]> wrote:

Right. Agile doesn't mean no requirements, nor does it mean give me every requirement, fully and finally detailed, up front. Agile is simply a responsive, iterative process wherein one applies "just-in-time" paradigms to things such as analysis and documentation. Can't live without a doc in the end, otherwise how do multiple teams work together? How do multiple organizations work together? How does a builder get paid by a client and avoid litigation? Requirements documentation, that's how.

∞ Andy Badera
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=andrew%20badera


On Thu, Feb 21, 2013 at 6:35 PM, Mark Nyon <[address removed]> wrote:
I should clarify that I've been using Agile methodologies for awhile, and I do understand how quickly things can and do change, and can and have rolled with those punches.

However, If you do a search for "Agile Requirements Gathering Best Practices" , you see that they do exist.

It just seems that decisions are made without a certain level of thought & scrutiny, and products are built, only to be repeatedly scrapped later. If everyone is on board with that approach, that's fine, but when I've seen it occur, it's also been accompanied by the client losing trust and/or faith in the tech company to deliver what is promised, which introduces a whole bunch of stresses into the working relationship that it doesn't really need. Some thought/evaluating/requirements gathering/analysis would reduce some of that, IMO.






--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Mark Nyon ([address removed]) from NY Tech Meetup.
To learn more about Mark Nyon, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Andy ([address removed]) from NY Tech Meetup.
To learn more about Andy, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy