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!

ad-hoc Planning

Myth: The Daily Scrum is when developers pick their tasks for the day

Variations:

• Daily Scrum is where planning happens

Category: Daily Scrum myths
Danger: Low

The basis of the myth

The Scrum guide says, "During the [Daily Scrum] meeting, the Development Team members explain: [...] What will I do today to help the Development Team meet the Sprint Goal?"

In some teams, developers will stand in front of the Story Board, and then spontaneously decide: "... hmm ... and today ... THIS one ...", deriving their behaviour from the Scrum Guide's direction to explain what to do today.

Why is it a myth?

This one is so close to truth that it could be true, but it's deceptively deviant.
Scrum does not say that developers should not have a plan until they come into the Daily, but that they should lay out their plan during the Daily, and adapt it where necessary. This ties right into the big bad dangerous overall myth "Agile people don't plan": Developers should be clear on their plan before discussing it, rather than winging it.

Assumption #1: Big Upfront Plan 
There is little harm done when the team has laid out a Big Upfront Plan of tasks during the Sprint Planning, except that developers cherry-pick tasks based on what they think is best, rather than work in priority order. It only becomes harmful when developers start completing tasks instead of delivering value.

Assumption #2: Scrum is short-sighted

Every developer should already have a clear idea on the next steps even before entering the Daily. The Daily Standup is not a breakpoint erasing history and opening a new page - it's actually intended to ensure everyone is still on the same page.

Assumption #3: Time-boxed planning is enough

Scrum suggests that the team has a clear plan for the day. Ad-hoc planning is OK when little planning is needed. But when necessary discussions get replaced with more or less random choices, the product success is endangered. The intended output of the Daily Scrum is a feasible, aligned plan for the next 24 hours. If more time is needed to create this plan, the unclarities should already have been discussed before the Daily.

Consequences

Lots of WIP

When developers cherry-pick their tasks rather than contributing to getting things Done, the Planning board will soon be cluttered with lots of started, unfinished stories. 

Unforseen impediments

When developers pick tasks without putting enough thought into them, the chance of failing the Daily Plan increases.


Postponing trouble

Developers often have an uncanny eye for spotting trouble, and when they simply pick tasks they think they can do until tomorrow, they tend to pick the ones with lowest risk first. The main risks of the Sprint are postponed.

Idle time

In some rare cases, developers will idle when they completed all of their tasks until the next Daily Scrum. That makes absolutely no sense: There is no reason to not do anything when the Sprint Goal is not met and there's work to do.

Remedies

Everyone on the team should be clear that Planning is not where you pick your tasks, but where you align your task plan with the rest of the team. An easy way to stop ad-hoc planning is to intercept developers before the Daily Standup and ask them what their plan is.

Keep an eye for Work in Progress. Put WIP limits on stories, not just on tasks. When a developer starts tasks on a new story while there are still open tasks for an existing story, scrutinize this decision.

If Daily Plans are considered an iron box (i.e., "I won't do anything I didn't state"), re-emphasize the agile principles of collaboration and technical excellence.

Reporting time!

Myth: The Daily is the team's status reporting meeting.
Variations:

• SM asks progress-related questions to individuals.
• Managers who need status updates can attend the Daily.

Follow-up myths:

• The Daily Scrum eliminates traditional progress reports

Category: Daily Scrum myths
Danger: Moderate

The basis of the myth

The Scrum guide says, "The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain: * What did I do yesterday that helped the Development Team meet the Sprint Goal?" (and other questions)

Coming from a traditional project management perspective, people immediately equate this with a progress report.

Why is it a myth?

Daily Scrum has nothing to do with progress reporting. Especially not individual status reporting. And it's not the Scrum Master's responsibility to check on people. It's simply synchronization and (re-)planning.

Assumption #1: Activity status matters
Reports only help if an action is taken. The team autonomously decides on actions. Solutions are created by the self-organizing team and escalated when inevitable. "Activity status reports" are not a part of Scrum. They are un-necessary, because results are visible every few weeks.

