As part of the Introduction to Scaled Agile Framework series, this article with cover the Scaling Conetx and Some Basic Concepts like where scaling fits and how it works.
Let’s first understand what Scaling is?
As a word, Scaling means there are multiple teams working on a Product (Value Stream).
Scaling Agile refers to the process where the established Agile methods (Scrum/Kanban) are applied to other layers of organization.
Look at the Matrix below to understand the layers of the organization.
In any Project organization the ratio of Product and Teams is:
- 1 Team working on 1 Product
- 1 Team working on Many Products
- Many Teams working on 1 Product
- Many Teams working on Many Products
The Matrix above shows the context of Product v/s Teams.
- When we define a Product – here we define an Independent Value Stream which makes sense from a market perspective.
- When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
- Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts. Scaling is out of scope of Scrum.
- “Many Products – Many Team” context is defined by portfolio management, which is out of scope for most of existing scrum frameworks – SAFe is one of the most prevalent scaling framework that helps with
- “One Team – Many Product” quadrant is for Staff Pools who do heterogeneous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.
Context of Scaling and De-Scaling
When we think of larger products, we can think about descaling – that is, dividing the larger products first into smaller units of independent value streams (Products).
For the above product, the Scrum Context is that for each product (an independent value stream) there has to be a single product backlog, a single product owner and a single development team. Like the below diagram, each team works as an individual Scrum Team with their own “descaled” Product Backlog. There will have to be some considerations made to co-ordinate among the various dependent product backlogs. The diagram shows how the descaled products work.- Spotify is an example of framework which works on the principle of descaling
Context of Product Backlog and Product Owner
There is always a one to one relationship between a Product and Product Backlog and Product Owner. The context of the product backlog is shown below
The following structure where one is NOT OK. The accountability on the Product will go down if the following is implemented. It is better to descale the product instead of having a structure as shown below:
Context of a Product Owner and Development Team in Scaling
A Development team will always look up to Only one Product Owner.
A Development Team looking up to multiple PO means, the accountability is not central and conflicting decisions may come to the Development Team.