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.

The template requires a free Member account
Please log in to download the file. Don't have a log in? Register now, it's fast and free!
Log in to download this file


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.
About the Author

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."

The template requires a free Member account
Please log in to download the file. Don't have a log in? Register now, it's fast and free!
Log in to download this file


©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.