Assumption #2: Daily Reports help

The team discusses the best course of action to reach the Sprint Goal. The Sprint Backlog is a good indicator of how close the team is to reaching this goal. And the Review is a great indicator of how well the goal was hit.
What reports should result in, is need for change. But this is the result of a Retrospective. So the Daily Scrum contributes nothing of relevance for management intervention.

Assumption #3: Utilization matters

The team should be collaborating. When a team member stays silent, this does not mean they did not do any work. We don't even want "activity statements" in the Daily. We want people to collaborate and discuss results, not how busy they are. There is absolutely no correlation between what a person says in the Daily Scrum and how much they do.

Consequences

Blather

When team members assume that they are being interrogated for performance, they will blather about how busy they are, but will not focus on the Sprint Goal. The entire Daily Scrum becomes a freak show rather than a goal-oriented meeting.

Me vs. Us

In the Daily Scrum, it's all about the Sprint Goal and how we, as a team, can reach it. "I" should not matter all that much. But when people feel that they need to prove what they contributed, "our" goal becomes irrelevant.

When the Daily Scrum is abused as a Reporting ceremony, it becomes pointless.

Remedies

The Scrum Master must clearly educate the team that Daily Scrum is not reporting, and how its character is different from traditional reporting.
The Scrum Master should definitely refrain from interrogating individuals, but rather provide the leeway for team members to speak only about what they feel comfortable with.

If managers eavesdrop on the Daily Scrum to "measure progress", they need to be educated on more valuable progress assessment opportunities, such as Sprint Reviews and Backlog status.

Should line managers abuse the Daily Scrum to check on individuals, the Scrum Master needs to educate them on the destructiveness of this behaviour. If this abuse does not stop, the manager must be invited out to enable a productive Daily Scrum.

Standup!

Myth: It's called "Daily Standup" for a reason!
Variations:

• No sitting or leaning.

Follow-up myths:

• No electronics

Category: Daily Scrum myths
Danger: Low

The basis of the myth

The "Standup meeting" is a classic management tool to keep meetings short, because people don't like to stand for long times. Because the Daily Scrum is supposed to be short, this one has carried over.

Why is it a myth?

The idea of a "Standup" neither originates from Scrum, nor does it belong into Scrum.
The Scrum Guide only states, "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours." The term "Standup" is nowhere mentioned in the Scrum guide.
Scrum is not prescriptive about how this event is conducted - only about intended results, scope and timebox.


Assumption #1: Physical fitness
For a person of normal health, 15 minutes of standing is no issue - it's even good for blood circulation. But what about people with special needs? It's not called "Standup" for the very reason that Scrum does not exclude people who can't stand up.

Assumption #2: Spatial proximity

It's not even necessary for the team to gather in proximity, only to be together. This is a big issue for distributed teams, who can also use Scrum (albeit with the standard issues distribution causes). Remote team members are usually forced to use electronics just to participate.

Consequences

Standups actually can induce psychological pressure and discomfort. If this is what you're looking for, fine - otherwise: Why?

Remedies

When your team can stand up, that's good. It's healthy. If they can't, well - no problem. If they don't want to, look for the root cause rather than fixing the symptom.

When you want to add specific constraints or methods to the Daily Scrum, ask the team.

For example, "Why should we stand up?", "What difference does it make?"

Team Time!

Myth: The Daily Scrum is exclusively for the developers
Variations:

• The Product Owner must not attend
• Outsiders must not attend
• "Chickens" don't speak

Category: Daily Scrum myths
Danger: Moderate

The basis of the myth

The Scrum guide states, "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum."
The simple word "participate", which indicates "take an active part" is sometimes confused with "attend".

Why is it a myth?

