A colleague of mine sent me this email today. He mentioned about the dilemma which one of his client was facing. I have pasted his email below (I have changed some of the names to respect the confidentiality)
I needed some help on projecting Agile as compared to water fall. PQR product is getting implemented at ABC and ABC’s project head Dorothy is facing some challenge in motivating her team to work in Agile way, especially when it comes to UAT. I think it’s becoming hard for her to convince that ABC’s users can continue part testing for features released in UAT. ABC’s user’s team is more comfortable doing QA when complete product is rolled out for UAT. This approach will hamper implementation dead line (before <Month> 08 end). She was looking from us some kind of presentation / stats which clearly explains benefits of Agile over Waterfall and give some stats (if possible) on failed big projects using waterfall and successful agile ones.
Can we get some stats / figures etc around this request?
Having been in similar situations in the past, I can certainly understand Dorothy’s challenge. While I did respond back to my colleague (please see below), I thought about posting this email as a blog post to see if any of the readers out there can help Dorothy with their experiences and metrics. Also, I am sure there would have been many in Dorothy’s shoes and wanted to find out what they did to overcome the challenge. Please feel free to add your experiences in the comments section below this post.
My response to my colleague -
Software industry is littered with examples where the software failures (by failure I mean that it was not able to meet end-users needs) have occurred. However, most of the time it is very difficult to say that the failure occurred because of waterfall or agile or any other similar methodology. IMO, failures are always because of certain risks which could not be mitigated at the proper time. This article at the link below shows a survey results which lists why project failures have occurred in the past. When you look at these risks, it is fair to say that Agile Methodology is better equipped to mitigate these risks as compared to Waterfall.
Coming to your point of metrics – I personally do not have the project failure/success metrics comparing Agile vs. Waterfall. I can certainly hypothetically speculate, however I do not think that is what Dorothy wants. If I can understand what she is trying to look for is to look for ways to mitigate the uncertainties associated with the implementation deadline. If she lists these risks down and plans to mitigate that, she will very clearly see and convince people that Agile is probably their best bet.
I am slightly going on a philosophical note here – unfortunately we engineers many a times fall into a debate of one vs. other – Agile vs. Waterfall, Java vs. .NET, and so on as if they were two religions. I think achieving the goals is important as compared to looking at the rewards associated with selecting one vs. the other.
While I do not have a ready presentation on Agile vs. Waterfall (there are plenty on internet though which you can point to though). However, I would be happy to show and explain how we (in GlobalLogic) do it in Agile if Dorothy is interested. Also, please do note that the way there is ‘bad waterfall’ there is ‘bad Agile’ also ;-)
As I said in my email, the success and failures of a project are typically not because of a particular methodology – but how the methodology helps to manage and mitigate the risks associated with any projects. There are good and bad implementation of all the methodologies out there. In my experience, it is not in the best-health of the project to get into the debate of goodness of one approach vs. the others. We should leave it to the ‘academicial-minded‘ to do that. The key is to take the best of all the approaches which would mitigate all the risks associated with the project.