This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Last part of Forests and Trees Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

So on to the "last lap" here. We had kind of a "roundtable" on problems that we've seen, been near, or helped create - that then led to project failure and/or crisis. So:

• Toot your own horn - if you don't, no one else will :) "Heroic" acts (often as a result of the "hero" screwing up) get rewarded - steady, good, quiet work rarely gets recognized
• Social success (golf with the boss, for instance) often leads to more success than does actual work
• Fixing the wrong problem
• Doing a project with new/trendy tech because management read a magazine, or the developers want to refashion their resumes
• Sticking with old tech for too long so as to stay in a "comfort zone"
• Death marches in general
• Announcing a launch date before there's a contract or requirements (Consulting firms!)
• Ill advised mergers - of corporations or internal teams (not that I've seen that :) )
• Focusing efforts on bug fixing to the exclusion of all else, w/o ever really paying attention as to whether the fixes are making customers happy
• Tensions between sales/marketing and engineering - either engineering taking too long for some "perfect" system that never arrives (hurts sales), or sales demanding customer specific fixes that may not be generally applicable - and thus disrupting new development

We drew a picture of that one:

The " " signs indicate pressure from one end exacerbating problems on the other. What you need is less "over the wall" and more face to face (issue for many offshoring projects, in the opinion of the room). We had another diagram that entered into this:

That diagram is trying to show the relationship between work that gets done, work that gets done with issues, and productivity - one can design models to predict where the "best" place to fix things are - but there are always tradeoffs.

That's about it - it was a great session, and I've only captured a pale shadow of it here. I'd welcome expanisons by any of the other attendees!