Reasons Why Scrum Can Fail

If Scrum and Agile approaches are supposed to increase the chances of success for software development projects, not all the projects that want to use Scrum are successful. In some organizations, Scrum is a failure. This article discusses why Agile projects might fail because of the confusion between the Scrum roles (Scrum Master, Product Owner, Developer) of a Scrum Team and the required Agile mindsets.

Author : John Yorke, Agile Coach, WWT Asynchrony Labs, http://www.asynchrony.com/

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 built-in checks and balances and 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 key 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’s All About the Mindset

However, I don’t think it is the role that defines this triad but the perceived mindset behind the role.  For example, 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 it all help achieve a proper mindset. Furthermore, having a strong team member with a Customer mindset, who has a desire to engage the customer and ensure they get what they really want also aid in achieving a strong team. And finally, having a cross-functional development team with strong Production  mindset – that of delivering a well-designed, high quality and maintainable product is also essential.

Scrum assigns named roles because they believe this gives 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. This can lead to creating cargo cults with many product owners who build what they want and not necessarily what the customer wants.  In addition, there are many development teams that over-architect, over-engineer or pay lip service to quality maintenance and even design, which decrease the chances for team success.

The flip side is that you can create Agile teams that are very successful without team coaches and without customer representation. But my assertion would be that on those teams there is someone with an Agile mindset who calls out the team when they deviate. There is also someone or several people who make the customer voice heard and who engages with them often. In addition, 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. This can also include cases where a role isn’t named or when someone or more than one person 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 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.

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, QA or Designer, 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 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 diverse perspectives). Utilization should not even be a consideration, value to the system should be the consideration. The same applies to the other roles – product owner, designer, quality assurance, etc.

It’s All in the Name

As I have described above, naming roles on a team is a risk. If you get the wrong person it can undermine the balance. 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 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-organization on a team. Where roles like Scrum Master and Product Owner stifle horizontal knowledge sharing, hierarchy stifles everything. 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 the leadership title will likely subvert rather than support.  Equally, a self-organizing 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 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 Agile mindset rather than certifications. 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 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 you to understand that a focus on perceived local efficiencies and a desire for maximum utilization can actually be damaging to the larger system. Or you can also read my blog post on the meaning of efficiency in Agile.

About the Author

John Yorke is an Agile Coach at WWT Asynchrony Labs. He assists with the company’s development teams, and is a former Scrum Master with more than 20 years’ experience in software development. This article was originally published on https://yorkesoftware.com/2016/08/14/why-scrum-so-often-fails/ and is reproduced here with permission.