[thelist] Fulltime to freelance

[Luther, Ron]

Hassan Schroeder noted:


>>Perhaps you missed the principle two lines down:

  "Business people and developers must work
   together daily throughout the project."

>>It's the "business people" -- end users or their representative(s)
>>-- that define use cases, scenarios, feature requirements, NOT the developer(s).


Hi Hassan,


I respectfully disagree.  The biz folks may own the reqs, scenarios, and the like but I would certainly not agree that they are solely responsible for developing and defining them.  I believe (surprisingly strongly AAMOF!) that one of the key components of agile is that it does _not_ excuse the developers from having responsibility in working to define the requirements.  (Dude, there is a heck of a lot of value the developers can bring to that process - if they would only choose to!)

IMO when this technique works at its very best, it is a collaborative and consultative effort with both parties actively involved.  The minute either party get into the 'his role' / 'her role' / 'throw it over the wall' / 'not my job' mentality ... then whatever the process you might have at work is ... it's no longer "agile".

I've spend a lot of time acting as an interpreter between biz and IT.  The biz requirements are a LOT more flexible and negotiable than [many in] IT like(s) to think.  Having the ability to come to the table and say "Hey - that functionality you are asking for here is hard, expensive, and will take forever to implement ... How about if we did it this way?" is absofreakingly invaluable.  Even in talking to the timeline and 'wave' stuff - being able to make suggestions; the "Hey, how about we rollout {1}, then {3}, then {2}?  That would make things easier on our end.  Could you live with that?"

The biz folks are not omniscient.  And the bizreqs are not tablets coming down from the Mount.  The developers could stand to be a little more probing in asking questions not only for detailed understanding of the specs, but of the relative importance of the features in the set, and the how and why they support the underlying business process.

I think the consultative approach should be imperative.


My 2¢,
RonL.

(Who was composing a very long reply to Matt on how to 'sell' agile when he got sidetracked by work.  Maybe I'll finish that and post it here instead when I get back.  Have a good holiday y'all.  I'm off for a few days of hiking.  L8R!)