The myth is that the Daily Scrum is some kind of protected, high confidence environment where nobody except developers are welcome. The idea behind the Daily Scrum is that it's a highly efficient, focused, short meeting.
The rule that "only Development Team members participate" exists because non-developers may not understand what developers do. When others cause distraction that impedes the synchronization and planning, they overstep their welcome. But they are welcome.


Assumption #1: PO can not contribute
It's not necessary, but sometimes, the Product Owner has information that will help the Developers reach their Sprint Goal. Even though the Daily is not the meeting to share this information in detail, the Product Owner needs to inform the team that there is information which may affect their next planning steps.

Assumption #2: "Chickens" don't contribute

Derailing the Daily Standup by asking questions is not welcome, but if an outsider has information that is absolutely relevant for plan currently being created by the developers, at least they should be aware that this plan would deprecate before the meeting ends.

Consequences

Ineffective Planning

When the team makes a plan that is wrong, and someone can help the team move in the right direction, that person should be heard. Purposefully ignoring available information is very un-agile and has nothing to do with Scrum.

Morale effect

When outsiders who have important information are told by the Scrum Master to withhold this information, they will. This may demoralize those who can help the team, weakening overarching collaboration. 

Extra meetings

When outsiders (e.g., members from other teams) are "invited out" for no reason, then extra meetings for synchronizing with these people will be required. Silent attendance should always be welcome.

Remedies

The Daily Scrum should enable synchronization and collaborative planning. Any person who does not distract from these goals may be welcome, because this increases transparency, understanding and trust.

The Scrum Master should not be hasty to hush up or invite others out, but rather spend time educating/coaching them regarding their effect on the meeting. 

At best, the Daily Scrum could be a kind of "fish bowl" meeting where the entire stage belongs to the team, while others draw all the necessary information they can. This can eliminate huge amounts of otherwise needed coordination meetings that would otherwise draw capacities from the team.

Estimate ALL the items!

Myth: All items on the Product Backlog need to be estimated
Variations:

• Upfront estimation
• Estimates are required for the PO to prioritize the backlog based on ROI
• An estimated Product Backlog is required for a Release forecast

Follow-up myths:

• Re-estimate frequently

Category: Backlog myths
Danger: Low

The basis of the myth

The Scrum guide says, "Product Backlog items have the attributes of a description, order, estimate and value."
Traditional project managers creating an upfront Work Breakdown Structure are used to attaching estimates to each piece of work early on in order to produce the Project Plan. So, the entire idea that the Product Backlog should be completely estimated upfront is a mix of project thinking and

Why is it a myth?

Again, read further: "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process ..." - it's completely fine to add estimates at a later time. This, of course, means that it's completely fine if there are backlog items without estimate!

Assumption #1: All items will be delivered

Why do we need estimates about items that we will not deliver? Only when we are sure that an item will ever be delivered, it's estimate will be important. In turn, until we know that it will be delivered, the estimate is not important.

Assumption #2: There's value in the estimate
Estimation takes time. To justify investing this time, the estimate needs to have value. So, we assume that the generated estimate will actually be used for something. Estimate that deprecate before being used are waste.

Assumption #3: We need upfront information

A Product Backlog tends to consist of items that will be done in the near future and items that will not be done in the next few Sprints. How does the estimate about items that won't be worked on affect the plan?

Assumption #4: We know what we're up to

As the product develops over time, the basis on which a new feature is built also changes over time. Let's use this image: When you are standing on the beach, it will be difficult to estimate a skyscraper. Once you've built 20 houses of varying size, it will be much easier to estimate that skyscraper. Until we know enough about our product, many estimates are just haphazard guesswork.

Consequences

Tedium

Combined with a huge backlog, upfront estimation turns into a long, tedious meeting. As developers start to feel tired, they'll be very complacent in the estimation, reducing the accompanying discussion and thereby the accuracy of the estimate. After half a day of estimation, you might as well roll dice: Your estimates will be good for nothing.

Guesswork

Based on assumption #4, the accuracy of early estimates will be very low. How does a a probably-just-plain-wrong estimate actually add value? How likely is a plan based on guesswork better than a plan made without details?

Extra effort

When estimates are made way ahead of time, the backlog items will need additional attributes, such as "When was the estimate done, how likely is re-estimation needed" etc., adding extra effort with no value. Again, CRUFT increases, leading to a viscious circle consuming an ever-increasing amount of precious, limited time.

Re-Estimation

When estimates are outdated because of new information, they need to be re-estimated. However, this means that the original estimate had no impact on the final product: The previous estimate is waste. The more often we discover that an estimate becomes outdated, the more wasteful our estimation approach is.

Remedies

Question, "What do we need the estimates for?" and limit effort to the need.

Create awareness in the team and organization that new information invalidates previous estimates, and so the value of future estimates quickly approaches 0.

Keep "Just in Time" in mind for estimation as well. A Release spanning more than 3-4 Sprints is most likely subject to many changes, so do not even feel pressured to estimate every item for the Release. Create a crude approximation for the Release scope, a better approximation for the Sprint - and simply forget about the future until you get there.

Refinement may be used to estimate items that will be coming up in the next 1 or 2 Sprints to create a better Sprint Plan if estimates are needed and still missing.

Until you know whether an item will even be realized, do not waste time estimating it.

Personal status update

Myth: During the Daily Scrum, every developer answers the "Three Questions"

Follow-up myths:

• Daily Scrum exposes developers who don't contribute

Category: Daily Scrum myths
Danger: High

The basis of the myth

The Scrum Guide states, "During the [Daily Scrum] meeting, the Development Team members explain:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?"

This is then re-interpreted as "Each developer must individually answer these questions". It also ties nicely with project status reporting, which is very easy to transfer into the Daily Scrum.

Why is it a myth?

As long as you have individuals working on individual items, the Three Questions are very similar to each team member giving an update based on the Three Questions. As soon as collaboration increases, team members already know what others did, and the answer to question 1 becomes redundant. When developers use techniques such as Pair Programming, the repetition of "Yeah, I was working with Joe on ..." also provides a level of redundance.
The Daily Scrum is not the mandatory point when this information should be conveyed, but the latest sensible point for this. Any information that is already available to the team is redundant during the Daily.
Lastly, the purpose of the Daily Scrum is not to answer questions (it's not an interrogation session), but to synchronize and plan the upcoming 24 hours.


Assumption #1: We're not really a team
When we really have teamwork, what is the benefit of them stating what they did during the Daily Scrum? Being part of a team should imply that others already know what each team member was doing, how far they got and where the problems rest.

Assumption #2: We work on many things

When we collaborate on one thing, it's really difficult not to know what is going on. Only when we distribute the work, we need to sync. As long as Daily Scrum helps me find out what my team is doing, we may have issues with scatter or transparency. Daily Scrum does not resolve these impediments, it only reduces the damage they case.

Assumption #3: It ain't obvious

The Daily Scrum nowhere states that the team should state the (freaking bloody) obvious. It only limits running out of sync. When things are not obvious, we should work on transparency, alignment and focus. As these aspects improve, the amount of communication about every individual's work decreases.

Consequences

The biggest problem of the "Three Questions" Daily Scrum meeting is when there are hints that people are working individually, and not as a team. When the "Three Questions" actually seem to reward having individual contribution over collaboration, the Daily Scrum turns from a synchronization meeting into a scattering meeting, a merit report or - even worse, a bashing or pressuring session.

Remedies

The Daily Scrum is good to synchronize, focus and create clarity on the next steps.

The Scrum Master should observe for problematic patterns such as team members "reporting in" or many different topics being discussed.
When people feel the need to "make up" something so that they have something to speak, the reasons for this should be analyzed,
When developers are more concerned about their own Three Sentences than about really synchronizing, the Scrum Master should step in and challenge the benefits obtained from the meeting.

If outsiders attend the Daily Scrum and use the obtained information to evaluate individuals, the Scrum Master should invite them out.