Simulador Test Professional Scrum Master II

From the Scrum Guide 2020:
– «If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.»
– «Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.»

The Scrum Teams should share a common definition of Done, which can be extended by the teams if it keeps being compatible with the common definition. Each Sprint should produce an integrated and usable Increment, regardless how many teams are working together in the same product.

Scaled-Scrum follows the same principles of the Developers working in a single team Scrum:

• The Teams pull the items from the Backlog during the Sprint Planning, in collaboration with the Product Owner.
• The Teams are responsible of self-managing during the Sprint.
• The Teams are responsible of delivering an integrated Increment no later than the end of the Sprint.

Nothing prevents a Developer of working in two or more teams, although the productivity will drop in average due to the cost of context switching.

As a self-organized team, the Scrum Team is expected to seek solutions autonomously to solve their problems before asking for help.

The Scrum Master should strive to help others to solve their problems in a sustainable way, without needing permanent help from the Scrum Master and not replacing one of the most important duties of the Product Owner, which is collaborting directly with the team.

A better approach is to «take to the team» the problem and ask them to analyze the problem, its impact and come up with solutions. Improving the Definition of Done would really be an effective measure, so the Developers can autonomously decide whether a Item is Done or not, regardless of the need that the PO should participate or not in the validation.

In order to forster autonomy, commitment and self-organization, the Scrum Master should strive to involve all the team in looking for the root causes of the problems and identify the solutions.

The lack of agreement could be due of not setting their own rules, values and principles from the begginning. Running a team reset could improve that.

Considering the two developers with conflicting opinions as the ones to convince to change their point of view is a pre-judgement which restricts the capability of the Scrum Master to help the team to achieve a true and sustainable solution. Pressing them in public is an even worse approach because they may feel ridiculed and push back the next opinions from the Scrum Master.

From the Scrum Guide 2020:

• Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
• The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.

The Scrum Master needs to help the team to solve the disfunctions of the Daily Scrum. Involving them in the analisys of the disfunctions’ root causes and in the identification of possible solutions helps to tap on their knowledge and increase their commitment to the solutions.

The Scrum Master is not the boss of the team, so this role cannot force others to start or stop doing things. Leaving them self-organize without offering help, renders the Scrum Master role useless. The Daily Scrum facilitation is not standard and it is up to the team to choose the format it fits better their context.

Product Backlog Items are pulled by the Developers during the Sprint Planning event, aligned with the Sprint Goal proposed by the Product Owner. Only the Developers can estimate how many Items they can pull.

In case several Scrum Teams are working together, they should coordinate to pull how many items they can do, and which items is each team going to work on.

A good Scrum Master will try to engage with the Developers and understand them before «preaching» the rules and principles of Scrum. Agreeing to directly drop one of the key events of Scrum is neither helping.

Understanding their point of view regarding the last Retrospectives and offering to host a good Retrospectives should be good moves.