What kind of self-organization is meant by design in Scrum when it comes to Scrum teams? - reference to Richard Hackman's model from "The psychology of self management"

Self-management facilitates empiricism and bottom-up intelligence. The higher-ups are expected to listen rather than tell. If there's a design principle at work, that's it.

Ian - thank you for a reply, yet please clarify

Which one is that in reference to the model that I've posted?
- obviously not manager-led teams, right. Right?
- self-managing teams?
- self designing-teams?
- or self governing teams?

Also, you seem not sure about whether there is any design principle, why so? If you're not sure then can it be that there is no design principle behind Scrum? 

That would be weird considering Schwaber's "Scrum Project Manager" idea way back from 2004. Plus previous works by Schwaber & Sutherland and possibly more people.

 

The Scrum Guide refers to self-managing teams. Not manager-led, or self-designing, or self-governing, so that's the reference to use. There's no mention of a design principle, although the Guide clarifies that Scrum is founded on empiricism and lean thinking, while the Scrum framework itself is contextualised as the core design of Scrum.

OK Ian, thank you.

For some context - I teach people in ITIL4, SAFe, Prince2, DevOps... the list goes on.

Sometimes I encounter situations where people have problems with basic words like "incident", "issue", "problem", so on. 

In ITIL4 and other bodies of knowledge such words are keywords - they have only one particular meaning.

Guess how that helps in learning a different body of knowledge where same keywords are defined differently?

I know that when I took Project+ exam from CompTIA I had problems as I'm kind of invested in PeopleCert body of knowledge. 

It was, um, a challenge of sorts to put it in a neutral way.

Hence my question. 

Either semantics are defined... or not. If not, then interpretation creeps in. It works for DevOps with Three Ways and CALMS, also for SRE, but somehow when it comes to Scrum it results in a mess.
 

I do appreaciate the problems around different terminolgy within the language of different certifications.

As mentioned Scrum teams, by design, fall under self-managing teams as specified in the 2020 Scrum Guide. Scrum Teams manage the work, not the organisation. They decide how to achieve the Product Goal, but not what the Product Goal is (that’s for the Product Owner). They don’t govern themselves independently of organisational constraints or stakeholders.

This maps directly to Hackman’s “self-managing” team level — autonomy over execution but not over strategic direction or membership.

While the Scrum Guide doesn’t cite motivational theory, its structure clearly reflects empowerment theory (in terms of self-management) and goal-setting theory. If Scrum got to this point empirically and independent from theory or not, I cannot tell. So this is speculative. However, as is known, self-management promotes autonomy and ownership, while Product and Sprint Goals provide focus and measurable purpose. Together, these principles create a motivated, engaged, and outcome-driven team — which is the designed aim of Scrum.

Essentially, the Scrum Guide only describes work at team level. Consequently, the role of management (excluding the Product Owner and Scrum Master) remains undefined. In a company consisting of only one Scrum team, the Product Owner (PO), who is a member of the Scrum team, sets the overall direction, while the Scrum team is responsible for everything else.

The Scrum Guide makes only a few statements about a larger corporate context. For instance, it states that 'For Product Owners to succeed, the entire organisation must respect their decisions.' In this case, the PO formally sets the overall direction. However, these relate to the product level.

--

As the Scrum Guide only refers to a single team working on a single product, the Authority Matrix is not fully applicable here.

The bottom two levels — 'Executing the team tasks' and 'Monitoring and managing the work process and progress' — are clearly at the development team level.

The first part of the third level, 'Designing the team', is also clearly assigned to the team.
However, the second part, 'Designing its organisational context', if referring to the organisation outside the team, is influenced by the Scrum Team, particularly the Scrum Master. Therefore, the team's responsibility is not negated. In discussions around the Scrum Guide, management's accountability for facilitating a suitable environment is often mentioned.

The fourth level, 'Setting overall direction', is clearly the accountability of the Product Owner at product level (who, as mentioned, is part of the team). However, discussions around the Scrum Guide also mention that product-overarching directions are the accountability of management.

I am not a professional Scrum trainer, so you might think that this is not an official statement — and you would be right. But perhaps my thoughts will help you answer your own question.

Thank you all for your answers. So as Scrum ideal model exist withouth defining external context, then logically there needs to be some external management. 

As Benedikt mentioned, Scrum model spans only one team. 

This is interesting, as with Schwaber's "Scrum Project Manager" model - Scrum Team would be self governing in reference to Hackman's model - Product Owner role would focus on business, Scrum Project Manager would focus on managing the whole context around a Scrum Project (solving problems, talking with board, so on) and team members would well, do the work. This approach simplifies things as there is one leader with authority and power (a Scrum Master) who connects with the broader context and can protect scrum team from external harmful influences. Other managers would have problems with bypassing such setup. 

On the other hand Scrum Master role that is not a "Scrum Project Manager" sets the Scrum Team at self-managing level and the path to managing context lenghtens and is complicated - seeking approvals instead of making a managerial decision, pleading for this or that, so on. This complicates things as there is not one leader with authority and power, is mostly bound to a team level as a facilitator and cannot realistically protect scrum team from external harmful influences - as employees do not order managers around. Other managers can bypass such a setup with ease.

Hence second option is not sustainable.
 

Not to deviate from the original question, but a quick perspective.
The 2020 Scrum Guide updated the description of the Scrum Master from a servant-leader to a leader who serves, reflecting conversations with the authors, Ken Schwaber and Jeff Sutherland, and a shift toward emphasising the leadership aspect of the role.

Schwaber’s 2004 book Agile Project Management with Scrum predates the clearer role definitions that were later formalised in the Scrum Guide. The “Agile Project Manager” described there is closer to a traditional project manager in a predictive context, not the facilitative and coaching role of the modern Scrum Master.

Within a Scrum Team, the Scrum Master leads by guiding adherence to Scrum principles and by fostering self-management.
At the organisational level, the Scrum Master acts in part as a change leader, helping the organisation understand, adopt, and support Scrum. This includes working with other leaders to remove systemic impediments and guiding the shift from command-and-control to empowerment, trust, and decentralised decision-making.

Ultimately, the choice is organisational: if a company wants hierarchical control, a traditional project manager is appropriate. But if the company wants adaptive value delivery through empowered teams, a Scrum Master provides the leadership model designed for that purpose.

Thanks Pierre, I'll try to keep it short as I am kind of tired with this Scrum linguistic spaghetti that is going on for years.

A leader - https://www.merriam-webster.com/dictionary/leader

"a person who has commanding authority or influence" 

Well, look, a Scrum project/initiative/product/endeavor/whatever manager once again.

And this is not even cherry picking on definitions.

You know that a theory is lazy when people need to look up dictionaries to decipher its meaning... I mean interpret it.

"Ultimately, the choice is organisational" - ah, the essence of Scrum theory part, shoving responsibility on someone else, like always, and then if it somehow works - ascribing the credit for it. The method is perfect, people are not! Oh, such depth.

No thanks, I have my own brain. Though thanks for your reply, I appreciate it.