Great new video about Kanban by Michael Badali. This is the third video in a regular series:
Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
|ScrumMaster||Product Owner||Project Manager||Team Lead|
|NO||Define Business Requirements||PARTICIPATES||NO|
|NO||YES (Deliveries)||Define Milestones||NO|
|YES (process and people)||YES (business)||Risk Management||PARTICIPATES|
|Organizational Change Agent||NO||NO||NO|
|NO||Accountable for Business Results||RARELY (just costs)||NO|
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
Organizations like to have clear role definitions, clear processes outlined and clear documentation templates. It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect. ScrumMasters should be anti-bureaucracy. Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.
To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.
– None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).
– Obstacles or impediments “backlog” – a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing. These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
– Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
– Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams. Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed. Outsiders are not welcome to the retrospective.
– Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks. This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
– State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).
NOT RECOMMENDED (BUT SOMETIMES NEEDED):
– minutes of Scrum meetings
– process compliance audit reports
– project administrative documents (e.g. status reports, time sheets)
– project charter (often recommended for the Product Owner, however)
– project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
– any sort of up-front technical or design documents
The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach. There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
– improving how the team uses Scrum
– helping the team to remove obstacles and impediments to getting their work done.
One of the valuable and important responsibilities of the ScrumMaster is to remove obstacles that impede the team’s work. This is necessary so that the team can become more and more productive in their work which gives greater value to the company. If the ScrumMaster does not work diligently on removing these organizations obstacles, the team will get bogged down by challenges and become demotivated to progress, and their morale will drop and become apathetic to the work and to Scrum. The benefit of removing these large obstacles is that it speeds up the cycle time of the work by the team. This is essential so the Team Members can focus their energies on delivering working software.
To learn more about organizational obstacles, visit the Scrum Team Assessment.
One of the primary ways that the ScrumMaster serves the team is by removing impediments to the progress of the team. If the team does not have what it needs to progress in its work, whether it be technology, tools, the right space, etc., the ScrumMaster must have the authority to immediately fill those gaps for the team. The ScrumMaster should not need permission from management in order to get the team what it needs. There should be request procedure that the ScrumMaster needs to go through in order to get sign-off from acquisition departments and what not. At the same time, if there are interpersonal issues between team members, the ScrumMaster must be empowered to intervene and help individuals overcome their differences without the involvement or permission from their direct line managers. Any process or procedure that the ScrumMaster is forced to follow prolongs the impediment for the team as well as the consequential waste and unrealized delivery of value.
To learn more about in-team obstacles, visit the Scrum Team Assessment.
The principles of openness and transparency include being able to be truthful about ways that you are struggling. A Team Member must share their struggles with their Scrum Team and with the ScrumMaster so that the team, at least, knows your status. Without that visibility, the Scrum Team may make decisions that are difficult or impossible to implement due to hidden obstacles. At every Daily Scrum, each Team Member should think carefully about the challenges they are currently facing, and share those challenges. The ScrumMaster cannot do a good job without that transparency since a core part of their work is to deal with obstacles. If a Team Member fails to be open about obstacles, or fails to recognize something in their environment as an obstacle, this can slow the team in its progress towards becoming a high-performance team. Obstacles that persist for a long period of time simply because they are not openly discussed can have a demoralizing effect on the team. On the other hand, a team that creates full visibility into their obstacles can enlist the help of stakeholders, work together to overcome those obstacles, and systematically become better and better at doing their work.