To get grounded on what the Small Value Stream (SVS) pattern looks like, I will describe what SVS’s (1 – 4 teams, roughly 7 – 35 team members) look like.
First, let’s describe some examples of business value streams at a financial services company so you can get a flavor for the problem set:
- Deposit Services – business aligned to checking, savings, and CD products
- Deposit Operations – business aligned to back-office processing of deposit product features, such as check deposits, ACH processing, etc.
- Home Loans Acquisitions / Sales – business aligned to marketing of and acquisition of mortgage customer applications
- And so on….
Second, there is the matter of scale. For medium-sized companies, the IT investment in their products does rise to a level that you still need to be concerned with how to scale agile delivery. However, you are generally talking about IT shops with 100’s of team members rather than 1000’s. This does not preclude the potential that the SVS pattern might be present in larger companies. However, you will generally find that larger companies, due to their scale, will have 6 – 12 teams dedicated to each value stream much like the examples given above. In SAFe terms, that is about the right size for an Agile Release Train.
Third, the business intent for these SVS’s are most often not connected to each other. Therefore, they can create and maintain vision documents, roadmaps, and program backlogs that are mostly independent from each other and that allows them to make faster, local, and more adaptive product decisions. There are occasions, more the exception than the rule, where program level program initiatives need to take precedence over the SVS’s local priorities. For example, re-branding the website or an architectural shift to a new database version or system. For these broader initiatives, coordination of priorities and feature backlogs across each of the affected SVS’s is required to make these program deliveries happen.
Fourth, as an optional element of the SVS pattern, the technology stack (presentation tier, service layer, and back ends) for any SVS might be heavily shared across multiple SVS’s. So, while the business intent is mostly independent across SVS’s, there is a common set of platforms and components that are updated by teams in many SVS’s. As further optional element of the SVS pattern, these updates by many SVS’s could combine into a common, synchronized release that happens at a predictable cadence.
So, the SVS pattern emerges because: 1) the scale of each value stream is relatively small, 2) their business intent is rarely connected across value streams, and 3) optionally the technology stack is shared across value streams.
Therefore, for example, elements of SAFe, like the “all team members on board” Release Planning event, do not seemingly help the majority of value delivery across 20-50 teams. Can I realistically expect to get 300+ people in the same room for 2 days? Probably not. And if you could, would such a meeting have any chance of being effective? Definitely not. But what about those rarer program initiatives that do cut across multiple SVS’s – how do we get them delivered? In a future article, I will describe how SAFe, in a slightly modified execution at the Program Level, could be used to aid in the delivery of these larger program initiatives. As a preview of that article, here’s a picture that introduces Small Value Stream Product Management and accompanying Vision, Roadmaps, and Backlog for each SVS.
You might be saying, “Do we really need another layer?” Well, the highest majority of product management planning is happening within each SVS regardless of the broader Program Level planning. Therefore, the SAFe Program Level Product Management is relatively lightweight and provides a binding structure for getting those rarer cross-SVS initiatives delivered. I will spend more time explaining this flow in the future article.