Here's an Agile development scenario. For simplicity, let’s use two month iterations. Marketing says the three features with the highest ROI are a Facebook plug-in, a Second Life plug-in, and an RSS feed plug-in.
You start with the Facebook plug-in. You plan. You design. You create a test plan while the code is being written. You discover potential problems and deal with them. You automate those tests while the code is being written. As the code is written, it is integrated, built and tested continuously; problems are found and fixed immediately. At the end of development, the only problems that remain are the ones that could only be found at the end of development. If you wanted to, you could cut a new release with very little overhead.
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. So, you start on the RSS feed support. Now marketing says the Second Life plug-in is worthless but iPhone support is hot, so you add iPhone support. During the whole process, you kept your options open. At the end you have produced more business value than using the traditional process, and you were in a position to start realizing that value much earlier.
To get the primary benefits of Agile, as described above, you don't have to use 3x5 cards or pair programming, and you don’t have to do frequent releases. These things are optional and you can use them or not according to your preference and circumstances.
Next: Achieving the Primary Benefits of Agile
3 comments:
Wow! That's a lot to cover in such a short piece. I think you did a good job compressing it, although I feel like I want to pipe in and add that there's so much more agile goodness!
Scott Ambler did a really awesome workshop at last year's SD Best Practices that compared and contrasted traditional vs. agile I wrote a little about it here - might give you some other ideas if you were interested. I think his main point was that the ultra compressed timeframe forces us to work more collaboratively, which in turn winds up being so much more efficient then a sequential effort of throwing things over walls.
One nitpick - I got a little hung up on the two month iterations ("is that really agile?"). Could you make this work with 2 week iterations inside of a 2 month release (you don't have to deploy every iteration, right?). Or maybe even just 1 month iterations?
--
The Hacker Chick Blog
Hi Abby,
Thanks for the kind words. This post comes from a powerpoint I put together that shows traditional vs agile in a single (animated) slide and I was trying to use a reasonable timeframe for the traditional project of six months. By using 2 month iterations I didn't have to come up with 6 features and go through each one in the example. :-) I should probably update the post to reflect what I just said above so folks don't get the impression that a 2 month iteration is a good thing. Hmm, I suppose I could keep the timeframe to 6 months, do the first three months of each and reduce the other 3 to "and so on." Thanks again for your comments.
I was searching for top agile development services for my startup business and I have visited many websites to get this service at a reasonable price. Agile customer servicesof Epikso have made my job effortless and they have provided me the best services that fit well in my budget. Thanks for sharing all this helpful information.
Post a Comment