I've been going through the site looking at the Scaled Professional Scrum resources, and comparing this framework as sensibly as I can with scrum.org's Evidence Based Management.
Although EBMgt is applicable to a wide range of scaling conditions, I wonder if SPS is more restricted in its potential. The key constraint is perhaps the "Nexus" which provides its underpinning. The assumption seems to be that multiple teams can draw work from a shared Product Backlog, and SPS appears to imply that enterprise scaling matters can be framed in these terms.
In other words a Nexus seems to assume the existence of a product or value proposition that has achieved scale, or is rapidly achieving it. The Scrum Teams that form an incipient Nexus respond to that condition. Since product scalability is never really in any doubt, teams arguably play in a field of clover that is tilted towards success.
However, most organizations at scale do not actually build software at scale, and the playing field for their developers is irregular and boggy. Software supports what these enterprises do, but it isn't what they do, so there is little pressure to scale these products. They may have scores of internal applications and obscure bits of middleware, each discrete element of which rarely involves more than one development team in its creation and maintenance. The numbers on these teams are at the low end, three developers or so being the norm. To enterprises like this, a Nexus is as irrelevant as a shared Product Backlog.
The difficulty these organizations face isn't one of scaling teams to support scaled products. They aren't mature enough in terms of agile development to enjoy that class of problem, and they may be in lines of business that don't place value on such artifacts anyway. Their challenge is one of understanding the most basic of agile practices, while applying them at the scale they have achieved in the business they happen to be in. These include the financial, retail, and transport sectors, a whole raft of public bodies, and many SME's.
The concerns they harbor might be elementary, but they are still "enterprise scale". They include:
- "How do we staff one team without robbing another?"
- "How do we support BAU as well as development work?"
- "Why is predictability so poor?"
- "How can we get rid of this technical debt?"
- "Why don't our projects deliver the value we hoped for?"
- "How can we get the I.T. Department to be more efficient?"
- "How can we get Business off our backs?"
- "How can we get other people to change?"
- "Where does product ownership reside, and how far can we compromise it?"
- "How can we change agile practices to fit the reality and greater pragmatism our organization is built on?"
Some of these concerns are reasonable and obviously some aren't. The point is that these organizations are on an agile journey, each one is larger than just one team, and none are remotely interested in having a scalable product that would justify a Nexus, and which would give them a shared, product-focused scaling narrative. For them, perhaps Evidence Based Management offers more than Scaled Professional Scrum does.
Although EBMgt is applicable to a wide range of scaling conditions, I wonder if SPS is more restricted in its potential. The key constraint is perhaps the "Nexus" which provides its underpinning. The assumption seems to be that multiple teams can draw work from a shared Product Backlog, and SPS appears to imply that enterprise scaling matters can be framed in these terms.
In other words a Nexus seems to assume the existence of a product or value proposition that has achieved scale, or is rapidly achieving it. The Scrum Teams that form an incipient Nexus respond to that condition. Since product scalability is never really in any doubt, teams arguably play in a field of clover that is tilted towards success.
However, most organizations at scale do not actually build software at scale, and the playing field for their developers is irregular and boggy. Software supports what these enterprises do, but it isn't what they do, so there is little pressure to scale these products. They may have scores of internal applications and obscure bits of middleware, each discrete element of which rarely involves more than one development team in its creation and maintenance. The numbers on these teams are at the low end, three developers or so being the norm. To enterprises like this, a Nexus is as irrelevant as a shared Product Backlog.
The difficulty these organizations face isn't one of scaling teams to support scaled products. They aren't mature enough in terms of agile development to enjoy that class of problem, and they may be in lines of business that don't place value on such artifacts anyway. Their challenge is one of understanding the most basic of agile practices, while applying them at the scale they have achieved in the business they happen to be in. These include the financial, retail, and transport sectors, a whole raft of public bodies, and many SME's.
The concerns they harbor might be elementary, but they are still "enterprise scale". They include:
- "How do we staff one team without robbing another?"
- "How do we support BAU as well as development work?"
- "Why is predictability so poor?"
- "How can we get rid of this technical debt?"
- "Why don't our projects deliver the value we hoped for?"
- "How can we get the I.T. Department to be more efficient?"
- "How can we get Business off our backs?"
- "How can we get other people to change?"
- "Where does product ownership reside, and how far can we compromise it?"
- "How can we change agile practices to fit the reality and greater pragmatism our organization is built on?"
Some of these concerns are reasonable and obviously some aren't. The point is that these organizations are on an agile journey, each one is larger than just one team, and none are remotely interested in having a scalable product that would justify a Nexus, and which would give them a shared, product-focused scaling narrative. For them, perhaps Evidence Based Management offers more than Scaled Professional Scrum does.