ProjectConnections Print View
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.
Learn more about ProjectConnections and who writes our content. Want to learn more? Take a site tour.
| Content Levels | |
 | Register for free access to papers, case studies, and over 50 templates. |
 | Subscribe for complete access: $14.95 monthly or $149/year |
| Risk-free 15-day trial!
Compare levels View sample templates Corporate subscriptions | |
Introduction to Software Release Trains
Quick Summary
Key requirements and suggestions for successfully implementing release trains, along with observations and indicators to help you decide if release trains are right for your organization.
What this is
A Release Train is the technique of planning software releases on regular or cyclic time period, for example, the last day of every quarter, or every 9 weeks, etc. The "train" metaphor of a release train is likely based on the concept of railroad train schedules (planned arrival and departure times) and that trains carry multiple types of rolling stock (different types of projects are included in a release).
Why it's useful
- Release Trains can help you manage your development, test, QA, support and release staff resources more efficiently. They can also help manage your investment in capital equipment, tools, facilities and software used by these organizations during the process of development testing and product releases.
- Releases are far more predictable. They are scheduled and released at regular intervals. The time period and predictability become the main drivers, with features possibly deferred to the next cycle if it is determined that they can't make the proscribed release cycle. Note that Release Trains are considered "regular" and follow a periodic algorithm, but they can be implemented as an irregular function also (e.g. 9 weeks, 12 weeks, 9 weeks, etc.).
- They generally support incremental innovation and incremental development. Since the releases have proscribed time periods, larger initiatives will cross release boundaries - either the outcomes of the large initiative will not become part of the product/system until the release cycle in which it is ready. Or, the project plan can release portions of the product or project in one release and portions in future releases. Experience shows that this mode occurs for most organizations, since some project inevitably will take longer than the proscribed short release time periods we're discussing.
How to use it
Release Trains are useful and you may want to consider them if:
- Your clients or customers are demanding more frequent releases of software (they are tired of waiting indefinitely while you try to pack everything in because you don't want to wait until that "next" far-in-the-future release).
- Your clients or customers are demanding less frequent releases (they are tired of the patch or upgrade du jour).
- The development, QA, test or other groups are misaligned as far as allocating their individual group workflows and various groups shift the backlog back and forth between each other. (In other words, it's not one group that's always late, but different groups. One group being consistently late would normally be identified as a resource problem).
- The product has a large user base, rather than a smaller, custom user base, with broader needs and wants. The consistent and regularly timed releases give smaller increases in functionality across the board, leaving no customer niche left out in the cold.
- Something in your environment-customers' situations, clients' needs, end users' wants, etc.-changes frequently. The reasons for this may be rapidly changing markets, rapidly changing technologies, or rapidly changing integration or innovation at the customer site (as examples). Timed releases provide consistency and predictability for accommodating these frequent changes, rather than so many releases with "gotta have it now" dates springing into being ad hoc, driven by particular stakeholders.
Peter Michels has served as Director of Engineering and Program Management, Senior Project Manager, Software Development Manager and software developer in large and small companies with most recent focus in commercial wireless and 802.11 network communications. Pete's professional interests are in project recovery, organizational behavior and organizational restructuring.
It has been commented that Pete has a higher tolerance level than average for negativity, which he explains must be the reason he enjoys, remains in and excels at the project management profession. Pete has also been quoted as saying "almost everything is a project of some sort." Apparently, he uses MS Project for many personal activities too. Pete firmly advocates that schools should teach basic project management along with consumer economics and shop classes. Pete has an irreverent sense of humor and finds a something amusing in most projects or programs. Pete's last team shirts read "If you can't juggle, don't join the Circus" next to a juggling clown logo on a unicycle with the sleeve reading "Ringmaster."
©Copyright 2000-2010 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy