Mandatory PO task approval

Myth: Developers can't do Refactoring or architectural redesign without getting PO permission first.

Variations:

• Technical tasks require PO permission.
• The team only works on items presented by PO.

Follow-up myths:

• The PO needs to understand the technology very well to properly prioritize the work

Category: General Scrum myths
Danger: High

The basis of the myth

Traditional project managers create a Work Breakdown Structure, laying out the details of the work to be done by the developers in detail. Everything on the WBS must be done by the developers, and everything outside the WBS is "not in budget", and therefore not done by the developers. The misunderstanding that a PO behaves like a Project Manager leads to the idea that the PO needs to approve all the work.

Why is it a myth?

The Scrum guide states that the PO is responsible for "Optimizing the value of the work the Development Team performs" and "Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next". The intention behind this: The PO has to take care that the investment into development is money well spent. When the team has to do certain work, it has to be done. In that case, the PO's approval is typically granted by default, because failure to do necessary work impacts the value of the product detrimentally.


Assumption #1: The PO personally manages the work
Some Product Owners feel the need to be in full control over everything the developers are doing. This is a very time consuming pastime without any real value to the product or towards customers. As per the Scrum Guide, the PO doesn't even need to do any of the backlog work - they can entrust all of this to the developers: It just needs to be clear that the PO has the responsibility that proper backlog management happens.

Assumption #2: The PO must approve technical tasks

While in general, every technical task has a value and cost associated, this is usually very difficult to express. What is the cost of not including this-or-that framework, what is the customer value of extracting a microservice? When the team decides that a certain activity is mandatory in the best interests of the product, it needs to be done. Refactoring is no different from testing: you won't ask the PO to approve testing, would you?

Consequences

Task focus

The PO focusing on technical tasks is looking more at the work done by the team than at outcome. This may blind them towards real customer expectation. A good PO should be able to completely ignore the "How" in the work and focus fully on the "What" in order to create a satisfying product.

Owning the work, not the product

The PO spending precious time to understand and approve every single technical task loses the same amount of time pondering the strategy of the product and exploring customer demand. Instead of owning the product, they become owners of a to-do list.

Micromanagement

As the PO involves with every technial decision around the product, they strip autonomy from the developers. This will form a dependency relationship where the PO becomes a key decision maker even for questions outside their domain of expertise. From micromanagement will come a culture of finger-pointing, blaming and distrust. 

Unsustainable development

When the PO gets a say in whether technical improvements are priority now or later, a business-savvy PO will often prefer another marketable feature over better technology. While this may be a good decision on some occasions, driving the product completely from a feature marketing perspective will result in fatal amounts of technical debt.

Remedies

When anyone feels that the PO should approve tasks, you should question the "Why". Potential reasons might include:

• The team is not sure of the current priorities and market situation. In this case, the PO can support the team by providing deeper insight.
• The PO does not believe that technical changes are necessary. In this case, the team might want to examine their own stance on "gold-plating".

Hardening Sprint

Myth: Every few Sprints, we need a Hardening Sprint to make the product robust
Variations:

• Test Sprint
• Bugfix Sprint
• Integration Sprint

Category: General Scrum myths
Danger: High

The basis of the myth

Many teams come from a project-oriented background where "after the development work is done", if any time is left, remaining effort is put into stabilizing the product. As Scrum is product-oriented and intended to "last forever", these teams frequently suffer from accumulated technical debt. A well known solution is the Hardening Sprint to stabilize the product so that it can be shipped.
This myth was supported by the old use of "Potentially shippable product increment" (PSPI) in the Scrum guide, which gave leeway to the interpretation "Well, we don't ship just yet...", which has since been abolished in favour of the "Increment".

Why is it a myth?

The Scrum Guide clearly states that an Increment must be Done. This is explained literally as: "This Increment is useable, so a Product Owner may choose to immediately release it." There is no leeway to accumulate technical debt until a later date.
The Scrum guide does provide a certain amount of leeway for teams who are not sufficiently adept at Software Craftsmanship or work with an unsupportive product to weaken their Definition of Done to an appropriate level. This implies that team members and the organization understand their constraints and are actively working to continuously improve their DoD.
The institutionalization of a "Hardening Sprint" is contrary to the spirit of agility, namely: releasing value early and often.

Assumption #1: We can do the work later
Later, there will always be more work. That's the idea of a Product Backlog. At any point in time, the Product Backog contains the most valuable things to do. Any work for a backlog item that is deferred to the "Hardening Sprint" is either sufficiently important to do now - or sufficiently worthless to do never.


Assumption #2: We'll fix the bugs later

Many teams institute hardening Sprints because they don't have test results yet. A common misconception is that another team does the QA for the last Sprint while the developers code more stuff. To ensure that the current Sprint does not get disturbed by bugfixing, the bugs are postponed until the Hardening Sprint, where they are consequently eliminated.
Well - there are many issues here:

• Scrum does not separate functions. The idea of a separate test team is un-Scrum. "Tests passed" would be part of a good DoD. 
• Development and test should always be in sync. Practices like BDD etc. help in designing a defect-free product from the beginning.
• As code always builds on preceding code, a defect found "down the line" will cause significantly more rework than a defect just created: Hardening Sprints create massive waste!

Consequences

Poor quality mindset

Developers should be proud of creating a product that is usable at any time. When they get used to the idea that "later, we'll get time to increase the quality", they will learn that low quality is acceptable.
As typically, there is always something more important and always one more bug, the product accumulates technical debt which is usually just kept at bay instead of systematically managed. 

Value denied

When the team relies on an upcoming "Hardening Sprint" before releasing an increment, the value of any increment is Zero until then. The incurred delay for delivery may be quite costly for the product organization.


Branching hell

As the product itself is "hardened" at a later date, emergency fixes are typically created in "branches". Since each fix needs to be stable both on Production and in the Increments, each fix will require an independent "bug branch". All of these then need to be merged during the Hardening, resulting in exactly the problems which Continuous Integration intends to fix.

Remedies

Abolish the concept of a "Hardening Sprint". It induces tremendous waste.

Think very carefully about which activities are considered necessary during a "Hardening Sprint". List them out explicitly and ask the following questions: "Why do we need this activity?" and "What would need to change so that we either don't need this activity any more?" If the latter is inconclusive, ask, "What would we need to change so that we can do this activity during each Sprint?"

Common solutions to fix the need for Hardening Sprints include:

• A strong Definition of Done
• Test Automation
• Firm Engineering Practices, such as: BDD, TDD, Continuous Integration
• Collective Code Ownership
• Truly Cross-Functional teams (including Design, Development, QA and Ops)
• Feature teams
• Giving Developers a Prod-like development environment (thanks @Docker!)