I take your lack of any argument to the contrary as implicit agreement with the subject matter. Otherwise, I am embarrassed for you due to your lack of any argument to the contrary.

chad:
I understand now, I think I made some incorrect assumptions. I too hope that you get the chance to blog profusely about your experiences!

The new gig I’m going to in March should have all of these things to some extent or another (hopefully a great extent) and so I hope to blog profusely about how well things work in contrast to my current gig which has almost none of these things, sadly.

The first, most important thing is that everyone has to WANT the project to succeed. Then it’s just a matter of persuading them and proving that certain practices (which, for some reason seem to go against conventional wisdom, even though they seem so obviously efficient and right) actually pay off in dividends.

Sadly, I have worked on a number of projects where many of the people involved on the project were more concerned with political points and vendettas than accomplishing the project.

I have been successful in persuading incremental change in several organizations. It seems that it is easiest when they have gone on for several years using no methodology or some sort of quasi-abortive waterfall and are so desperate for something, that they are willing to try anything. I have seen these organizations be very successful at implementing the processes I’ve described above because they are willing to drop what they thought they knew and try something that works.

http://jamesshore.com/Change-Diary/

http://jamesshore.com/Agile-Book/

Becoming a change agent isn’t easy. That’s when you start needing to look at persuasion books or something.

What would you like for bloggers like us to write? In my experience, it’s always been very subjective, the arguments always different, the reasons/motives/whatever for sticking with BDUF and hurry-up-and-work-100/wk-later are different in each situation.

I guess the essence of my point is that its great to discuss software process but ultimately its usefulness is restricted by the very nature of how hard it is to CHANGE software process. No doubt this is why there is a healthy market for Agile consultants. It has been my observation that for every 10 blog posts or articles that focus on improved software process there is but one that tackles the tricky problem of getting in there and changing the existing process.

You could say that my original comment was an effort to move us closer to improving on that 10:1 ratio.

As for TDD, some people are opposed to it, but I haven’t ever figure out why and they never seem to have good arguments (‘It takes too long!’ — as opposed to testing AFTER development? Or… surely they’re not suggesting you do NO testing, riiiiiggghhhttt???).

It doesn’t necessarily require full buy-in from everyone on the team (as long as you’re OK with ‘that guy’ committing code with no tests, or poor tests). It has been my experience, though, that anyone good at doing Test-After-Development LOVES or is very interested in the idea of TDD, but they just don’t know how to get started or are discouraged by the fact no one else is interested in helping him/her.

I’ve found two types of people when it comes to testing those doing/interested-in TDD, and those who don’t do testing. I know there are some staunch TAD’ers out there who swear that TAD is better, but I haven’t met them personally and haven’t seen their work, so I can’t comment one way or the other.

I have, however, seen TDD done effectively and it’s always helpful. I’ve never seen a project HARMED by TDD.