Choice of Agile Product Development Model

I have to disagree with you. Being agile is not about releasing software, but about being ready to release software. Most people do not get that, and that is one of the problems why many developers, manager, etc, believe agile practices do not apply to them.

I work for a commercial software development company that works on a yearly release cycle for the most part. As you mention, releasing a new version is not about burning a CD and give it to someone; there are many departments inside of the company and external companies that come into play, so it is not going to happen that we will shorten our release cycle. Besides, there are some other financial circumstances that will prevent this and that I am not even going to mention.

However, the product that I worked is designed by a team of product designers that write the specifications on the new features and lead the feature teams to insure everything works as is supposed to. The feature teams are also composed by QA engineers that will test the features, report defects, and re-test features. I do not have contact with other customers, but there are marketing and sales people that do, compile requirements and decide what is important for our product to implement.

All these people are my on-site customers. They do not buy the product, but they are the ones deciding if the product has the features that were requested, if the features work as they expect, and if the software has quality to go into production (being released).

My real customers, the ones that buy the product, would not see any of my work until next year, but these other people want to see progress on a regular basis. From the Marketing guy that will install the latest build once a month because he heard we integrated this new feature he was interested about, to the Product Designer that will get a new build every couple of weeks to make sure I am following the spec, to the QA engineer that takes a couple of builds a week to test on the latest code, make sure things are fixed, and there are no regressions, they all expect the code to be stable, with quality, following the spec, and with no major issues.

Guess what? I got to be agile. I got to keep my main production branch stable and put into place every single practice that will allow me to produce several builds a day, and if those builds are release quality, the better for me. Otherwise, I am going to get complains from a bunch of people that cannot do their work because the product is broken, or the build failed, or the test automation did not pass.

If I keep thinking that there is no hurry, that I still have a year to release, and that we can take it easy and then work over-time the last couple of weeks (or months) of the release cycle, most likely we release our software with very low quality and our real customers, the ones that actually pay for the software, are not going to be happy. Because when you work on a yearly release cycle, a year is a year, which means the product is going out the door no matter what.

I have to be agile, but not to release the product, but to keep the product ready for release year long. Otherwise, I will have to put long hours at the tale end of the project, and my customers will still be upset with me and the quality of the product (needless to say that I will also have broken some work relation on the way).

Sorry for the book.