Small Value Stream (SVS) pattern organizations have the largest portion of their product development flow starting locally with intent generated from within each SVS. Therefore, we can optimize the planning within any SVS by using the Vision, Roadmap, and Program Backlog elements of SAFe by localizing these concepts to each SVS. However, there are rarer, but important, program-wide epics that require coordinated flow and planning across multiple SVS’s and their associated teams. I first introduced the following picture in the second article in this series. It depicts the business intent flow between the Program and SVS Levels in an SVS organization.
Let’s dig into the picture a bit, starting at the top. For those rarer Program Level features that cut across multiple SVS’s, the Program Level Product Management team is responsible for managing the Vision, Roadmap, and Program Backlog at the Program Level (depicted in blue). The Program still needs to manage business features along with architecture features (depicted in red) that are applicable across multiple SVS’s. The SVS-Level Product Management team (one for each SVS) is responsible for managing the Vision, Roadmap, and SVS Backlog at the SVS Level (depicted in green). Depending on the needs and priorities at the Program Level for the next PSI, the SVS Level Roadmaps and Backlogs will be informed by those Program Level priorities. Additionally, an allocation model developed for each PSI will be utilized to determine the apportionment of the Program Level features vs. SVS Level features for each SVS. Those SVS’s, and their associated teams, that are heavily allocated towards Program Level features for the upcoming PSI (like SVS # 1 above) will be fully involved in the Program-Level Release Planning event at the start of each PSI. These SVS’s can still plan for delivering some SVS Level features in that PSI but they will focus their attention and priority on the Program Level features during Release Planning. SVS’s and teams that are slightly impacted or not impacted at all by Program Level features (like SVS # 2 above) can send proxies (such as Product Owners) to the Program Level Release Planning event rather than sending all team members. Therefore, when considering SVS and team allocations for Program Level features, it is better to have SVS’s and their teams mostly involved or mostly uninvolved with the delivery of program features so that there is clarity of participation in the Release Planning event.
As expected from SAFe, the participants in the Release Planning event will produce a set of PSI/Release Objectives and a PSI Program Plan. Those Objectives will mostly include the Program Level objectives but can also include any notable SVS Level objectives that should have visibility at the Program Level. The majority of SVS Level objectives will not be included in the Release Planning’s Objectives since they represent planning that is primarily done sprint-by-sprint (or PSI-by-PSI if that is preferred by the SVS) solely within the teams of that SVS.
Regardless of a particular SVS’s participation level in the Release Planning event, all teams within the Agile Release Train will still gain the lean benefits from a common cadence (i.e., 2-week sprints and 8-12 week PSI’s) and synchronization across all teams.
The System Demo held at or near the end of every 2-week iteration still holds the same value in the SVS pattern organizations. The System Demo should be concentrated on the PSI/Release Objectives and no significant time spent demonstrating any local SVS objectives which can be targeted in a separate demo aimed towards the local SVS stakeholders. Similarly, the Solution Demo, as part of the PSI’s Inspect and Adapt workshop, should be concentrated on the PSI/Release Objectives.
For SVS pattern organizations, the Program Level is really the most impacted level in SAFe. The next article will describe the Portfolio Level of SAFe applied to these organizations.