The Scaled Agile Framework (SAFe) uses the Agile Release Train (ART) concept as a method of value delivery against a funded Investment Theme. A Value Stream is a known or yet to be identified product or service that delivers some value to the organization. In many cases, the value stream involves revenue generating activities, but it may also involve non-revenue generating activities, such as optimizing a process to make it more efficient or making a process safer (no pun intended), or to satisfy some regulation or compliance mandate.
Let’s say there is an online consumer goods marketplace called allthings.com. It has a very successful business on the internet, but is not so successful on mobile devices. In fact, allthings.com has lost overall market share due to the growth of mobile over the last few years. A significant value stream is the web portal. If we dig deeper, we could probably identify additional value streams, but for the sake of keeping this post short and simple, we will assume that the web portal is the only value stream. Now that we have identified the value stream, our investment theme is to make the web portal mobile, with the intent of capturing sales on mobile devices. I should note that SAFe promotes the idea of one theme per train, but I believe that one theme can fund multiple trains because a theme is a container for the dollars we can spend on similar initiatives, like in this example. But more on this later.
Armed with this knowledge, we can identify the Epic(s). I’m assuming that you are already familiar with the epic concept in SAFe. Executives and senior management will decide among tradeoffs. Let’s say the desire is to write Android, Windows Mobile, iOS, and Blackberry applications. If we decided to fund all of these, we could easily create one epic and one or more release trains based on the epic.
Epic includes all mobile platforms considered
But, let’s assume that management is not so sure about the future of the Blackberry platform, and human, time, and financial constraints limit the ability to deliver more than two platforms at once. So the decision is made to proceed with the development of iOS and Android applications and leave Blackberry and Windows Mobile to future initiatives. Remember, epics cut across trains, so simplify where you can. In this case, we create one epic for Blackberry and Windows mobile, which goes back to the Portfolio Backlog and one epic for Android and iOS, which goes into the queue for development and feeds the subsequent release train(s) at the program level. Our investment theme changes too, because an investment theme has a budget and items in the portfolio backlog are not funded yet. The scope of the investment theme is reduced to only include Android and iOS, while a new investment theme for the Blackberry and Windows Mobile applications will need to be created at a later date.
Epics split due to funding decisions
So how many release trains? If we want to minimize risk (in all its varied forms), my suggestion is to create two release trains. Creating one release train would create dependencies among teams working on two different platforms. One release train will operate on the same cadence, so any delay (remember Cost of Delay from Reinertsen?) on either platform would impact the other. In this case, one release train would service the Android platform and the other would service the iOS platform. Ideally these trains would run in sync, but if one were to get into trouble, the other should not be affected.
Release trains based on investment theme and epic choices
In SAFe, the identification of your release train(s) starts with the solid understanding of your value streams and investment themes, followed by breaking the work down into manageable chunks, like epics, that can be economically justified and funded incrementally. These chunks will feed your release train(s) until they can no longer be economically justified. Hopefully the model used here can be extrapolated to your organization and can help you to find your release trains.