A principle (or consequence) of highly iterative software development methodologies is that after the first iteration, the product is always "ready to ship". That is, the product does something useful and is in a releasable state.

This is a great risk mitigator. At any time, if the project is cancelled or its scope scaled back, there will be something of value to show for it. But it also makes it less likely for the project to be cancelled, as a working product is a great demonstration of the project's value and the team's competence.

It is also good for team morale, and for reducing stress. Whatever goes wrong, everyone is confident that it won't be a complete disaster. It's easier to be courageous when you know that "Plan B" will work out fine.

Practices that support this principle are
	* DailyBuild -- build the software every single day
	* RelentlessTesting -- automated UnitTest''''''s
	* SmokeTest -- simple manual tests that can be performed every day
	* FixBugsFirst -- don't let them lurk
	* SingleReleasePoint

To actually ship out a release demands a lot of work and coordination with other groups, so AlwaysBeReadyToShip is more of a DevelopmentStance or an ideal to strive toward than a practical reality.

See also RapidDevelopment

----

''Does this apply to the software's documentation, install instructions, packaging, marketing materials, etc? For most of my career, I've worked for software consulting groups where AlwaysBeReadyToShip would make a lot of sense. Now, I work for a software product company where the scope of '''ship''' is much larger than before and I'm not so sure that AlwaysBeReadyToShip makes sense. How does enlarging the scope of '''shipping''' affect the software development process?''

Shipping a product does involve a great deal of work, by a lot of non-developers. The above principle is focused on the development team's role: they make sure that the software is "done", and do whatever they can to maintain that state. How to integrate this with QA, marketing, manufacturing, packaging, technical support, and other groups within a company is a very complex problem and will vary between products and organizations.

----
Yes, you can make the requirements of completing an iteration include the appropriate documentation, install instructions, ''et cetera''. Doing this provides a bonus: because the user interface / user manuals are always up to date, you can use them as the product specification.

Another bonus: It shortens the feedback loop between the developers, quality control, and marketing.