One practice that I have come to believe is important is to have regular releases of software that is reviewed by business stakeholders. By regular I mean every 2 – 6 weeks. These do not have to be full production releases, but they should be to at least a staging or beta platform that business stakeholders can use as if it were the final product.
Regular releases are important for two reasons.
- Business stakeholders get to see and provide feedback on the product long before it’s complete. Anything that is going off track can be identified, and fixed earlier, which means for inherently less cost than if found later.
- The development team becomes practiced at releasing user ready software. If business stakeholders use the released version it must meet a certain level of usability and quality. If a team only releases once a year, or even less frequently, they are performing a task they do not do often, and most likely do not do well.
We have been releasing every 2 – 4 weeks on the current project I am on and it is working very well. Through this process we have been able to very quickly react to the requests of our business stakeholders, and we are also very good at releasing updated versions of our software.
Regular releases also help teach a team to stick to a schedule, since the releases themselves become the back bone of the schedule. In short I believe it’s helpful to release early and often to those business stakeholders who will eventually decide if what you’re working on was worth it to them.
There are some caveats to the above. A blog post form another blog about this same topic has a comment that points out it might be a bad idea to release early and often for software that has life and death implications. I would agree with this when it comes to shipping products for market use in those fields. I wonder if internally it doesn’t make sense to do frequent releases to QA or internal business stakeholders though as a matter of process. For medical or navigation software I would completely agree final releases should be thoroughly tested and ready.
Here’s another post from a different blog about releasing early that talks about the pros and cons if you are trying to market your product in a stealth like manner. It makes the point that getting feedback from people who are not your real potential users may not be helpful. I would agree and many times QA or internal business stakeholders are not the real end users, and their feedback may lead to features and changes the eventual end users won’t like. I think releasing to internal folks as a proxy to real end users would be better that not having any interim releases at all, in at least you know you are making progress towards a final release that is measurable. The post brings up some really interesting marketing aspects I’d never really thought of since I am mostly in the code these days.