Among the many conversations that Scrum inspired in its earliest days, the debate on traditional project managers and the project manager responsibilities in Scrum has been one of the most heated ones. Today, we will do our best to look at this problem from every conceivable angle all the while keeping in mind the various factors that contribute to this subject being one of the most controversial in Scrum.
Traditional Project Management
In order to understand the debate on the project manager responsibilities in Scrum, it is necessary to understand a thing or two about traditional project management and traditional project managers.
While certain proto-project managers existed centuries and millennia ago, the traditional project management we are interested in was born towards the end of the 19th and the start of the 20th century with Henry Gantt (yes, that Gantt) and Frederic Taylor laying down the basics. A number of other people, theories and concepts (including predecessors of many Agile principles) also contributed to project management throughout the 20th century, but that’s not what we’re interested in today.
We’d recommend The History of Project Management by Mark Kozak-Holland if you want to learn more about this subject.
What we are interested in is that this traditional project management resulted in certain core responsibilities of project managers to be defined, such as:
- Ensuring that the project meets objectives
- Estimating the scope of the product
- Managing the change in scope
- Estimating time and cost requirements
- Managing and mitigating risks
- Planning and sequencing of schedules and activities
- Negotiating work with the team
- Removing impediments and assisting the team
- Serving as a focal point for information on the project
- Managing stakeholder communication
- Tracking, reporting, keeping documentation
It should be pointed out that these are just some of the standard project manager responsibilities and that they will vary depending on the organization, the project and the project manager’s approach.
In addition to this, we have to understand that this traditional project management was born in industries such as construction and manufacturing and that the majority of its subsequent development was influenced by practices from such industries which preferred projects going through sequential phases, e.g. the waterfall model.
The reason why this is important for us is that the software development industry in its early days adopted the waterfall model, especially in larger organizations. Subsequently, this played a major role in the inception of Agile software development (including Scrum) and its “relationship” with traditional project management and managers.
New (Agile) Software Development Reality
By the early 1990s, it was becoming clear that the waterfall model didn’t really work for teams developing (then) modern software, mostly due to the fact that it was ill-suited to accommodating changes that were occurring past the design phase.
Unfortunately, one of the tactics employed by large organizations to remedy this was to encourage project managers to double down on the more micro-managing and intrusive practices. As a result, many in the software development profession started seeing traditional project management (and managers) as the core of their problem.
In combination with the need to garner attraction by being aggressive in breaking with the tradition, this inspired the early leading figures of Agile software development to paint traditional project management as the bad guy and to do everything in their power to remove it (project managers included) from the process.
As for Scrum, the official Scrum Guide ended up not prescribing a project manager as part of the team. Instead, it introduced new roles which took on those responsibilities.
Scrum Masters and Product Owners Taking Over
One of the reasons as to why Scrum became the most commonly adopted Agile software development framework is the maturity with which it approaches the business side of developing software, including the project management aspect. It reassigns the classical project manager responsibilities to the Scrum Master and the Product Owner.
As you can see, the role of the Product Owner takes on the majority of business-side, product-related responsibilities while the Scrum Master focuses on the team responsibilities. Both these roles have additional responsibilities, but it is important to notice how they take on those traditionally handled by project managers.
As a result of this, in many organizations that practice Scrum, traditional project managers are often the ones who assume one of these two roles. In such cases, they often play a dual role - as Scrum Masters/Product Owners on a tactical level and as Project Managers on a strategic level. Of course, finding the right balance in those situations and moving away from certain “traditional” practices, such as overly passionate management of the team, are the biggest challenges.
Finally, we should point out that Scrum puts some of the responsibilities into the hands of the Development Team, as well. For example, the Dev Team decides on the amount of work it takes on in a Sprint and handles the internal organization of the team (it is self-organized).
A Place for a Project Manager in Scrum?
Scrum “purists” will most likely cringe at the notion of this, but we have to be realistic and at least consider the fact that, in certain situations, a project manager (one who has not assumed either the SM or the PO role) might be a welcome addition to the process if everyone approaches it the right way (and with a bit of agile training if needed).
Let’s take as an example a company that develops software for outside customers and assigns a Scrum Team to each project. In such cases, the role of the Product Owner is usually assumed by someone on the client side.
In the majority of cases, they are not aware of what this role entails which makes it near impossible for the rest of the team to do their jobs. In such a situation, it falls to the Scrum Master to educate the Product Owner and advocate good Scrum. In theory.
In practice, the Product Owner has limited time and willingness to get into the intricacies of Scrum and their new role. Instead, they need someone to coordinate the business side of the project with them (something most Scrum Masters are not equipped to do) and act as a bridge between them and the rest of the Scrum Team.
In such situations, the project manager can be the solution, supporting the Scrum Team (in true Scrum fashion) and working together with the Scrum Master to help all parties involved get what they want. It is not uncommon for project managers to be called proxy product owner, vendor-side product owner, or service-delivery manager in such cases.
Another case in which a project manager can be a welcome ally to the Scrum Team is in large, complex organizations with massive bureaucratic structures in place. In such organizations, Scrum Teams have to exist in an ecosystem that is riddled with politics, governance and regulations, established processes, documentation and reporting, complex stakeholder structures and much more.
In theory, the Scrum Master is the one to protect the Scrum Team in such an ecosystem. However, many Scrum Masters do not have all the skills and the experience to handle all of this, while in some cases they are simply spread too thin (being Scrum Masters to more than one team, also handling development work, etc.). Even in situations when they are well-equipped, this would consume far too much of their time, causing them to neglect other aspects of their role.
Once again, a project manager might be just what the team needs, facing outwards and providing an added layer of protection for the team.
After all, we get down to transparency, inspection and adaptation. If it is obvious that an addition of a project manager might improve a Scrum Team, is it really in the spirit of Scrum to ignore this because of old grudges or some other reason?
Project manager responsibilities in Scrum are a complex issue when one considers the history, the new roles Scrum introduces and especially when one is realistic about the various environments in which Scrum Teams operate.
Still, with a bit of good faith and a lot of good collaboration, Scrum projects can run like clockwork.
If you are looking for a free tool that will help you manage your projects (whether you are a Project Manager, Product Owner, Scrum Master, or none of the above), make sure to give VivifyScrum a go!