I have recently got the Professional Scrum Master I (PSM I) certification from Scrum.org. During the time I was preparing for it I got to know Scrum better and cleared some misconceptions I had created during my experience as a Scrum Master.

In this post, I attempt to clear some of the things I found that are easy to understand in theory but harder to put in practice, especially when the organization is not 100% sold on Scrum.

Companies think Scrum is a Silver Bullet

Everyone is doing Agile. You want to be Agile, right? Because if you’re not Agile then that must mean you are… clumsy?

Agile gained a lot of popularity since its birth and Scrum (alongside Kanban, XP, and others) became one of the ways companies stride towards agility.

Since Scrum is one of the most popular (if not the most popular) Agile frameworks/methodologies, organizations want to adopt it so they can reap the supposed benefits of being “Agile”. But most of the times they’re not ready to adopt it without making some significant changes in the way they work.

An example which can quickly lead to confusion is the absence of titles in the Development Team. Scrum imposes that people in the Development Team have no title other than simply “Developer”. This is done to (softly) enforce cross-functionality in the team. By removing titles we no longer have a tester or a QA specific person in the team, everyone should be able to perform any task regardless of level of expertise (this doesn’t mean you cannot have specialists).

That’s great and all, but usually companies have a need for hierarchies, especially because they need to justify salary differences. So even if you don’t recognize titles, you will always have a secondary channel where people know they are not the same as their peers, level wise.

This poses a challenge in companies that have teams with mixed levels of experience. If Scrum is not correctly understood and enacted, even though it preaches cross-functionality, having a hierarchy in place may lead to divides between who gets to do what (e.g. only inviting senior developers to road-map plannings, assigning boring/tedious tasks to juniors).

Companies may fail to understand the real purpose of Scrum because they simply want to get on the Agile train for the sake of not feeling left behind. Even though Scrum is usually applied in the context of software development, it is a Risk Management framework at heart. If you think about it, events, inspections, the Scrum Master and Definition of Done are all mechanisms which allow you to decrease the risk of the development process. Organizations need to understand this in order to properly support their Scrum usage and the Scrum Master should be a champion of this.

No commitment with Transparency

Transparency is one of the three pillars of Scrum (alongside Inspection and Adaptation). Transparency is super important because every day, decisions are made based on the perceived state of affairs meaning that making a decision while having incomplete or incorrect information may have severe consequences.

If your company plans work behind closed doors, the people actually performing the work won’t have a complete picture of why they are developing something. This can have consequences which range from lower motivation (because people feel like cogs in the machine) to building the wrong thing (because people didn’t know the original reason behind the task in the first place and couldn’t correctly adapt).

The biggest offender in these scenarios is usually the current status. Everyone wants to say things are done. But what does done mean? This is why Scrum enforces that every Scrum Team must have a Definition of Done that makes the developing of an increment possible. A developer can say that a certain feature is done and what he truly means is that he has finished the development and is now testing when some stakeholder assumes that done means deployed to production.

Company culture is directly tied to transparency and the way things work. This article explains how culture is directly tied to employee behavior. A group of influential people in a company got together to figure out next steps and future plans. A coach asked them “what does a person need to do in order to be promoted?”. Once everyone pitched in with ideas that ranged from “be proactive” to “always be available”, the coach finally said, “here’s your culture”. If you need transparency then it must be a behavior enacted by leaders and that trickles down to every rank of the company.

Make sure transparency is a priority and make sure people have room to be honest and don’t fear backlash when presenting bad news.

Refinement is not done properly

Refinement is the only activity prescribed by Scrum which doesn’t have an event associated with it. The way refinement is done is at the discretion of the Scrum Team. Scrum only prescribes that refinement should not take more than 10% of the time allocated to development.

With this being said, teams can easily fall into one of two traps, creating an extra meeting to perform the refinement or not doing refinement at all and doing it ad hoc in the Sprint planning session.

If you create a meeting specifically for refinement you may have too little information at the time of the meeting in order to properly refine the Backlog items. You can also be inviting people who are already on board with what you are refining so they might not take full advantage of the meeting. You also make it harder to adapt to things that need to be refined between the meeting and the next planning session.

If you do all the refinement in the planning session then blockers may rise which can halt the planning since there isn’t enough information to properly plan/estimate.

The solution here is to refine as you go. Small refinement tasks can be performed by one or two developers with the help of subject matter experts if necessary. It doesn’t always need to be a group exercise. If refinement is always a group exercise, having an hour and a half refinement meeting (for a two weeks Sprint) already breaks the 10% allocated for the refinement.

The Scrum Master is the “Team Manager”

The Scrum Master is not the team manager. It is too easy for the Scrum Master to fall into the trap of handling the tasks that should be shared by the Development Team such as communicating the progress of the Sprint or updating the board. The Scrum Master should be the warden of the processes, the one who makes sure things are being done, but this doesn’t mean he should be the one doing so.

Being the “Team Manager” may lead the Scrum Master to do other types of mistakes such as moderating meetings and taking over some of the Development Team’s responsibilities. I have made this mistake in the past.

The solution here only comes through knowledge and experience. The Scrum Master must know what his and the Development Team’s responsibilities are and act accordingly. He must educate himself and the Team about Scrum.

Not crafting Sprint Goals

One of the core elements of the Sprint Planning meeting is to come up with a Sprint Goal. The Sprint Goal is something that exists alongside the Sprint Backlog. The Sprint Goal is a sentence which represents the overarching goal for the Sprint, something that makes the team understand what they’re working for.

In theory, it makes perfect sense. Since Scrum is best used when working with some degree of uncertainty and/or innovative products, sometimes the items in the Sprint Backlog may become obsolete, although the task encapsulated it the Sprint Goal may not.

An example could be something like: “Deliver a seamless experience when signing into the app”. A “seamless experience” is something subjective. The Team might strive towards improving the performance of the login page at the beginning of the Sprint only to understand, halfway through the Sprint, that the Goal can be achieved simply by using social logins. The Sprint Backlog will be reworked but the Sprint Goal remains.

Not using Sprint Goals decreases the flexibility of the Team because the Team will limit itself to develop what is in the Sprint Backlog without thinking of the bigger picture.

Making Feature Factory teams use Scrum

Feature factory teams are teams whose main job is to pump out new features with little to no regard about amassing technical debt, refactoring and inspecting previous work. The success of these teams is measured in the number of features they are able to produce.

These types of teams should make use of other development frameworks (or use none at all) such as Kanban because making these teams use Scrum will just lead to burn out:

• Even if they don’t finish a feature by the time the Sprint ends, that feature will always be the one they start working on the next Sprint. There’s usually little to no re-evaluation of priorities in these scenarios.
• Sprint Retrospectives and Reviews are usually a waste of time because there’s little room to inspect and adapt, might as well be working on newer features.
• If priorities are clearly defined by the business, estimating makes no sense. There’s no need to estimate something if the order of the features to implement is not subject to change.
• Your developers will feel they are living in a lie because they know they are using Scrum just so the company can say it’s Agile.

---

Side Note: PSM I Study Material

The PSM I assessment is an 80 question test where questions are either true/false, multiple-choice or multiple-selection. It is one of the most renowned certifications and doesn’t require you to attend a workshop.

I studied/used the following resources:

• Scrum Guide
• Scrum Narrative and PSM Exam Guide Book
• Scrum.org Open Assessments
• Mikhail Lapshin’s Mock Quizzes

If you are able to score consistently above 95% in the practice tests then you’re ready to undergo the PSM I exam.