Major Pitfalls of Scrum

Scrum Master: “Good morning! Let’s start. Who wants to start?”
Dev: “I can start.”
Scrum Master: “Go ahead!”
Dev: “Yesterday, I started with a new task, TC-13385. The API that was promised to us is still not working, so I’m kind of waiting…”
Scrum Master: “Cool! Any impediments?”
Dev: “Eh, no impediments…”
Scrum Master: “Great! Who wants to be next?”

Scrum. Almost every software engineer has heard of it, experienced it, or even suffered from it. Since the year 1986, when the “Scrum” word was first introduced in the context of product development, followed by Agile Manifesto that was published in 2001, it has spread to universities, digital agencies, automotive industry (where it all began), and beyond.

Lots of companies, from lean start-ups to large enterprises, have adopted Scrum in the belief it would help them build productive, self-organizing teams. And many succeeded, often despite their modest training — overcoming some minor misfortune, they found themselves driving their projects in the right direction.

Yet, like with any effort that involves a human factor, things can easily turn for the worse — projects get suspended, people burn out, and their contribution fades away. Zombie Scrum begins to manifest to a full extent.

There is one thing about agile — if it goes wrong, it goes horribly wrong. Whatever the root cause is, the result is always the same — mediocre product and frustrated teams.

Since I have a good recollection of many cases from my former jobs when Scrum didn’t work as smoothly as anticipated, I tried to summarize the most frequent pitfalls any agile team might fall into. Let’s take a look at them.

Pitfall #1: Insufficient adoption

Bad adoption is quite common, especially among start-ups. Someone reads something about Scrum, starts using the Scrum vocabulary, but never really asks the question of “why”. You can’t copy-paste something that works somewhere else and expect it to work like a charm. Managers like to tout their things as silver bullets that work no matter what, although it is rarely the case.

Scrum and Agile in general should be thought as a mindset, rather than as a mere set of principles. If people look at Scrum as a rigid process, they will only follow rules for the sake of following rules. This should not be taken lightly.

There are three pillars of the Scrum framework — transparency, inspection, and adaptation. You measure data, inspect the progress, and continuously improve the process, until it fits your circumstances.

Instead of “We do it because the book says so,” it should be “We do it, because we followed the recommendations, and during our regular retrospectives, we came to a conclusion that it worked out well.”

Pitfall #2: Lack of freedom

Very often you can see companies that hire people for a narrow set of responsibilities they are supposed to carry out. Designers design, managers manage, developers write code, and no one truly cares about the delivered product. Experimenting is neglected, as it would introduce unnecessary risk to the project — the very definition of the Assembly Line.

In addition to that, if the team has no part in deciding what, how, and when to deliver, they will never contribute to any initiatives, and the purpose of the product will fade from their understanding.

High productive teams get to choose which features to commit to, they own the features they deliver, strive to master their craft toward a great purpose, have a great deal of autonomy to decide what is best (i.e., choosing appropriate technologies to work with), are free to experiment, and encourage cross-functionality.

Pitfall #3: Isolated developers

Many people who started their career at companies of dubious business models have built a certain mindset which dictates not to spend their time on anything that is not invoiceable. No pair programming, no onboarding, no retrospectives, just 100% delivery. These people are very difficult to turn into an Agile mindset.

They come to the office in the morning, open a list of tasks, pick up the first one, start working, pick up another one, and so forth. Finally, before the day ends, they book their time for each respective ticket, and go home. Period.

There is a well-known discrepancy between great individuals and great teams, as I have put in one of my previous articles. If someone’s productivity goes through the roof, it doesn’t mean this person is a great asset to the team. A team full of isolated yet productive workers will have a multitude of issues.

For disintegrated teams:

• it will be very difficult to onboard a newcomer to the team, as they will have no intention of helping him/her. You never learn by doing things alone.
• quality and transparency of the product will be negatively affected.
• once a new sprint has started, there will be a fight for “good tasks”. Indeed, I have seen this many times.
• lack of purpose will turn into lack of care — there will be no response to failure or success.
• every individual will have their own Definition of Done, varying from “Works on my machine” to “Accepted by the Product Owner”.
• communication will suffer, resulting in cases where the team delivers X while the Product Owner asked for Y.

For integrated teams:

• every newcomer will have a dedicated mentor who will help him/her to become a great asset to the team.
• quality and transparency of the product will be reinforced.
• once a new sprint has started, the team members will pick up tasks as per their competencies.
• the team will care about the direction the project is driven into.
• the team will agree upon their own Definition of Done and every member will stick to this definition.
• communication will be taken seriously — if someone is unclear about an objective of a task, the rest of the team will provide a clear understanding.

Pitfall #4: Dysfunctional teams

