The Differences between a Project Manager and a ScrumMaster
I recently came across the following discussion on LinkedIn: the differences in the roles of a project manager and a ScrumMaster. I thought I would jot down my views on the same. In the traditional model of software development, the project manager (PM) is responsible for project planning, estimating costs, preparing status reports, scheduling tasks to the team, and managing the leave calendar. However, with the popularity of Scrum and its three roles—the ScrumMaster, product owner, and the team—the project management responsibilities, although diluted, are not going away.
No matter what we try, eliminating the PM role is not going to absolve us from supporting the responsibilities; someone has to do them.
Scrum recommends that the ScrumMaster (SM) should work like a servant leader by removing all the impediments of the team. The ScrumMaster is like a coach and a mentor, not a PM. Now the question is: Without a PM’s role in place, who should handle the associated responsibilities?
Enterprises have tried different techniques to fit roles and responsibilities of a PM into Scrum teams. Some of them include trying to spread project manager responsibilities across the team members, having a centralized project management office (PMO) to support Scrum teams and renaming the ScrumMaster’s role as iteration manager or something else to stack up additional PM responsibilities. Each of the above techniques has its own pros and cons.
Spreading the PM responsibilities across team members may not work very well. Scrum teams are expected to be self organizing, and they can handle most generic tasks, like assisting in project planning, status reporting. However, in order to estimate the costs, one needs specialized financial skills. But many companies are not as transparent as Semco in enabling the employees to know all the contractual details. Semco’s transparent and open culture is a result of its leader, Ricardo Semler, trusting self-organization and maintaining a transparent culture.
Having a centralized PMO is definitely a good option. Senior leadership at large enterprises expect weekly executive summaries of all project's risks and issues. Centralized PMOs can work collaboratively with the Scrum teams and extract the reports. Many services companies have complicated financial contracts that a specialized PMO cell is better equipped to handle than a typical Scrum team.
Pushing a ScrumMaster to take on additional PM responsibilities under the guise of a role like an iteration manager (or something else) is not always a good option. It could work well in smaller projects; however, large, complex, and distributed projects need dedicated PM attention.
To conclude, I believe that one should carefully evaluate the context of the project while finalizing a PM role for a Scrum project.
