It’s when a team frequently releases it’s product into the hands of end users, always listening to feedback, whether critical or appreaciative.
The frequency is determined by the technical and business needs of the users, but it’s considered to be enough one release every four to six iterations.
To favor technical contexts, such as in Web Development, a more regular rhythm of release can be achieved, such as every iteration. Some teams push this practice to its limits, through continuous deployment.
– Presenting the latest iteration of the product to a manager for “testing” purposes is not enough; nor is handing over a version to the quality assurance team; a “release” in this sense should be at the very least a beta version, evaluated by representative users
– In some instances (such as embedded software) it is not possible to arrange frequent releases to “all” users; this should not be a excuse to give up on frequent releases to “some” users (pilot websites, beta testers, etc.)
Setting up for regular releases “from the ground up” is a cornerstone of Agile’s risk reduction approach:
– Mitigates the infamous planning failure mode of discovering problems very late
– Validates the product’s demand in its market earlier
– Provides early feedback about the quality and stability of the product
– There’s a much quicker return in the economic investement