No specialists!

Myth: Everyone should be able to do everything.
Variations:

• Nobody should be specialized as anything.
• We're looking for a Developer who is good in Frontend, Backend, Databases, Testing, Architecture, Design, UX, DevOps ....

Category: General Scrum myths
Danger: High

The basis of the myth

The Scrum guide says, "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment" - which is misconstrued as "Every developer should be cross-functional".
It's an exaggeration/misunderstanding of the idea of "T-Shaped People"; the concept that people should be able to do everything, but specialize in one field.

Why is it a myth?

While a jack-of-all-trades-master-of-all is every IT manager's fever dream, there are two problems here:
1. There are probably not enough of these people in your network that you could fill a team with them
2. They're probably not going to work at the average rate of a software developer.
So, you're not going to get those people on your team. And since you don't have them - don't expect them to be.

Assumption #1: It's easy enough to know everything relevant.
Well, if it is - why don't you just grab a book and learn the necessary things about Frontend development over the weekend for a start? After you got that, maybe you can look into Software testing. At least that makes you a Frontend developer who can test their own code - no backend, database, UX ... yet. And when you're done, please re-visit those lists, because they might have changed. Keeping up to date in one field is hard enough. Keeping up in all would take so much time that no coding could possibly get done.

Oh, and we haven't talked about domain knowledge in your product yet.


Assumption #2: People can be good at everything

Yes, but not everyone can be good at everything. Everyone can be good at something.
Everybody specializes based on what suits them. Some people just have a knack on turning ideas into running code - while others are naturally gifted at finding the fly in the ointment. Some people can simply "feel" good design, while others are completely oblivious to the impact of their ideas on UX.

Consequences

Wrong team constellation

When you believe you've got the Jacks-of-all-trades, your team members are either coincidentially good at the things others are not good at, or you're missing something potentially important. 

Long staffing times

While waiting for "Mr. Right", you've probably missed a hundred opportunities to find the person who would have been perfectly suitable for your team. The harder you look for a jack-of-all-trades, the more you become blind to good opportunities.

Just asking to be fooled

Given how much knowledge modern development takes, a person who claims that someone can know everything is just asking to be fooled. Buzzword bingo and sly talkers will probably win the interviews in a company where hiring decisions are based on the jaded idea that someone, somewhere has found the Philosopher's stone and is just waiting to peddle it for pennies.

Remedies

Simply accept that people specialize.
Rather than asking people to do everything well, make sure people can do one thing that really contributes to the team - and they're sufficiently flexible to fill in the gaps as needed.

It's good to develop your team members to adopt new skills over time, but remember:
1. Nobody can know everything.
2. Attaining a new skill takes time.

Individual goals

Myth: People need personal goals
Follow-up myths: Variable salary based on personal goals

Variations:

• Personal goals help people grow
• Personal progress reports
• Personal stretch goals
• Division goals

Category: Development team myths
Danger: High

The basis of the myth

Management by objectives is a common method of traditional management. In many organizations, this is propagated downwards in the organization. Every person receives certain goals, oftentimes tied to some salary proportion for attainment. While MbO is not bad in and by itself, it is merely a legacy process that may not be suitable for Scrum.

Why is it a myth?

It simply doesn't have a place in Scrum. This has nothing to do with Scrum and is exactly the opposite of Scrum's idea of "shared team accountability".

Assumption #1: Individual growth helps
Growing each person is good, but they should grow into a stronger team. Anything that a team member does which does not further the team's objectives is actually counter-productive. Do we really want team members to invest time and energy into that? If not, why would we want to give them goals forcing them to do exactly that?

Assumption #2: Tying goals to salary makes sense

When my goals are tied to my salary, I'm stupid if I don't negotiate for goals that are difficult to attain. People typically negotiate goals that they can reach without much of a stretch. These goals do not help anyone grow.
On the other hand, a goal that requires something worthwhile learning within the (usually long) time for which the goal is defined, contains so many Unknowns that only the most gullible people would voluntarily agree to have them tied to their salary.

Consequences

Mis-Alignment

