When traditionally managed organizations first adopt Scrum--an agile project management approach that includes the roles of Product Owner, ScrumMaster, and Team Member(s)--there is often an assumption that project managers are the default choice to serve in the role of ScrumMaster. But examining the definitions of these roles as found in leading sources suggests that this assumption is probably wrong or at least misguided. In fact, the responsibilities of project management as defined in traditional literature are not aligned with the ScrumMaster role at all. Despite this apparent disconnect, the Scrum framework incorporates more traditional project management practices than is at first apparent.
To help organizations understand how, this article will first outline how traditional project management responsibilities line up with Scrum roles and then highlight the important shift in mindset required for an agile implementation to yield its benefits.
What is Scrum?
Before we begin discussing how traditional project management and Scrum line up, it is important to begin with a cursory definition of the Scrum framework. Thought most Scrum concepts will be familiar to experienced project managers, the specific language and mechanics may not.
Scrum is an agile project management approach that combines an empirical process model with clearly defined roles for the management and execution of that process. Within the Scrum framework, there are three roles: The Product Owner, the ScrumMaster, and the Team. Work is performed iteratively and incrementally within repeatable 30-day work cadences known as “Sprints.” This process is managed through three primary meetings: Sprint Planning, which occurs at the beginning of the cycle and determines which work the Team will tackle; Daily Standups, which bring Team members together for a few minutes each day during the Sprint to communicate progress and dependencies; and Sprint Review, which occurs at the end of the cycle and is used to assess whether Sprint goals have been met. Finally, the process is managed through a handful of planning and progress artifacts, including “backlogs” (for planning) and “burndowns” (for reporting).
Traditional project managers will immediately recognize various aspects of the Scrum framework. For instance, its process model is built on what the PMBOK® Guide refers to as “rolling wave planning,” in which the development plan is progressively elaborated and the product is built incrementally over the course of consecutive development iterations. It’s also strikingly similar to the “Deming Wheel,” advocated by quality guru W. Edwards Deming (i.e. “Plan, do, check, act.”) and well known to any experienced project manager. However, the key difference lies in the distribution of responsibility and authority across the framework’s three roles, which include all of the management functions described in the PMBOK® Guide, but are executed as a system of checks and balances among the roles.
What is Project Management?
In order to discuss how project management responsibilities align with the roles in Scrum, we first need to review the definition of those responsibilities as found in PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition.
According to the PMBOK® Guide, the project manager is “assigned by the performing organization to achieve project objectives.” To do that, the PMBOK® Guide prescribes a collection of processes and practices in nine “knowledge areas.” The heart of project management lies in the first four: scope, time (schedule), and cost (budget)--the so called “triple constraint,”--plus integration management to tie it all together. Nearly all PMs are responsible for managing the triple constraint.
In addition, many PMs are responsible for managing other aspects of their projects described in the other knowledge areas (e.g. Quality, Human “Resources,” Communication, Risk and Procurement). Ultimately, which of these the PM is actually responsible for depends on the organization and the judgment of the PM and team. In practice, the application of these knowledge area processes often includes responsibility for assigning tasks to the development team, various methods of monitoring and controlling the team’s execution, reporting progress to stakeholders, managing conflict, etc. As if all that wasn’t enough, the PM is usually responsible for myriad other factors including acting as the de facto business analyst to help the stakeholders define the features of the product, gathering product requirements, and so forth. Furthermore, the PM often shoulders all this responsibility in absence of