A note from the authors of this paper, Stephen Walters and Dr. Craig Statham:
"An excellent question was asked of us by Krishna Kumar on reviewing this paper. He asked, “[H]ow analyzing team types helps in identifying/visualizing value streams?” and it was felt that this explanation of how we came to write this paper would be useful.
We went right back to basics. Each of us was seeing a need. For Craig, it was hard to visualize the value streams that existed in his organization. He saw that planning of work with complex dependencies between the teams was difficult. The question of “who do we need to work on this new feature” was a constant frustration. For Stephen, when he spoke with customers about Value Stream Mapping there would always be 2 questions: What is a value stream? How do I identify my value streams?
The first question was always relatively easy, but the second never so, and was key to Craig’s dilemma. The end point would always be a "Product team" and the value stream would be their CI/CD pipeline. Because of the engrained cultural view of DevOps implementations that everything should be a product with a product manager and everyone should collaborate because we don't want silos, this leads to many problems.
- Team identity and responsibilities are blurred to make every team seem the same doing things the same way (Mid-tier stickiness)
- A monolith would break down into micro-services that all collaborated and so became tightly coupled to create a monolith of micro-services (Conway's Law)
- Toolsets would be made up of a huge sprawl of tools that left Value Stream Data and views fragmented and unreadable (Toolchain sprawl)
This meant that when you did a Value Stream Map for a "Product": the responsibilities would be blurred, as would ownership, meaning no-one had clear responsibility for delivery vs internal support; There would be a lot of team dependencies but focus would only be on the team that the mapping was being done for without considering the impact to the rest of the organization; Tools would be looked at as only the ones being used by that team and from a functional perspective and not a measurement or visibility perspective.
These were the problems that both Craig and Stephen were seeing reflected in these real organizations. Our problem was that everything up to then about identifying value streams was subjective - what felt like a value stream. We needed to find an objective, scientific way to identify the organizational structure (which because of Conway's Law, would be reflected in the architectural structure). So we went back to basics and looked at Team Topologies, where the first thing we realized is that most organizations don't even know what their existing team types are. Teams that they think are stream-aligned are also performing platform activities, and enabling activities - the team responsibilities are blurred which means focus is being taken away from value add for what should be a stream-aligned team.
So how can you identify a value stream when the teams involved in the value stream don't even have an identity either? The primary team, as Skelton and Pais say, is the stream-aligned team. This is where your Value Stream flows, but that flow is supported by the complicated subsystems, platform and enabling teams in your organization. But again, what are they?
Applying Graph Theory allowed us to look at the flow and then from that determine the team types, as shown in this paper, using graph centralities of Pagerank and Betweenness. Now that the teams have an identity, we can see the primary driver of flow (The stream-aligned team) and determine their support mechanism (The complicated subsystems, platform and enabling teams). We now have a view of the true Value Streams we support in our organization today.
When this analysis was tested on a sample organization, the number of stream-aligned teams fell short of their expectation. Their CVR (Cost Value Ratio) was very low because the ratio of stream-aligned teams to other team types was low. There needed to be more focus on delivery for the customer rather than internal delivery which can be a cost sinkhole.
So in short, the TLDR; is: how is it possible to identify your value streams if the teams that make that value stream flow don't have an identity. Providing a team identity allows for Value Stream identity. That then allows for the value stream to be identified and visualized."
