A simple software project with one developer working on it, perhaps it is you and your open-source project, does not need an elaborated description of its progress. In fact, the state of your project can be binary, either it is still in development or it is available for the public consumption. But once the team grows, the complexity increases, and the project starts to become an amalgamation of a few subcomponents, the clarity around the development status, particularly towards its release, is crucial for all the involved stakeholders.
A development milestone marks a specific point during the duration of the software development. For a development team with a strong project management culture, the date/timestamp of each milestone is important and kept in the record. Those dates are useful for a few different retrospective analysis.
Perhaps it is not difficult to imagine that the opposite, a team without much orientation around its release engineering process, will exhibit various symtoms. The most obvious is the lack of authoritative status of the actual project. Is it beta? Is it preview? Is it already GA? What is even the definition of all those? And no, GA does not stand for Generally Alpha. It is also often the case that nobody can provide a definite answer as to when the release is going to happen. If you ask the tech lead, the build engineer, and the product manager, you might end up with 3 different answers (or worse, more than 3).
How to instill such a proper culture? First and foremost, the stewardship of the release process must be explicitly nominated. This is the role often called as the release manager. In some places where the project is intertwined in another set of big activites, sometimes the role is known as the program manager. In practice, it does not matter who performs this stewarding role. It could be the product manager, one of the experienced engineers, one of the junior ones, or even an intern, as long as that person is wearing the “release manager” hat while doing the duties.
Next, it is equally important to have a complete definition of each development milestone. A short version of the definition could be a list of conditions which will be fulfilled when the development already reaches that particular milestone. Any stakeholder familiar with the project should be able to perform an objective evaluation of those conditions.
For this illustration, imagine a small software team which releases its product every quarter, where every release is going to a small set of milestones: Feature Complete (FC), Code Freeze (CF), Release Candidate (RC), and General Availability (GA). The diagram demonstrates the development phases along with the milestones.
For this team, the checklist for the Feature Complete can be formulated as follows:
- A release branch must be active in the Git repository
- All third-party dependencies must be up-to-date
- There must be zero regression in all unit tests
- The test plan must be approved
- There must not be any more P1 issues
Then, perhaps the Code Freeze’s criteria will be quite similarly defined:
- A release branch must be made restricted for further check-ins
- There must be zero regression in all integration tests
- The test plan must be completely executed
- There must not be any more P0 issues
Based on these two milestones, it becomes clear that the Stabilization phase, which happens between after FC, has the goal of pushing the progress towards CF. The release manager, or whoever is playing the role, is crucial in ensuring that everybody in the team has the CF’s criteria in the mind and working towards that. While it might be blindingly obvious, having the definition of both FC and CF written down somewhere and made explicitly known to the team gives the benefit of avoiding any possible ambiguities. If an engineer is not sure what to do during this Stabilization phase, first they can use this agreed definition as the guidance.
For complete, the Release Candidate milestone, the last one before the final GA, might look like the following:
- Every known issue and breaking change must be reported
- The user documentation must be up-to-date
- Blog post for announcement must be finished
Naturally, the above list will steer the tasks during the final checks towards the GA milestone.
The milestones, along with the definition, will vary across different organization, depending on the scope of the project, the size of the team, and other factors. To make sure that every team member and every stakeholder will be as aligned as possible during the development, it is paramount to come up with the lightweight and agreed-upon milestones, the respective definition, and the process to follow them faithfully.
Do you document your development milestones? Does everyone in your team understand the process? Please share your thoughts and experience!