Scaling Agility is a huge topic right now, with many different methods available. Most of these methods are based on Scrum and/or Kanban, so I thought it would be interesting to discuss what the scaling ‘problem’ actually is…
First, let’s take a look at a single Team (all Teams referenced in this blog can use either Scrum or Kanban), with a Product Owner and a collection of Stakeholders. The basic concept is pretty simple, as we see here.
- The Product Owner works with the Stakeholders to develop a Product Backlog, which is a prioritized list of Results that the Stakeholders want from the Team.
- The Product Owner works with the Team to refine these Items into (smaller) Work Items that are placed on the Team’s Backlog, which is usually either a Sprint Backlog or a Kanban Board.
- The Team does work from its Backlog to produce Results, which the Team and Product Owner review with the Stakeholders.
- Based on the review, the Product Owner works with the Stakeholders to update the Product Backlog, and the process repeats…
This process is simple, and its purpose is to enable the Product Owner to maximize the value of the Results the Team produces for the Stakeholders.
So, What Happens When We Scale?
Well, the obvious scaling is when there are multiple Teams working on one Product Owner’s ‘stuff.’ However, that’s not the only scaling we could have. We could also have multiple Product Owners, each with his/her own Product Backlog representing their own Stakeholders.
There is actually a many-to-many relationship between Backlogs and Teams, as we see here. (click image to view larger)
The Scaling Problem is to optimize the overall value provided by the Organization to its Stakeholders, and this takes a lot of agility in many different areas. Here are some of the issues that arise:
- Deciding what to do next (across all the requested Results), and which Team should do it.
- Combining the various Teams’ work into reviewable Results, since many Teams could work on the same Results.
- Providing feedback about the Results to all the Teams involved in its development.
- Making sure the Teams are aligned in their thinking about how to do their work – especially the Teams working on the same Products.
- Moving work from one Team to another when priorities change – which could be quite frequently.
The bottom line is this: when you are looking at scaling methods, ask yourself some questions, including:
- “Does this method allow for multiple Teams AND multiple Products?”
- “Does this method allow for frequent changes in priority?”
- “How does this method assure that all people involved are aligned and in sync with what is important?”
Ready to acquire advanced real-world skills to scale Agile?
Sign up now for our 2-day intensive Agile Scaling Professional class.
Be careful out there. And, As Always, Stay Agile.