The Scrum Team is self-managed and accountable for the outcomes of the development effort. Therefore the manager keeps monitoring the team to ensure they are performing well and also seek for support opportunities.

The Scrum Master should not be a proxy reporting to the manager. That would make this role loose impartiality and perform as a manager. Entering retrospectives wouldn’t typically be a good idea, because it might undermine the Scrum Team capability to create transparence, inspect and adapt.

Attending the Sprint Review is the standard event to understand if the Sprint outcomes are good and check the reactions of the stakeholders. If the team is exhibiting maturity, attending that meeting could be unnecessary. Staying informed about the team in informal ways (e.g. corridor conversations) or on demand by the team, will respect their autonomy and avoid extra meetings.

A manager of a Scrum Team is supposed to facilitate the development of the team and its individuals, but not to replace or superseed their functions. Even worse, try to change a good decision based on tactics or politics may spoil the relationship between the Product Owner and the manager.

The best course of action is to facilitate the discusion to have an objective interchange of ideas and ultimately take the decision based on the relative value of the features being prioritized.

Velocity is a statistical indicator that can help to forecast the amount of work that may be delivered in the next Sprints, or how many Sprints would it take to deliver the remaining Product Backlog.

Velocity is highly contextual to the team, because it decides how to score the items effort, so it does not make any sense to compare it. Even worse, trying to compare it will probably drive teams to fake the numbers.

Monitoring performance is expected for a manager, not to manage the teams activities but to identify the need for help.

Scrum Teams scattered on different physical locations offer new opportunities and also challenges.

On the upside, hiring can we easier in a global world, without the need to select people from a single location. The organization can also save money in very hot labour markets, although that shouldn’t be the main reason to select a distributed workforce.

On the downside, productivity and specially creativity can drop if special care is not taken to put in place good remote collaboration practices and some face-to-face activities.

«Purpose, Mastery and Autonomy are three accepted motivational factors for creative workers. Allowing the Developers to understand the Product Vision, together with the Key Value Indicators could help to understand the outcome produced to the users, and therefore the purpose.

Bonus systems tied to indicators are prone to rise greed and eventually game the numbers. Choose a fancy name (alone) will have a small effect all other things being equal. A Scrum Master could help to increase the motivation of the team, but one of the things that this professional may point out is to provide a clear product vision to the Developers.»

When a Scrum Master promotes self-organization and removes the Scrum Team impediments, helps the team to become independent and high-performance.

While facilitating the Sprint events and preventing the stakeholder to enter the Sprint are actions that may be useful on the short term, those are more sustainable when done by an empowered and self-managed team.

Managing the Scrum Team members it is *not* something that the Scrum Master should do.

«The nature of Scrum is based on self-organized teams. A good begginning is people self-organizing in a group to meet a challenge. The facilitated process helps them to do it effectively and efficiently.

Management can design the groups on different criteria, but that will reduce the engagement of team members.

The Scrum Masters are there to help the teams, not to define them.»

Teams self-management includes choosing the tools that better suit their needs. However that freedom needs to be balanced with other organizational needs, such as tools interoperability or the easyiness of team members to switch among teams with low friction.

Trying to influence them to revert their decission without a solid reason means undermining their self-management. Organizing a poll that imposes everyone a single tool because of the winner option does not help neither.

Managing the system means designing and optimizing its parts (teams) and relationships (dependencies). Co-managing this together with the team can increase transparency and effectiveness.

The Value Stream Mapping (VSM) is a nice tool to spot bottlenecks and wait times. The Lead Time is an indicator that helps to understand how fast are we delivering value.

Designing a static communication system is likely to be innefective, since communication in Agile is dynamic based on the emerging needs. Managing all work through a single tool and increase effectiveness, or also be a highly inflexible system.

The Scrum Team roles are expected to collaborate positively, based on open communication, openness and empiricism. When there is a disagreement, an effective approach is to gather evidence to ground the decisions instead of making decisions based on intuition. Fully developing alternate features is a too expensive and wasteful way of finding who was right (if any!). Instead, running small experiments (inspect) to make a bigger decision based on data (adapt) is a more empirical and efficient approach.

A manager may help the teams, as long as the teams find useful to receive feedback from the manager.

The Scrum Master should look for help in case the Scrum Team cannot make a decision, like suggesting them to explore new ideas in other teams or roles such as the manager.

Agile offers quicker feedback opportunities through short Sprints and continuous collaboration. That improves value delivered, reduces risks and helps to capture business opportunities.

Even if some projects could become faster by removing rework, this is not the key benefit of Agile. Control over engineers or maximizing utilization are not aligned with the style of Agile.

We are talking here about a structural dependencies problem. The manager should act somehow to help the team.

Asking them to decide whether help or not their peers will probably create conflicts among teams. Helping them to remove those dependencies on the mid term by training others or redesigning teams is a good choice. Meanwhile, helping them not to overcommit.

«Scrum acknowledges the complexity of creative work, so defining with detail the problem and the solution is not possible. Only a rough estimate can be used beforehand and the real plan will emerge as the solutions are being developed.

Asking the Product Owners to define a detailed budget is an illusin that won’t probably happen during the execution. Using a traditional organization such as the PMO is not aligned with Scrum. Using the past project performance to compare with the current budget could help, but not with the goal of delivering a detailed IT Budget.

Asking the Product Owners to define a high level plan (based on Product Goals) and forecast the delivery based on statistical data establishes a more effective and empirical framework for demand planning .»

The Sprint Review is the standard event where all stakeholders can seize the progress towards each team’s Product Goal. All the attendees will get information and answers about the development progress.

The Product Owners can use several tools, including the Release Burndown, number of remaining items, cumulative flow diagram, etc. but it won’t be easy (or even possible) to compare them.

Management can delegate part or largely the hiring of new candidates, but still remains accountable to the company.

Most mature teams could perform most of the hiring process together with HR, which will make sure the HR policies are respected. Other teams less mature would benefit from participating somehow in the selection of the candidate. In any case, the Scrum Master is not the Scrum Team’s manager and does not replace HR.