With more and more companies adopting agile development, the traditional project manager roles are fading. With this transition, project managers are being thrown into new roles, including the “scrum master.”
Let’s say you’re a faced with a group of former project managers who received their scrum training and have been sprinting for a little while or are about to begin. Be careful; old habits die hard. Take time to reflect with these individuals; it’s new to them and likely the team as well. Here are five traps to avoid as a project manager transitions to scrum master.
1. Being the Chief Meeting Organizer
Yes, a scrum master facilitates ceremonies (sprint planning, etc.) where necessary. No, they are not the administrative assistant to schedule everyone’s meetings. It’s important that every team member feels empowered to communicate with anyone necessary to get the work done, without the scrum master as a middleman for brokering the exchange.
Scrum and agile development place an importance on people and their interactions over the formalities commonly found with traditional project management and top-down communication funnels. Consider the Agile Manifesto: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools…”
2. Not Recognizing the Difference Between the Spirit and the Letter of Agile
Sally, a new scrum master, raised a question in her community of practice: “We stated in our team working agreement that everyone should come on time. Since everyone is showing up on time regularly, should we remove that from our agreement document?”
It’s not about updating a document; it’s about fostering a team culture with these ideals. The working agreement document may be an entry point into the conversation, but if it’s sitting on a drive without updates, yet the team culture is healthy, that culture is what’s most important. Where there are team issues, the scrum master should diagnose them or highlight them to the team.
Recognize that issues are not resolved by documents and physical tools but rather by the conversations in which meaningful solutions are created together. Reflect again on the Agile Manifesto’s reference to “individuals and interactions over processes and tools.”
3. Mistaking the Stand-Up for a Status Update
A stand-up is time for the team to communicate to each other, not to the scrum master. The meeting belongs to the team, not to any one person. You may find in a newly formed team that when people are used to a waterfall process, or no process at all, they look for a leader. The project manager in a waterfall project is generally the person chasing the status of everyone’s work in an attempt to update project plans and predict finish dates. This chasing disappears in scrum, and the team must learn to act as a self-directing team. The scrum master should reinforce this self-direction and accountability.
4. Assuming Their Only Job is to Be the Scrum Master
The scrum master, as well as the rest of the team, should be versatile. In some agile teams, the scrum master is a rotating position. It’s a servant leader role, and as with any other team member, if there are things to be done and the scrum master is capable, they should pick up and execute those tasks.
According to the Scrum Guide, “helping the development team to create high-value products” is one of the scrum master’s services to the team. It’s one that sometimes is lost for a project manager transitioning into this role, as they may not be used to doing items that fall under a developer’s or even a tester’s purview.
5. Not Adjusting Stakeholder Communication
Weekly status reports with issue logs and risk and mitigation plans are the holy grail of project manager communication. In scrum, the measure of progress is “working software” (or solutions) per the Agile Manifesto. The issues and/or risks are raised, discussed and generally solved by the team, with escalation to outside help where required.
The scrum master may not be able to control what artifacts the team uses to communicate. If there is a governing body, such as a project management office or portfolio management group, the expected deliverables may already be set. In these instances, as much as possible, scrum masters should point to the fact that “issues” or “impediments” are fluid and change depending on committed work by the team. Avoid detailing out issues, as they are sure to be outdated within days, hours or even minutes.
Scrum masters can use any of the standard charts coming out of scrum. Burnup or burndown charts are particularly helpful as a means of communication, along with the sprint review (also referred to as a demo or showcase). With these charts, teams can share facts around delivered work and progress against a determined release. The sprint review provides a live opportunity to touch and feel the completed work. Witnessing consistent delivery goes a long way for stakeholder buy-in to the progress and credibility of the team.
Transitioning to scrum master should be a fun change. Just be careful; it is important to help with reflection and coaching so that the new scrum masters leave some habits behind.
