We all know what a Scrum Team looks like, right? There’s a Product Owner, a ScrumMaster and a Development Team. In this simple picture, the ScrumMaster is connected to the Development Team.
When a Scrum Team gets too big, you need to have a way to scale it. As we’ve said before, scaling is never easy. Whether scaling your family, business or Scrum implementation, complications have a way of growing exponentially alongside your efforts. Understanding the complexities of multi-Team environments and communication is critical to the successful scaling of Scrum.
Over the years, Scrum frameworks developed to tackle the inherent complexities of scaling. One such framework is Large Scale Scrum (LeSS), developed by Craig Larman and Bas Vodde. In LeSS, the basic idea is to add multiple Development Teams to a single Scrum Team, as shown here.
Now, the Scrum LeSS is scaling is an ‘old’ version of Scrum, so there are caveats: 1) each DevTeam commits to its Sprint Backlog, which is ‘locked down’ during the Sprint; and 2) the PO is not allowed to ‘bother’ the DevTeams during the Sprint.
These caveats were very common in Scrum 10-15 years ago, when Scrum was used purely for (straight-forward) Development. Since then, Scrum has changed – for various reasons. Some of the most important ones are:
- DevTeams often have a need to update/change/re-prioritize their Sprint Backlogs during a Sprint. This happens for many reasons; one of the most common is that they are doing Dev/Ops and have a need to fix bugs as they come up…
- DevTeams would discover additional work while they were working on an Item, and they’d have to decide if the new stuff should be done now or later. This is a prioritization issue that requires PO intervention…
- The work was not predictable enough for the DevTeams to accurately predict how much work would fit in the Sprint. This often led to a conflict between meeting a commitment and actually getting to Done…
If any of these issues occur on a LeSS Team – and I’m sure they will in real life – the PO will have a need to work with the DevTeams during the Sprint. Since LeSS says the Product Owner should not do it directly – and the PO is likely to be spread too thin to do it anyway – the Product Owner will have to work with representatives from the Development Teams in order to get (and give) information to the Development Teams.
Invariably, this leads to the establishment of Proxy Product Owners (PXY), who are Development Team members who work with, and are held accountable by, the Product Owner, as pictured here.
Proxy Product Owners were all the rage in 2002 through 2004. It was all you heard about at conferences. In 2005, I was with Ken Schwaber and the majority of Scrum Trainers at the time, and I asked the question, “Is the Proxy a part of Scrum? If not, let’s figure this out…” Well, we talked and talked, and concluded that the Proxy was actually the Product Owner of the smaller team, and that the original Product Owner was a Chief Product Owner (CPO), or something like that. Personally, I think that this makes the phrase “Product Owner” confusing. (I would prefer Team Captain, or Squad Leader or something similar.)
Now, in current scrum, the original Product Owner needs a Scrum Team to be a Product Owner of. The natural thing, since the problem is communication with the lower-level teams, is for the Product Owners of those Teams to be the Team Members of a management Team. A new framework emerged, one in which the fundamental unit (The Scrum Team) remains intact, yet scaleable. We named this new framework Scaling Scrum with Scrum (SSwS), as shown here.
And, there you have it – from LeSS to Scaling Scrum with Scrum!
Looking for more real-world skills to Scale Scrum with Scrum? We’ve got training for that.
Think your Team could benefit from some real time observation, feedback and recommendations from our Scrum experts on how to apply Scaling Scrum with Scrum? We’ve got coaching for that.
As Always, Stay Agile.