Agile method vs. Traditional method #1

-- review of http://www.accurev.com/whitepaper/why-try-agile

During the last few years, I have been working in a mobile phone company with traditional methods deployed successfully but failed to ship products with quality, on time. I have been really impressed deeply with the awful things described below. But so far I dont know how to overcome the issues successfully with “Agile methods” though it’s said that Agile methods has four core values

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Just finger crossed :)

------------------ headaches of traditional development methods, copy from original articles ------------------

Six Features in Six Months

Let’s say you want to add new features to stay competitive. In a traditional project, you have a known timeframe for major releases. Too short and you’ll spend too much time on overhead, too long and you’ll miss opportunities. For the sake of argument, let’s pick a timeframe of six months and say that allows you to provide six “big features” including time for all preparation and testing. Marketing says the six features with the highest ROI are a Facebook plug-in, a Second Life plug-in, an RSS feed plug-in, and three other features. During the six months, the business value of the planned features may change. If it goes up, that’s great, but if it goes down, there’s very little you can do about it.
Midway through the design process, marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. You think, “Oh well, nothing we can do about that now.”
Just after you finish coding, marketing declares that the Second Life plug-in is going to be a complete flop and wants to know when can they get iPhone support.
Now that the functionality has settled down, QA finishes their test plan, and starts writing test cases and running them. Planning and development took longer than expected. Originally, there was a month reserved at the end for testing, but now the release deadline is looming with just two weeks left in the schedule. The time for testing is compressed, QA concentrates on the most critical stuff and gives the rest a spot check. Once the find/fix rate gets down to an acceptable level, you declare victory and deliver the new release. In the end, the functionality that was asked for at the beginning is delivered a month late and doesn’t have the originally anticipated value.

Problems with Quality
In a traditional project, the elapsed time from start to finish from the perspective of any individual work item is very long. There is no consistent process applied to each and every work item. Instead, work items are fused together into “the release” and the quality of “the release” is measured. One consequence of this is that QA gets a big dump of functionality near the end of a release and has to figure out how to make the best use of the time remaining which is often less than originally planned. That means taking shortcuts. The "most important" new features get very thorough testing and the rest get a "spot check." Another problem with traditional projects is that since much of the test case writing, test automation, and test plan execution is left to the end, problems can hide out until just before the release and thus there is a long time between the introduction of a problem and the detection and fixing of that problem.

The Misperception of the Value of Traditional Testing
Here’s a mystery. If running through your full test plan takes two days, why does testing take a month? The answer is that you aren’t really doing a month’s worth of testing, you are doing the same testing over and over while a month of time goes by. Problems have been creeping in all along the way that you are just now finding out about, and it takes many test/fix cycles including repeating some or all of that test plan over and over again to expose and fix the problems. It is only the final full run of your test plan that gives you the measure of the quality of the product, so in the end you’ve really only gotten the value of the test plan. If it takes two days for that final run, then you have two days of testing, not a month.

Low Visibility
Time after time, with traditional development, progress is measured based on progress against a plan. The problem is that customers don’t buy Gantt charts, they buy shipping software and the progress that is measured by Gantt charts is not directly connected to shippable software. Just because you have finished.

100% of the requirements which is 20% of your plan, that doesn’t mean you are 20% done. In fact you are 0% done from the perspective of the customer because they can’t benefit from that progress until you ship. In a traditional project, you only know how much ahead or behind plan you seem to be based on the progress that people claim, but you don’t really know how much ahead or behind plan you actually are from an “is this shippable” perspective. It is almost impossible to see at a glance what the real project status and progress are. You know that you won’t start getting information about where you really are until sometime after code freeze.
It is hard to know what to do next if you aren’t sure where you are. Do you feel like you know exactly where you are and what to do next at every step of the process? Or do you feel pulled in a million different directions at once and lose track of what you’ve already done and what you need to do next? If you do feel like you’ve finally “got” how software is developed in your organization, how long did it take you to get to that point?

------------------ copy from original articles ------------------