The Scrum value "Commitment" clearly states that "People personally commit to achieving the goals of the Scrum team". As soon as the Scrum team does not have exactly the same goal as the individual, the person must choose whether to pursue their goal, or the team goal. By tying a financial component to the individual goal, the person is dis-incentivized to pursue the overall team goal.
It is impossible to give different people the same team goal, but differing individual goals. This will cause schizophrenic behaviour within the team. The result will ultimately be a bunch of individuals pursuing their personal goals rather than one team pursuing a common goal.

Missing Sprint goals

When a team member is forced to choose between investing time into furthering their own, financially relevant - and the team's mutual (not that directly relevant) goal, most people will choose to first secure their own finances. This may cause team members to diverge from the team goals, which (if the Product Owner is doing a good job) maximizes the financial impact to business.
It is never a smart idea to encourage people to optimize their own situation in disregard of the company success.

Remedies

Get rid of any kind of system rewarding or promoting behaviors that are inconsistent with teamwork or the team's goals. Focus on teamwork, team goals and synergies rather than individual contribution.
Encourage people to grow within their team rather than by themselves.
If you can't really go without a reward system (which has already been proven detrimential in knowledge work), reward and promote behaviours which benefit the team and the overall organization.

This may require overturning the roles of division managers and existing HR processes - but unless you do that, you will never attain a truly gelled team.

Pigs & Chickens

Myth: The Scrum team consists of "Pigs" (committed) and "chickens" (everyone else).
Variations:

• We treat people differently based on whether they are part of the team or not.

Follow-up myths:

• Chickens don't participate in Ceremonies.
• Chickens are not allowed to talk in the Daily.

Category: Development team myths
Danger: Low

The basis of the myth

The "Pig and Chicken" metaphor is often applied when there is a lot of outside interference with the team.
It is used by many agile coaches and trainers to convey the idea that members of the Scrum team should be absolutely committed to the team and those who are not committed might be a disturbing factor.
That is, the "pigs" on the team should only be working on items which do not contribute to the team's goals during the Sprint period, and nobody has the right to distract them. Those who are either distracted or causing distraction are unwelcome ("chickens").
The Scrum values "Focus" and "Commitment" lend credibility to this claim that Scrum team members should be "pig".

Why is it a myth?

Simply put, the metaphor isn't part of the guide.
And, for cultural sensitivity reasons, some people might be offended when they are told they should be "pig", regardless of how adequate the analogy is.

Assumption #1: Autonomy
When a Scrum team is not autonomous, then people who are not part of the team directly affect their success and are unequivocally contributing to the team's success.
Just like a child who can not wake up on time to go to school can not claim autonomy, a team which relies on external help can not claim autonomy.
Many fledgling Scrum teams are not autonomous in the sense of a meaningful Definition of Done. While it is aspirable to get there, during the journey, they better not discriminate against those they rely on.

Assumption #2: Separable goals

The "pig" may feel that their value to the success of the Ham+Egg restaurant depends much more on their contribution than on the chicken. However, the pig must understand that there will be no Ham+Eggs without a chicken, so the goal will not be attained. If business success depends on selling both Ham+Eggs, then the pig alone can commit all they want, they will still not succeed.
It is healthy to remember the contribution of others as essential, especially when the team stands at the verge of having to answer how they can pull the "chicken" capability into the team in order to get a better Definition of Done.

Consequences

Two-Class mentality
The "Pig-Chicken" metaphor creates a mindset where Scrum team members may disdain those not on their team. This can foster an extremely unhealthy, inappropriate elitism.
Even if the team was truly autonomous (even financially), elitism is not within the spirit of agility.
And when the team actually depends, it's especially harmful to look down on those you rely on.


Communication breakdown

The "Pig-Chicken" metaphor may lead developers to believe that "chickens" don't understand their problem or are of little or no help. Essential communication with outsiders may be considered a "waste of time", potentially resulting in huge opportunity losses. Even if the development team is fully autonomous, communication with the environment is part of natural Inspect+Adapt.

Remedies

The benefit of the Pig-Chicken metaphor is that it provides a simple explanation for discriminating who has the right to change team decisions and direction - and who does not.
However, it can quickly get overstretched and turn into a boomerang.

The best way is not to use it prescriptively in training or team building ("Define:Who is pig? Commit!") but only take out this analogy where it really makes sense - in situational coaching.