Release trains, the technique of planning releases on a particular date several times a year (such as quarterly releases, on the 12th of the last month of the quarter), can help you manage your development and test staff as well as machines and tool resources. I wrote about release trains a while ago here. If you’re suffering from these problems, consider a release train:
- Your users want more releases of the software and you can’t figure out how to release faster to release more often.
- Your users want fewer releases of the software and you don’t want to maintain too many releases.
- Developers are stomping on each other’s code, in service to separate projects. Or, if the developers manage through the configuration management system not to stomp, the merging is difficult.
- You have many small projects, all of which require significant development and testing resources.
- The testers feel as if they can’t make progress on their testing, that they keep testing the same products over and over because the products keep changing due to the small projects.
Here’s what you need to make release trains work:
- A program manager who reports into the people who determine the corporate-wide initiatives, the reasons for doing all these projects. The program manager manages the release criteria, the project managers, and whatever corporate-level issues need managing to make each release successful. The program manager determines if something is going to miss a particular train and if it should be postponed to the next train. The program manager helps each project maintain its cohesion and reduces coupling between projects.
- Project managers for each project for each of the trains. Each project is a significant effort, so requires at minimum a technical lead, and more likely a project manager to make sure the developers and testers (and the other necessary staff) estimate and deliver their work on time. The project manager has to ensure the developers do no more than necessary. YAGNI, You Aren’t Going To Need It, isn’t just for agile projects, it’s for all projects. The project managers have to be close enough to the project to understand the inevitable tradeoffs and discussions of what’s in and what’s out.
- Great configuration management, both the tool and the release engineers, so you can have up to four simultaneous codelines and the developers can still build to get exactly the sources they need. The release engineers will have to merge the codelines into the mainline too, in case you need to make a patch separate from the next release. (But don’t do it, unless the lack of a patch means corporate death.)
- Enough estimation ability by developers, testers, project managers, and any other project staff to be able to estimate the necessary work, so you can meet your projected release.
- Ability to develop enough automated tests for regression testing. A release train is a combination of an iterative lifecycle, with increments for each release. You’re guaranteed to change the same modules again and again. If you don’t have enough automated tests (and I don’t have a number I can give you), you won’t be able to release when you want to.
Release trains help you manage all your resources, because you can group similarly-sized or similar-impact projects together into one program. Because there’s one program manager whose job is to satisfy the execs or other corporate stakeholders, one project doesn’t “win” over another project. The sub-optimization that can occur at the project level can’t occur in the program, or the program doesn’t allow the train to release on time.
Software release trains aren’t the only answer. Using agile techniques also help manage resources. If you use agile techniques, your projects are more likely to complete on time. But if you don’t see how to make agile techniques work in your environment, try release trains. They are more like traditional projects, which may mean other people will accept them more readily.