Gfrktyl

I am new to the Scrum domain and recently found a "Scrum at scale" workshop near my town. I am a software engineer more inclined to data science. How would scaled Scrum help me become better in managing projects with many stakeholders, and how is it different from standard Scrum?

It would not help you with multiple stakeholders.

Scrum is already meant to deal with multiple stakeholders (and a single Product Owner consolidating their needs into a single prioritized product backlog). Scrum at scale is meant to help you with projects so large that you need multiple teams.

If you want to know how to better cope with your stakeholders, a Product Owner training would be the better choice.

TL;DR

Scrum@Scale is a specific framework developed by Jeff Sutherland and Scrum, Inc. for scaling Scrum beyond a single team. More generally, scaled Scrum (or "Scrum at [enterprise] scale") refers to the frameworks and practices required to apply Scrum concepts across multiple teams, which is often a requirement on very large or complex enterprise projects (e.g. "at scale").

Standard Scrum already handles multiple stakeholders. Scaled Scrum frameworks target programs with multiple teams. Managing stakeholders is a the function of the Product Owner in standard Scrum, but may be part of other roles (or even belong to entire teams) in other frameworks.

The Problems

At heart, Scrum is a framework for developing a product from a singular Product Backlog serviced by one unitary Scrum team. Over time, various approaches to scaling Scrum beyond a single team have been promoted within the agile community. Regardless of the framework, they all attempt to solve one or more of the following problems:

• Management of very large (or even multiple) backlogs.


• Cross-team estimation practices.


• Resource leveling across teams.


• Inter-team communications.


• Multi-product architecture.


• Multi-team and multi-product integration.


• Executive/stakeholder resource limitations.


• Portfolio management across a complex set of programs or projects.


• Metrics and reporting for multi-team efforts.

This is not an exhaustive list, but the theme of "multiple teams" is one that Scrum doesn't natively tackle.

Survey of the Scaled Scrum Landscape

Various frameworks and scaling mechanisms that are used to scale Scrum beyond a single team include:

• Scrum-of-Scrums


• MetaScrum


• Nexus


• Scrum@Scale


• Large Scale Scrum (LeSS)


• Scaled Agile Framework for Lean Enterprises (SAFe)

NB: SAFe uses Scrum at the team level, but is arguably not truly an attempt to scale Scrum itself at the enterprise level. Instead, it uses other mechanisms and frameworks at different organizational levels. Whether you include it in "scaled Scrum" is a matter of taste, but as one of the more well-known scaled frameworks I chose to include it here for completeness.

Other agile approaches such as Lean, Kanban, DevOps, and so forth are not included in this list as they aren't inherently based on Scrum. Nevertheless, the issues of scaling are often present regardless of the framework, and must be addressed in any multi-team or multi-departmental approach to agility.

Well, in my opinion, "scrum at scale" is trying to grapple with the real-world issue that – yes, in my opinion – "scrum is an over-simplification." Understand this, and you'll be fine. "Scrum" has many useful ideas for project and team organization, but it rather likes to preach.

My advice is simply: "use Scrum," because it is indeed useful, but "don't entirely believe it." Sip the kool-aid but don't drink the entire jar. Keep it in perspective.

Real-world software systems commonly "touch" many different organizational departments and activities, and interact with other projects in ways that impose hard constraints that no single team can solve, or necessarily even see. Of course this does not obviate the value of a "scrum" organization and workflow within that team.

"Scrum at scale" argues that scrum-style organization should nevertheless be applied at multiple levels, so that different "scrum" teams are managed in a "scrum" fashion until one "über-scrum master" rules them all. I will candidly express my opinion that this is effectively nonsense. The methodology, in my candid opinion, "does not scale," and ought not be expected to do so. Due to the time and expense inherent in all software projects, plus their over-arching influence upon the business as a whole, "this is what we have vice-presidents for," and it is why their decisions are always compromises.

=== EDIT:

In an attempt to clarify the above-expressed opinion as to "why Scrum cannot or should not scale," at Todd Jacobs' request I will now add to my previous comments without eliding them.

I would now make the observation that all projects are defined with scope-and-boundaries within which management hopes that the "Scrum" methodology will produce satisfactory results in the appointed budget and time, and with acceptable business risk. But, if we then attempt to apply "scrum" at higher levels within the organization, we quickly reach levels of abstraction and levels of concern which impact the business as a whole, and for which the (inherently risky) "exploratory methods" championed by "Scrum" are no longer applicable or even safe. This is what I was alluding to when I said, "that's why we have vice-presidents, and that's why their decisions are always compromises." They don't make their fuzzy high-stakes choices based on the same principles that "scrum" holds dear – they can't, and they shouldn't.

Real-world projects are often interlocked with other projects by technical, business, business-risk and financial concerns that can't be changed, so each project must be architected to consider them. Scrum-based teams then work within those determined boundaries in an earnest effort to self-select and self-optimize their activities.

However, careful delineation of these boundaries – which is not left up to the team – is in my opinion an essential part of the reason why "scrum" is perceived to be a workable strategy. It is in my view a micro- strategy but not a macro- one.

It is, one might say, a "risky" approach, but when that risk is well-constrained it might prove to be a benefit. But if the same concepts are then elevated to higher levels within the organizational tree, I believe that these risks become untenable. We already know how to let executives make decisions at those levels. My opinion is that we should let scrum, instead, "bloom where it is planted, and where it sometimes does bloom," namely, at the leaves of the organizational project-tree, making each project's outcome the best that scrum can make it be.