I should start out by saying that I am a big fan of Scrum, I think those that devised the framework possessed an agile mindset but also were mindful of human nature. They created a framework that had in built checks and balances and prescribed solutions to many of the most common problems. They also had an understanding of system level thinking – I’ll come back to that later.
The core of the system though are the core roles Scrum Master, Product Owner and Development Team. This triad is what makes Scrum so successful (when it works) and in my opinion it is the absence of this triad that is the root cause of the majority of the unsuccessful adoptions.
It is all about the mindset
However, I don’t think it is the role that defines this triad but the perceived mindset behind the role. Having a team that possesses a strong member with an Agile mindset, and the knowledge and skills to support it and the opportunity to focus on it; having a strong team member with a Customer mindset, a desire to engage the customer and ensure they get what they really want, and finally a cross functional development team with a strong Production mindset – that of delivering a well designed, high quality and maintainable product.
Scrum assigns named roles because they believe this give the best chance of having those mindsets on the team. But sadly it doesn’t guarantee them. There are far too many Scrum Masters that understand the rules, but do not have an agile mindset so create cargo cults and many product owners that build what they want not what the customer wants. And many development teams that over-architect, over-engineer or pay lip service to quality maintenance and even design.
The flip side is that you can create Agile teams without team coaches and without customer representation, sometimes they are very successful. But my assertion would be that on those teams there is someone with an Agile Mindset and calls out the team when they deviate, there is someone or multiple people that make the customer voice heard and engage them often and there is a cross functional team dedicated to building the product right.
In essence I am saying that Scrum fails when those in the named roles fail to live up to the role. And that in cases where a role isn’t named someone or more than one steps-up into that role. But in either case if those mindsets are not present on the team it is a recipe for failure.
Agile is a Mindset not a Rule-set
Scrum fails in essence because we assume a Role is the same as a Mindset. In this case Correlation does not imply causation. There are many great Scrum Masters and Coaches out there who posses an Agile Mindset, but sadly there are also a great many that lack it and see the role as the application of a rule-set rather than the application of a mindset.
System Level Thinking
This failure of mindset extends to the tired old conversation of Scrum Masters (and coaches) making themselves redundant on a team. There is a lot of talk about whether or not a Scrum Master(or Product Owner – or QA or designer etc etc) would be fully utilized on a team. Utilization of resources is a point of frustration for me (Note my deliberate use of the word resources). If you are concerned about maximizing utilization of someone then you are failing to see them as a person or see the value they provide and they have been reduced to counting the number of hours they occupy a seat.
A coach does not become redundant on a team when the team performs their tasks for them, a coach becomes redundant on a team when the team develops an Agile mindset and has the skills and knowledge to apply it without the coach’s help (and even then I see value in a diverse perspective). Utilization should not even be a consideration, value to the system should be the consideration. The same applies to the other roles – PO, designer, QA etc.
It is all in the name
Naming roles on a team is a risk, as I have described above if you get the wrong person it can undermine the balance, there is also a risk of knowledge siloing, and perceived expectations and divisions of labour when you name a role by areas of responsibility.
But far, far more damaging in my opinion is giving names that imply authority. Any type of named leadership role embedded on a team (Manager, Tech Lead, Team Leader, Architecture Lead) immediately stifles opinion and inclusion and undermines self-organisation on a team. Where roles like Scrum Master and PO stifle horizontal knowledge sharing, hierarchy stifles everything – so in my opinion this is far worse. If someone possesses a greater technical understanding there is no need to anoint leadership, it should be self-evident, and if it is not evident to the others on the team then likely the leadership title will subvert rather than support. Equally A self-organising team should not need a team leader or manager.
Ultimately it comes down to balance.
If you believe a team will be able to balance the three essential mind-sets without named horizontal roles, then the roles are unnecessary. If not (and I would err on the side of caution) then named roles give the highest probability of achieving this balance – especially if you have confidence in your hiring team that they are hiring for mindset rather than certifications. Those in the named roles should be sharing the mind-set as much as the knowledge.
But I if you feel there is a need for named leadership roles on a “self-organizing” team, ask yourself why you don’t trust the team to self-organize?
And finally if at any point decisions are getting made based on utilization of staff, in isolation and without consideration to the value they bring to the team. Then read the book “The Goal” by Eliyahu M. Goldratt. It will help understand that a focus on perceived local efficiencies and a desire for maximum utilization can actually be damaging to the larger system. Or read my post on efficiency
John Yorke 
We share a lot of the same opinions, John. I was asked not too long ago what the most difficult part about adopting scrum was. I said it was adopting the mindset. As you said, too many focus on the tools and techniques. I remember a story about Jeff Sutherland teaching MBAs about TPS and they couldn’t wrap their heads around the principles and they too just focused on the tools and techniques. I wonder if its because our culture values “how” over “why” and focuses too much on immediate results.
I’ve wondered if one of our mistakes is using the word “coach.” Are people misinterpreting this? When I hear “coach” it makes me think of an NFL coach pacing the sidelines and screaming at his players. We certainly don’t need that. Perhaps we should use the term ‘teacher’ instead?
Interesting too your opinion on the root problem of non-adoption. I posted recently why my last company couldn’t do it. Not understanding and embracing the roles was certainly an issue.
LikeLike