The Reason Scrum So Often Fails Agile Teams
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.
User Comments
I suppose all three of the issues you mention with SM, PO and team can be leveled st Scrum because the people in those roles are working within a (supposed) Scrum framework. But do we really think those same people, without Scrum, would somehow be proficient at team leadership, customer value, and production mindset? Should we really be claiming it is a Scrum failure that Scrum doesn't, itself, "fix" these people?
Hi Scott, I used Scrum as an example of where the named roles doesn't automatically fix the problem, but that the intent was there to try. I currently work in a non Scrum environment, and I see the same problems, teams that lack ALL of these mindsets in the composition of the team struggle. But when there are three or more people that are able to represent these viewpoints, characteristics and mindsets the teams tend to thrive.
Scrum doesn't fail, just like the rules of chess don't fail. You either play them as the rules state, or you don’t.
https://kenschwaber.wordpress.com/2011/04/07/scrum-fails
That was the point of the article, it said that if you adopt an Agile mindset and apply Scrum -projects are likely to succeed but if you apply the framework of Scrum without understanding why and without an Agile mindset your projects will likely fail. The intent was to emphasise that Scrum is a tool that needs to be used appropriately and only a poor workman blames their tools.
My biggest beef with Scrum is that it adds excessive amounts of overhead. Daily meetings, pre-meetings. post-meetings, planning meetings, estimation meetings. While that all can be counted under collaboration I experienced all these meetings as a waste of time. There was never anything tangible or actionable that came out of these meetings. Worse even, it takes a full time position of scrum master to manage all this overhead. How does that make things leaner?
I admit that those who were in charge had the mindset to "hit it early next sprint", which never happened. Agility was often the reason for indecision and non-committal. They also grossly overcommitted to what the team could do and the team did as well. The problem was, we worked on a brand new project that had so many varying units of work that comparison with prior work was not possible.
The biggest issue with scrum is the artificial time boxing. There are units of work that cannot be completed in an arbitrarily set time. Some things take longer than two or three weeks and no, they cannot be split into smaller tasks that are deliverable.
We eventually ditched Scrum and went to Kanban and three month cycles with standups only twice a week and meetings on demand as needed. We also stopped estimating. There is no value in guessing and in our case consistently guessing wrong. We could have estimated better if we had more up front design and documented requirements, but that is anti-agile. There is this weird idea that once going Agile, the important acts of planning, up front design, and above all documentation are bad. I am convinced we could crank out high quality features faster if we'd given a set list of functions a feature needs to have and which needs it has to satisfy. Instead, we get one and a half bullet points and often not even that.
Maybe we are doing it all wrong, but since we were mandated to be Agile (that was a management decision) our workload at least doubled, stress levels are at 11 out of 10, and we are forced to push stuff out the door that has plenty of known deficiencies. We still hear "we hit it early next iteration" and that just does not happen.
Tell us what you want to have built and we make sure it will work exactly as asked for. Don't tell us and we have to guess, others will give feedback (means "I don't like it!" rather than constructive criticism), and we have to change things, then change again, and then change again. That gets sold as Agile, but it really is nothing else than indecision and the fear of making a decision. That causes features to take longer to be completed and leaves little to no time for bug fixing, refactoring, or redesign. Ultimately, Agile is the death of quality and that while taking as long or longer than other approaches.
Tim, you cover a lot of ground in your comment. I'll limit my response to the content of the article. What you have described as far as I can tell is an agile implementation lacking an agile mindset. I have worked in both Kanban and Scrum (my current role is in a Kanban environment) and both will likely have the same amount of meetings but that relies on the teams understanding why the meetings happen and the correct outcome from the meeting. And crucially adapting and improving with the team extending or reducing the meetings to get the correct outcome. understanding the goal, planning the work and verifying it with your customer are almost essential, but if the same outcomes can be achieved with other methods that is great, but ensure you understand why you have a meeting before you conclude it is unnecessary.
Also Lean is not simply about waste reduction in fact waste is a tertiary consideration, Lean is first and foremost about getting the right outcome (Value), second about improving the flow and only after that is it about eliminating waste, a Scrum Master might be waste, but before reaching that conclusion consider whether they help contribute to value and flow more than the perceived waste you may see. Sometimes there is waste, but more often a good Scrum Master with the right mindset contributes so much to Value and flow that the waste is insignificant in comparison.