What you do NOT need to do in Scrum!

I often hear discussions who is doing the "traditional" project leader tasks in Scrum. This is in general an excuse to state that Scrum alone cannot work and classical project leaders are still needed. 

Below a list of tasks you do NOT need anymore to do in Scrum.

• Make commitments on behalf of the team about how much they can get done by a certain date or estimate effort for the team,
• Coerce the team that the commitments made on their behalf are attainable,
• Coerce the team to change their estimates,
• Give direction to the team on how to implement the work,
• Monitor the team's progress to make sure they stay on schedule,
• Step in and determine the solution,
• Conduct weekly status update and face to face meetings with the team to surface issues and provide direction,
• Provide motivation and push the team to work harder than they might want to using carrots and sticks,

• Decide task assignments among the team members and follow up on tasks to verify completion. Force them to work during weekends,
• Be responsible for the team doing the right thing at the right time in the right way,
• Update Gantt charts for the iteration and release planning,
• Finding out that requirements mean to explain team members what they should implement,
• Review the documents and code to guaranty quality,
• Explain upper management why the project is late and why you need additional resources,
• Explain upper management why you cannot transfer a team member to another project,
• Attend weekly progress and escalation meetings to explain in details the status of your project,
• Define the priority of the next activities.

Now you as Scrum master or agile project manager have to perform important tasks

• Help removing impediments to increase velocity of team
• Coach team to implement Scrum and reflect on their activities.
  Plan-Do-Check-Act principle is built into Scrum with retrospectives and sprint reviews.
• Coach product owner to deliver a groomed and refined backlog
• Inform and support all project's stakeholders

If you reflect on these two lists it becomes obvious that the first list describes malfunctions and the second one describes mechanisms how to improve continuously - lean principles -.

Jeff Sutherland gives some interesting insights about the Scrum master

• The Scrum master enforces Scrum practices "Coaching rather than command and control"
• The Scrum master effort is 
• Few problems: for a small team 10%, for a large team 50% of your working time,
• Many problems: for a small team 50%, for a large team 100% of your working time until the team reaches a flow status,
• A Scrum master is a change agent and supports the organization to become more agile.

Personally I experimented with Scrum master part of the team, or Scrum master working for multiple teams. Experience has shown us that the full-time Scrum master is more effective.

And the LeSS framework has a clear rule about project managers

Keep project managers away from the teams!