Re: Musings: Why do well-intentioned projects go so wrong, so often?

[Mutant]

Don't “scrap the old and start over.” Don't even say in public that you might.

I think you've chosen a solution without defining the problem here (or at least, you've got a specific solution to a very general problem). There are plenty of times where it's a good idea to scrap everything and start again. This can be from the technical end (e.g. the code base is barely maintainable, the design has fundamental flaws, the infrastructure is no good), or from the customer end (e.g. the system never worked properly, or did what we wanted it to do, the business has moved on, numerous "paradigm shifts" have occured).

I agree, it's not a good idea to scrap everything without a good reason. But good reasons often crop up. And it's important that the "business" type people, who are often the ones who write the cheques, recoginise that this might not be something initiated by them. Just because something "works fine" now, doesn't mean it's economical to leave as is, when every minor change takes weeks to complete.

More generally, I think Agile can offer a lot of help in most of these issues. I prefer Scrum with XP-style development practices. A lot of people still baulk at the mere term "Agile", but a lot of that is because it's been adopted as a buzz word, and completely mis-interpreted. Even if you do understand the theory side, putting it into practice can be a lot harder than you might think, especially in large organisations, with a lot of "baggage" entrenched in both processes, and people's expecatations. (Hint: to put it into place in this sort of environment, you almost *have* to have an independant Agile Coach. You'll probably find that as soon as you start trying to remove impediments, you'll find huge webs of resistance from upper management that are difficult to break down yourself).

I think what people who've put Scrum in to practice well find, is that if they really want to produce working software on a regular basis, they have to address how the entire organisation operates. To me, that's a reflection on the fact that software has become so integral to so many business, and is much more complex than your average (non-development) project.

Bottom line is: getting it right is hard. And we're still learning how to do it.

As a side note, it probably goes without saying, but there is only so much you can learn out of books. Experience is crucial, including learning from others' experience.

[sundialsvc4]

My brain generally clicks-off when people drag out sports-analogies for any reason. Programming isn't a sports-event; it's engineering. (Let the record show, furthermore, that “armchair quarterbacks” actually have no idea how a professional sports team, nor the surrounding business-entity, actually works. They drink the beer, maybe pay $34 for the book, and imagine that they do, getting smarter and smarter as the afternoon wears on.)

[Mutant]

I'm guessing you're referring to the name "Scrum"? Well, it was actually named by a couple of Japanese guys who clearly didn't understand Rugby, because their analogy doesn't make any sense. But at any rate, it's just a name, and the methodology *is* based on engineering (specifically, lean manufacturing).

I suppose they fancied themselves as marketing gurus. The fact that they originally named the Scrum Master role "Hooker" (a position in Rugby) proves they certainly weren't.

Anyway, I'd strongly recommend you go past the name and at least *look* at Scrum (or other Agile methodolgies). Even if you don't want to use it, you may find parts of it interesting and valuable.

[sundialsvc4]

(Chuckle...) “Hooker?!” ... Umm, is that the sort of person that someone who attaches the moniker “PMP” next to their name is supposed to be managing? (Wink!)