Like many of my colleagues, I love the conceptual idea of agile software development – forgo with the ancient ways of a long release cycle and move forward with quick bursts, course-correcting when needed. The lure, for the feature greedy product manager, is immense: you quickly “see” results, and have higher transparency into the product development cycle.
Are you also aware of the risks?
Getting “something out, quickly” (be honest, that’s the name of the game) means you draw short-term plans, even if by priority. That can mean that the “early features will get the worm”. In places where you just can’t issue partial features to customers, the early features will get completed and perfected while the features coming later into the game will remain “dark” – waiting for a later iteration before seeing the light of day.
There are distinct advantages to having the full “project plan” out, with rough estimations. Those “pesky customers” will need visibility (and sometimes commitment”) to roadmap. That means setting a date, communicating it, and sticking to it. If the capabilities being developed are complex (i.e. can be sold for a high margin) they cannot really be perfected in a matter of weeks, and need to be placed on a calendar. Good plans will need estimations (rough as they may be before starting to code). Good estimations will require good, detailed, product specifications and good end-to-end product specifications will require time.
On the other hand, the situation where all knowledge needed for development, including customer requirements, is available beforehand is rare. In the real world you want to get a certain capability out there, and quickly. You (and your customers) are not always sure of the finer details of the capability. Very often, the capability can be sold before both parties realize the full extent of the project. Even more often, it is very worthwhile getting real world traction with initial products and expanding where you can effectively benefit from the 20/80 rule.
For me, it’s all about value to the customer: if the customer can rarely upgrade, and needs the product down per spec (imaging an on-premise university system you can upgrade only during summer break) – be wary of cutting corners the agile way. However, if the customer is a SaaS user, and you can benefit from iterating, measuring customer behavior – by all means get results out there, quickly, and iterate.
I have worked in “main train release” companies – where the release is once every 18 months, and installation is on-premise. I also participated in wild startups where the releases came twice a month. One last thing – agile is usually more fun, too!