Unnecessary functions

Myth: We are agile now. We don't need Testers any more.
Variations:

• Testers = Business Analysts, SysOps, Project Managers ...

Follow-up myths:

• Cross-Functional developers

Category: Development team myths
Danger: High

The basis of the myth

The Scrum Guide clearly states that "Scrum recognizes no titles for Development Team members other than Developer", and some people who don't continue reading fail to understand that this does not mean "We fire everyone who doesn't code."
Without proper consulting when introducing Scrum, some organizations are tempted to do exactly that. Especially the inherent "hate" for project managers in the Scrum community drives even some veteran Scrum coaches/trainers to state that these should be removed as quickly as possible.
In some teams, we run into the problem that -especially testers- are disdained for being of little value.

Why is it a myth?

Continuing with the Scrum guide, it also reads, "Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."
This pretty much means that the definition of "Developer" is different from how traditional organizations understand "development", i.e. "writing code".
A Scrum developer might be a specialist for test, coordination or analysis. The real issue here is whether they are taking special or team accountability: Scrum knows no individual accountability.


Assumption #1: Development = Coding
The smallest part of development is creating the code. Having the right focus, the right idea, the proper design, high quality and sustainability are all in the book. All these affect the success of development, and in Scrum, the team takes care of all of these. Scrum teams do a lot more than just coding.

Assumption #2: The developers can do it!

It's not like when you utter the words "Scrum", some magic happens and your coders instantaneously get all the skills your other members of the organization specialized in for years. They are still necessary. Do not remove necessary functions from your organization. Otherwise, you're setting up your team up for failure.

Consequences

2-class system

Some companies rush headlong into declassifying anyone who is not a "developer" as non-value-adding resource. Oh, this is so much of a mindset problem. You trained these people, you set up your organization to reward their specialization, and now you make it their problem that they did what used to be right for you: They are still as valuable members of your organization as before, but their role has changed. Again, just because someone does not write code, does not mean they are not a developer in the Scrum sense: How about teams that don't even create software?

Belief in magic

There are usually reasons why you used to have specialists. Having them work against each other, rather than collaborate, does not make sense. But don't believe that Scrum magically makes some people superheroes by stripping others of their hard-acquired skills and transferring it into others' head. Scrum doesn't work like that. The team needs to collaborate and learn how to use the skills of everyone for maximum benefit.

Remedies

When introducing Scrum, it does make sense to look at the list of activities which are needed to succeed in delivering working software. Rather than get everyone out of the coder's way, bring together a team where all those functions are covered.
This may actually mean that only a few people are doing work on the product code itself, and the majority chime in to do the right things right.

When you realize that coders are considered the only "real developers" for some reason, educate what a "developer" in Scrum actually is: Everyone who contributes to product success!