My development experience has primarily been in commercial software. As such, I am quick to recognize that some aspects of agile methodologies aren’t always practical for commercial software development, nor were they designed with commercial developers in mind. For example, sitting with the customer you have not yet won is not really practical (or even possible, unless you happen to know the Doctor). and the ability to freely modify and refactor published interfaces is greatly reduced without significant customer impact.
In fact, commercial software must often be written “on spec” prior to winning any customers, and may in fact be written in secret to avoid the possibility of larger competitors with a greater ability to execute from implementing your own product ideas before you have a chance to get them to market. Therefore, some agile cookbooks aren’t going to work for you, but that does not mean agility isn’t desirable or appropriate. Another problem with specific agile methodologies is that they are very geared toward the internal IT developer. This isn’t an unreasonable perspective as well over 90% of software development is internal, but again, this won’t necessarily address the needs of commercial software shops.
In addition, most commercial ISVs have a greater need for a predictable software releases. While a missed internal deployment can certainly cost money, a missed commercial deployment involving marketing, sales, partners, and competitors can call the future of a small commercial ISV into question. I have personally found a mutilated mix of waterfall, spiral, and cowboy coding in commercial software companies, and often with a culture of heroism.
Regardless of what specific agile methodology you look at, fundamentally they are all based on the same idea: Embrace Change. By “embrace change” I don’t mean “deal with change” with emergency design sessions and marathon coding sessions, or “cope with change” by padding estimates, or “ignore change” because you’ve got some heroic developers to save you. Change comes from many places: software or framework limitations, requirements, leadership, competitors, coworkers, design constraints, and so on. Arguably, commercial software is even more subject to change than internal projects, so there is a lot of benefit to be gained from greater agility.
Unfortunately, and with a few exceptions, internal IT development is generally the focus for both research and practice in agile methodologies. Commercial software companies are on their own in figuring out the best way to take advantage of recent agile practices. Commercial software can definitely benefit from agile development, but it will take a lot more effort and understanding to balance the constraints of commercial software with the tenants of agile development.