Frequent Releases

Release early and often

A guiding principle for Project Chartering and Release Planning is the notion of Frequent Releases. Risk Management is central to the success of software projects. Any team that is building a system for months on end without getting any feedback is taking a big risk. Without feedback, it is entirely possible to build systems that do not meet the customer's needs. When this happens, the entire development time spent in building the wrong feature(s) will count toward wasted time.

Teams mitigate this risk by having short development periods followed by releases that generate feedback.

During Project Chartering, teams decide on the length of one or more releases. Due to market factors, it may not always be feasible to frequently release to external customers. This does not stop teams from getting feedback by releasing internally as frequently as they'd like. At the end of a 3-month internal release, management, customers and developers can get excellent feedback about what has been accomplished. This helps the project community plan for future internal and external releases.

Frequent Releases force teams to focus on Continuous Integration. They need to tackle complex integration issues upfront, and not at the end of development to discover that different modules are not compatible. They must integrate early and often, quickly evolving capabilities that allow automatic deployment to a staging environment, which is an environment that emulates a production environment. This practice helps mitigate the risk of working in a development environment that may differ from an actual production environment. Continuous automated deployment and verification of a system in a staging area removes the technical overhead involved in traditional releases.

Values & Practices

·	Values
·	Readiness Assessment
·	Continuous Risk Management
·	Project Chartering
·	Project Community
·	Test-Driven Management
·	Sustainable Pace
·	Planning Game
·	Storytelling
·	Storytesting
·	Frequent Releases
·	Small Teams
·	Sitting Together
·	Continuous Learning
·	Iterative Usability
·	Evolutionary Design
·	Story Test-Driven Development
·	Refactoring
·	Domain-Driven Design
·	Pairing
·	Continuous Integration
·	Collective Ownership
·	Coding Standard
·	Retrospectives