I just completed revisions to our Software Development Methodology handbook. It got me thinking about how many times I have written something like this and how its changed over the years.

As would be expected from a Software as a Service company, we approach things from an incremental development and update perspective.

We look to deliver new features every 6 to 8 weeks. We have a product roadmap which is a living and breathing organism. At the beginning of each year, we sit down (representatives from Marketing, Client Services and R and D are all there).

We look at the Roadmap and work out what is needed for the following year.

Once we satisfy this objective we then proceed to work out what is needed in the first 6 to 8 week iteration. As we release each cycle, we review the roadmap and determine the requirements for the following cycle.

This is the reasoning for my post title. At no point do we ever say our product/service is functionally complete. Back in the days of on premise software, we would pursue the venerable Waterfall approach. We would map out and plan for a development project of 12 to 18 months, aiming for at most 1 release per year. Users wouldn’t even get close to the new version until it was close to being "functionally complete" as a product. I would remember our customers/prospects getting all excited by some great new feature we would show them in a presentation, but a year is a long time in business, and by the time the product update was officially released, all the positive "vibes" and excitement of the initial announcements would have truly been forgotten.

By having 6 to 8 week feature updates, we are continually registering small wins with our customer and prospect base and keeping strong the goodwill of those customers. It also makes the term "functionally complete" an anachronism. A service should always be evolving and adapting. If you wait for 12 to 18 months between releases, your product will die a slow death.

A guest post by Troy Wing – CTO for Forcelogix