I should start by saying that I am a big fan of Scrum. The people who devised the framework possessed an agile mindset but were also mindful of human nature. They created a framework that had built-in checks and balances and solutions to many of the most common problems. They also had an understanding of system-level thinking.

The core of the system, though, is the three key roles: ScrumMaster, product owner, and the development team. This triad is what makes Scrum so successful—when it works. However, in my opinion, it is the absence of these three roles that is the root cause of the majority of unsuccessful adoptions.

3 Reasons Scrum Fails

Scrum assigns named roles because this gives the best chance of having those mindsets on the team. But, sadly, it doesn’t guarantee them. Based on my observations, the three main reasons Scrum fails are due to each role failing to adopt its key mindset.

1. There are far too many ScrumMasters who understand the rules but lack an agile mindset. This can lead to creating cargo cults where teams follow the rules without adopting the principles of Scrum. Those teams will never understand why they follow the guidelines, so they won’t be able to improve. In these environments Scrum is used to control development rather than enable it.

2. Product owners who lack a customer mindset build what they want and not necessarily what the customer wants, or blindly deliver what is asked for without understanding why it is needed, or, worst of all, do not regularly review the evolving product, missing opportunities to react to the customer’s emerging needs and impressions. The result is a product that misses the mark.

3. There are many development teams that lack a production mindset and will over-architect, over-engineer, or merely pay lip service to quality, maintenance, or even design, all of which decrease the chances for team success. This will likely manifest itself in the team doing unnecessary or unimportant work to simply keep busy. Developers miss opportunities for delivering the right solution because they are busying themselves with work that has little value to the customer.

The Mindsets Are Essential

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, along with the knowledge and skills to support it and the opportunity to focus on applying it, helps the team focus on continuous improvement and developing agile practices. This is the purpose behind having a named ScrumMaster. The role supports the need for focus and explicitly seeks out someone with an agile mindset as a primary skill. It is a conscious decision to explicitly place that mindset on a team.

It’s also crucial to have a strong team member with a customer mindset, who has a desire to engage regularly with the customer and ensure the customer gets what he really needs. This is the purpose of a product owner, and again, the named role allows the person in that role to focus and removes any conflict of interest that might otherwise occur. This provides the time and space to do the job well.

And finally, there must be a cross-functional development team with a strong production mindset toward delivering a well-designed, high-quality, and maintainable product that is right for the customer. To do this you must understand lean and systems thinking, and not simply keep busy writing code. Understanding the value of the work is far more important than maximizing utilization.

It is all three mindsets together that achieve the goal. If any one mindset is lacking, the whole team will suffer.

It's All in the Name

Naming roles on a team is a risk when the people in those roles lack the right mindset. If you get the wrong person, it can undermine the balance, remove the conflict, or lack vital thinking. There is also a risk of having knowledge reside in a silo, thereby causing perceived expectations and divisions of labor when you name a role by areas of responsibility.

But far more damaging is giving names that imply authority. Any type of named leadership role on a team (manager, tech lead, team leader, architecture lead, etc.) immediately stifles opinion and inclusion and undermines self-organization on a small team.

Where roles like ScrumMaster and product owner may inhibit horizontal knowledge sharing, hierarchy stifles everything. 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 the leadership title will likely subvert rather than support. Equally, a self-organizing team should not ever need a team leader or manager. Roles like ScrumMaster and product owner are not about authority—they are about a mindsetand ensuring that mindset is included on a team. Ultimately, they may become less important once the appropriate mindset is established, but the “lead” title only causes harm in a small cross-functional team.

It Comes Down to Balance

If you believe a team will be able to balance the three essential mindsets 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 and for being a team player rather than just certifications and expertise. Those in the named roles should be sharing the mindset as much as the knowledge.

But if you feel there is a need for named lead roles on a small “self-organizing” team, ask yourself why you don’t trust the team to self-organize.

And finally, if at any point decisions are being 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: A Process of Ongoing Improvement, by Eliyahu M. Goldratt and Jeff Cox. It explains the concept of system-level thinking and will help you understand that a focus on perceived local efficiencies and a desire for maximum utilization can actually be damaging to the larger system.

Agile Is a Mindset, Not a Rule Set

In essence, Scrum fails because we assume a role is the same as a mindset. There are many great ScrumMasters out there who possess 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. Whether your team needs named roles or not, make sure you have the three essential mindsets crucial to an agile team.