Agile v Waterfall - Which Is The More Risky?

I still find it strange that companies unfamiliar with Agile automatically view it as being a methodology that pays no heed to process or ensuring quality of output. From my experience the quality is actually a lot better, the timescales set are achieved more readily and everyone involved has a much greater understanding of the product and its development status at any one time.

At present I´m working on a project where I´ve had to split the test team into two due to several companies working to build a complex product together. One team is performing agile QA in a sprint team, the other is working ´the old way´.

It´s very interesting to note that all the worry and uncertainty is coming from the team working with the traditional model due to the fact that timeframes having been guesstimated months ago about environments, data and functionality that no-one knew about then. As time marches on we appear to be spending more time in meetings discussing what we once thought was gospel, has now changed due to various perfectly valid reasons and so how can we accommodate this into the table-filling project plan? To me it´s like trying to map out the projected state of the universe after being on earth for 40 minutes!

The sprint team obviously still has problems during the development of the app but they nail problems quicker during iterations, they know very clearly what´s coming up and can give really accurate times for delivery (or accurate times for delay). And everyone can tell you about all parts of the product - there´s no team building a module in a silo, oblivious of what the rest of the project team is doing because they don´t integrate their part until 4 months down the line.

There is a perception that using an agile methodology means starting to write code before knowing what the product is, and as a result the software testing companies people can only click a few buttons in a demo, shrug their shoulders and say “Yeah, looks fine to me I suppose”. What´s important to note here is that perception is shared amongst people who have not worked in an agile environment or, most probably, have worked in a poorly organised agile environment. To those people I ask that they maintain an open mind to change within project management and place some trust in the fact that there is a huge agile community out there producing fantastic software, in incredibly short timeframes, and with very high quality.