Organized and loosely run by: [http://www.seattlemind.com/wiki/index.php/Ario_Jafarzadeh Ario], [http://www.seattlemind.com/wiki/index.php/Berkun Berkun] & [http://www.seattlemind.com/wiki/index.php/User:JoeGoldberg Goldberg]

‘’‘Summary’‘’: About 20 of us had an informal session about the challenges of managing software development. The conversation ranged from dealing with stupid people, working across 5 time zones, methedologies, people getting hit by buses and other fun stuff. Here are my rough notes based on the final whiteboards and my ([http://www.seattlemind.com/wiki/index.php/Berkun Berkun]) memories.

* ‘’‘Does the requirements process always suck?’‘’ No. It depends on who is driving the process and how sane/pragmatic they are. If you think it’s a disaster, volunteer to define the process next time: it may be easier to be in the middle of the insanity and minimize it rather than be on the outside (and be controlled by it).

* ‘’‘How do you do sane small team work in crazy big organziations?’‘’ You have to find a way to interleave the two views of the world and translate across them. Effectively if the big organization has X deliverables, as longs as they get those deliverables they shouldn’t care what happens between those deliverables. Picking the right people to be the liason between the two worlds is critical.

* ‘’‘Is there a way to make specifications that don’t suck?’‘’ [http://www.seattlemind.com/wiki/index.php/Michael_Gerlek mpg] described a super-lightweight way to decent specs (and overcome the daunting fear of writing a formal, templated document). He starts in e-mail, and over 4 or 5 round-trips elicits the information needed for a good spec. At the end, he says “ok - this is what I wanted. Next time, lets just provide this up front, ok?”

* ‘’‘What is the elevator pitch for using Agile/XP?’‘’. Strict customer driven prioritization, Small specs/stories,  , Build little units, Always be able to release, Refactor existing work that needs to change, Matra is Lightweight/Flexible, more info http://en.wikipedia.org/wiki/Extreme_programming

* ‘’‘How to you protect against someone getting hit by a bus?’‘’ Insurance always has a price. Some say documenting things (code/specs) is one way, but this is expensive. Code reviews and pair programming help spread knowledge, but they also cost time. Best bet: pick the most critical work that would be most difficult for someone else to pick up, and spend your insurance $$$ there. Don’t document everything: document the things where the value of documentation is most valuable.

* ‘’‘What is Alan Cooper’s triad method?’‘’. Ario described his recollection of Cooper’s new method: one interaction designer (ID), one programmer (P), and one design engineer (DE).  The DE architects the work based on the ID’s prototyping and research. P does most of the coding. Each one (in theory) does the thing he loves most. However it’s never been done, and no one has been volunteering (We guessed because the resources seem prohibitive).