I spent a big chunk of my day dealing with a project that is, in no uncertain terms, a trainwreck. The client has sunk a ton of money into a product which is in, its current (first phase supposedly finished) state, unusable (client and vendor shall remain unnamed.) My role in the project has been strategic and as a liason, not technical, which to some extent gives me a bit of a distanced view. Web development trainwrecks are, sadly, far from isolated cases - they happen all the time, even when all of the parties have good intentions. And as someone who is building a business around doing this sort of work, it is of keen interest to me as to why some projects end up in the state that this project is in, and I want to make sure to avoid these kinds of situations. So how do we avoid trainwrecks? Some trainwrecks we can see coming miles away, but yet we are in complete denial about them. Some trainwrecks are like sudden derailments - it's not at all clear where it comes from. But I think all trainwreck projects have the seed of the wreck somewhere in the history of the project. The hallmarks of this particular trainwreck were so clear, that in retrospect, they scream out at me:

• Lack of transparency about development process
• Lack of transparency about cost implications of increased scope
• Waterfall development process (well, the vendor said they practiced Agile, but in practice, it's been waterfall)

As a practitioner of the Agile development process (we use a somewhat modified form of Scrum, in particular,) I'm beginning to really see the value of this kind of process. It makes visible all sorts of things that are often hidden. It seems like the Agile methodology helps in a number of ways:

• Once educated, clients have a window into the development process. They know what small chunks of development are going to happen in a given time interval, and they know what they will get at the end of that time interval
• Things are developed in priority order
• Clients can critique things early
• New functionality becomes a part of the "product backlog" and it is easier to have clarity about what is and is not within scope

Of course, it is theoretically possible to be completely transparent in a traditional waterfall methodology, and completely opaque using Agile, but I do think that the Agile methodology makes it way more difficult to be opaque. But it also takes some work and education of clients unfamiliar with the methodology (as well as making mistakes along the way on our part as developers.) And I've been able to watch this process work well, not only with our own projects, but also with a project I was a strategic lead on. I was pretty skeptical a year or so ago, but now I'm sold. And since transparency has always been something of real importance to me, a development process that encourages transparency is a good thing.