Teamwork is powerful yet rare. Still, it’s of the greatest importance for any Agile process. If the dev team doesn’t perform well, that’s where the Scrum Master comes into play, identifying issues and helping to find suitable solutions, even exchanging team members, if necessary.

Scrum defines five values: focus, respect, commitment, courage, and openness. On the other side, there is a book The Five Dysfunctions of a Team, which points out to the opposite of those values: inattention to results, avoidance of accountability, lack of commitment, fear of conflict, and absence of trust. If you happen to experience some of them manifesting in your team, I’d strongly recommend to read this book I mentioned in my previous article.

The most successful teams are autonomous and tightly integrated. They trust each other, enjoy each other’s company, and hold each other accountable. They understand the necessity of common effort, the importance of transparent communication, and the power of teamwork. Moreover, they do care about who will join their team.

Dysfunctional teams don’t recognize the importance of learning, the importance of team buildings, the importance of retrospectives. They are just there to “do things”. No assistance, no growth. No action, no progress. No purpose, no satisfaction.

Pitfall #5: Intrusive Product Owner

Stand-ups that degenerated into a mere show of productivity, new tasks smuggled into an already running sprint, backlog review done during a sprint planning, I need this to be finished today attitude, estimations treated as deadlines, Product Owner who asks respective team members to give an immediate, random guess, and the list goes on.

There are certain rules that should be enforced by all means. And if you want to do Scrum, you should do it on that basis or not at all, which all falls into Scrum Master’s jurisdiction. If the Product Owner tries to circumvent the basic rules of Scrum, it’s the Scrum Master’s responsibility to intervene.

If the PO changes the AC after acceptance, introduces new tasks during planning, or asks the team to work overtime, the Scrum Master must stand behind the team.

Scrum Master is the last line of defense between the Dev team and other stakeholders, and if there are any signs of potential conflicts, actions must be taken instantly.

Pitfall #6: Bad-performing Scrum Master

Here we arrive at last — the most common and most overseen pitfall of Scrum, the Scrum Master himself/herself.

There is a significant difference between managing, micromanaging, and bossing around. Scrum Master is an agile team manager, a happiness manager, a coach, and a protector. His/her sole responsibility is to make the team tightly integrated and committed to their work while removing road-blockers along the way. He/she is there for the team, not for the product — this falls primarily under the responsibility of the Product Owner.

In many bad cases, the Scrum Master is a mediocre resource manager who just organizes meetings, assists with grooming, and drags around user stories.

Giving someone the responsibility of holding scrum ceremonies doesn’t make them a Scrum Master, for the same reason as to why giving someone the responsibility over the French fries section in a fast-food establishment doesn’t make them a chef.

Managing teams is immensely difficult, and unless you had a really well-crafted upbringing in your childhood, you couldn’t have adopted all virtues to be an emphatic leader by nature. It takes years to learn the craft.

Next to a bad-performing Scrum Master, there are several other cases that are equally worrying.

No Scrum Master. I have experienced this before —Berlin, one project, two teams, three Product Owners. A team without a Scrum Master is almost 100% guaranteed to fail, as there is no shield between the Dev team and other stakeholders. The developers then turn into a headless chicken mode, unable to perform well.

Scrum Master “The Janitor”. There is one thing that is equally bad as a a Scrum Master who doesn’t do anything for the team —a Scrum Master who does everything for the team. Pressing all buttons, watering flowers, and removing every road-blocker along the way. If such a person leaves the team, its performance will immediately slide. A great leader is a leader who effectively trains his/her staff so that they could aspire to run their own teams one day.

Dual-hat Scrum Master. Scrum Master is a specific, isolated role. There shouldn’t be any other roles for the same person. If it was so, he/she would be either too busy carrying out either, or worse, there will be a conflict of interests.

If the Scrum Master is also a Project Manager, guess what happens when the client asks for additional features. Scrum Master’s attention is directed toward the team, while the Product Owner’s attention is directed toward the product.

If the Scrum Master is also a developer, he/she will likely fall back into his/her technical role every time he/she notices any sign of pressure. In addition to that, doing both programming and management often results in either both roles being carried out badly, or one being sharpened at the expense of the other.

Conclusion

Scrum is easy to learn but difficult to master. There are many pitfalls and hurdles to jump, but once you have overcome all of the struggle, you can achieve a great strategic advantage over your competitors.

As mentioned before, a healthy scrum boils down into a simple flow: deliver fast, collect feedback, improve, and repeat. If you want to go Agile from scratch, surround yourself with the best mentors you could possibly get, ensure that every stakeholder gets high-quality training, and hope for the best. There are no ways of doing Scrum that would guarantee you success, but there definitely are ways that will guarantee failure.

A committed, self-organized, and tightly integrated team is not something you can buy, that’ the beauty of it. You have to put a tremendous effort to build such a team. Scrum will not make your team work better. Your team must make your Scrum work better!