When considering the Program Level of SAFe applied to Small Value Streams (SVS's - see the first article in the series for an introduction to SVS's), I will describe SAFe elements that "work out of the box" and those challenges that SAFe brings and solves for SVS's.
First, let's look at a working model for an Agile Release Train, or ART, for an SVS pattern organization. As I described in the first article in this series, an SVS pattern organization, we might have 10 - 20 SVS's all working on a connected technology stack with each SVS having 1 - 4 teams. Therefore, we are talking about 20 - 50 teams contributing to the codebase for the next release, assuming we average about 2 - 2-1/2 teams per SVS. The SVS pattern ART then requires these SAFe elements across all SVS's to frequently release software across the 20 - 50 teams:
- Release Management - The SVS ART still needs a governing set of stakeholders who ensure the release content is technically sound and coordinated to be a viable set of business intent. Because there are many SVS's, we might need to proxy in the Release Management team to represent the combined interests of all business lines. Often, this representation can come from the business that is the closest proxy for the customer - like the Sales or Marketing business.
- Shared resources, including User Experience (UX), System Architect (SA), and Release Train Engineer (RTE) - Because the SVS's are often connected by a common technology stack and deliver combined releases, all of these shared Program Level roles are critical for making the Train run. A UX team ensures the user experience remains consistent across the deliveries from the 20 - 50 teams. Similarly, the SA ensures lean governance of existing and evolving architectures in the design and code delivered by the teams, as well as works with the teams to maintain an architectural runway. And most critically, the RTE makes sure the success of all elements of the upcoming release.
- System Team - We still gain enormous value in an SVS pattern organization by centralizing the System Team functions such as configuration management, continuous integration, end-to-end automated test governance, and environment management. If staffed liberally, we can more economically provide all of these important services to the 20 - 50 teams with little to no wait times for servicing the needs of all teams. Additionally, we can provide key governance on these delivery elements to ensure the release gets out the door reliably.
- Inspect and Adapt (I&A) workshop – All of the elements of I&A still apply for SVS organizations. There is real value from the solution demo, quantitative measurement, and problem solving aspects of the I&A workshop. Due to the release orientation of the SVS organization, this I&A workshop provides the venue for focusing on release or program level continuous improvement. For practical purposes, we will have representation from each of the teams attend the I&A workshop rather than trying to have 150-400 team members all in the same room.
- Economic Prioritization – All of the existing aspects from SAFe for prioritizing work based on the economics of product development flow using WSJF (Weighted Shortest Job First) are still wholly applicable for SVS organizations.
So, for SAFe at the Program Level, we have not yet covered Roadmaps, Vision, Feature Backlog and Product Management. The SVS's develop most of their business intent independently from other SVS's. However, we still need to get those rarer, but very important, program-wide epics and features delivered. I also have yet to cover the topics of Release Planning and Objectives. Since these topics are really the crux of using SAFe in an SVS pattern organization, I will devote the entire next article in this series to these topics.