Eighty percent of people who are using agile today use some flavor of the Scrum Framework. As you can imagine, there is a lot of variance in how Scrum is applied, and some people who use Scrum in ways that are not recognizable. People make up rules and have had beliefs about Scrum that qualify as “alternate facts” or more politely, Scrum Myths.
If only there was a standard for Scrum.
But wait, there is a standard for the Scrum Framework and that is the Scrum Guide. The Scrum Guide is maintained by Jeff Sutherland and Ken Schwaber (the creators of Scrum) and it is considered the definitive reference for the Scrum Framework.
At only 19 pages, there is no reason not to read it. And internalize it. That is if you are among the 80% of agile practitioners who use Scrum.
Most Scrum users have never bothered to read the Scrum Guide. Hey, reading is overrated! They assume or project things into Scrum Framework (or not in it) based on what they want to believe. Or they don’t care what the guide says and they adjust Scrum in ways they think will make it work better for them.
Here are a few beliefs about Scrum or Scrum Myths that have come up recently:
Like the official fact-checkers in today’s political climate, I set out to actually read the Scrum guide and to confirm or debunk these Scrum beliefs.
RATING: FALSE
I am not even sure where to begin with this one. How is it possible that people feel that it is more effective to send an email vs. conduct a short focused meeting?
Here is what the Scrum Guide says about the Sprint Review:
RATING: False
This was one that I heard during my Disciplined Agile (DA) training earlier this year. The instructor said that Scrum Practitioners won’t even talk to you about training or coaching if you don’t have dedicated teams.
I have long been a proponent of both dedicated teams and co-located teams, having seen firsthand the efficacy of having people in the same room working on the same product. Sadly, I was in the minority and this was prior to the 2020 pandemic. Globally, about 20% of teams were co-located with 80% using a remote or distributed team approach. I imagine that since the pandemic, almost no one is co-located. and that is likely to be the future.
However, the Scrum Guide doesn’t say anything about dedicated teams. In the words of one of my favorite Scrum experts, Craig Larman, “Scrum is Silent” on this issue.
As I noted in my review of the Disciplined Agile certifications, I thought that Disciplined Agile did a lot of unnecessary Scrum-bashing. At the same time, they are dogging Scrum about being out of date, using weird terms, and being too prescriptive, they also claim Scrum as their own. That is, they include Scrum within DA and say that if you are using Scrum, you are already using DA. Huh? It seems that DA wants to have their cake and eat it too.
RATING: Mostly False
This myth came from a comment on a blog that I wrote about the role of the Business Analyst in Scrum. The main point of my blog post was that in my experience, BAs like to operate outside the team, or do only BA work and that is inconsistent with the idea of having no specialists or sub-teams in Scrum.
That blog post has attracted the most comments and most of those comments are critical of what I wrote, claiming it to be too purist and not real-world enough.
The comment that triggered myth #3 was: “The Scrum Guide DOES mention BAs, and as part of the team…”
It got me scratching my head and wondering what I might have missed. I went back to the Scrum Guide and searched up business analyst.
Nothing.
I searched up business analysis and this came up:
“Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, “
Does this qualify as the Scrum Guide mentioning BAs? In addition to stating that there is no sub-teams, the Scrum Guide describes the Development Team as self-organizing and cross-functional.
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”
RATING: FALSE
I include this one because it seems to be a point of contention for new teams. Not only planning poker, but estimating techniques in general. As the saying goes, the Scrum guide is silent on Planning Poker.
The Scrum Guide does mention the need for estimating and the importance of product backlog items being estimated. But it does not include planning poker.
It doesn’t include user stories either. Or epics.
No user stories in Scrum??? Epic! I’ve witnessed so many team debates over what is a user story and what is an epic to the point where a recent client asked for a template to write an epic. Wait, what? [See my related post: How to User Story]
In fact, there are numerous topics that cause debate and friction among teams first learning to use agile and Scrum. NONE OF THESE ARE IN THE SCRUM GUIDE!
RATING: FALSE
False false false. Oh where do I start with this one. I guess first of all, each job requires different skill sets and the responsibilities are different.
Good project managers COULD become a Scrum Master if they worked at becoming servant leaders who fostered self-organization. Unfortunately, the task master type of PM who gets things done and makes sure everyone is doing their job is likely to fail as a Scrum Master. The best Scrum Masters have a zen like quality. They intervene infrequently and teams seem to do fine without them.
Read more about differences between Project Managers and Scrum Masters in this post: Project Managers Make Lousy Scrum Masters
This post included a few recent myths that I have learned of. I am sure that I missed a few. What are some of the myths that you have heard about Scrum?