This article originally appeared on Agile Journal on Tuesday, November 17, 2009. To access it online, visit: http://www.agilejournal.com /articles/columns/columnarticles/2507-an-agile-pmisnt-what-you-think-subhead-where-doestraditional-projectmanagement-fit-in-an-agileproject-using-scrum An Agile PM Isn t What You Think Where Does Traditional Project Management Fit in an Agile Project Using Scrum? By Jimi Fosdick 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 any real authority. PM Responsibilities and Scrum When Ken Schwaber and Jeff Sutherland, the creators of the Scrum framework, developed the disciplines roles, they intentionally divided the multifarious responsibilities of project management across multiple roles and endowed those roles with the authority to accomplish their objectives. According to Ken Schwaber: In the past the PM was responsible for figuring out what had to be developed and how, and then ensuring that the people doing the development did what they were supposed to. We decided to put responsibility with authority. The PO (customer representative) is now responsible for figuring out what has to be developed. The self organizing Scrum team of developers is responsible for figuring out how to do it and doing it. In Scrum, the Product Owner is the customer-facing role while the ScrumMaster is the development-facing role. Furthermore, Scrum separates the what (i.e. the project s overarching objectives, stakeholder needs, etc.) from the how (i.e. how will project objectives and stakeholders needs be implemented and met). Thus the things traditionally associated with project management are distributed between the roles or shared among them. PM Responsibilities of the Product Owner In Scrum, [The Product Owner] is the person who is officially responsible for the project. This is strikingly similar to the PMBOK Guide definition of the project manager mentioned above. In addition, the PO is responsible for representing the interests of everyone with a stake in the project and its resulting product. The PO achieves initial and ongoing funding for the project by creating the project's initial overall requirements, return on investment objectives, and release plans. The PO is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon. In the language of project management, the Product Owner is responsible for achieving project objectives. It is the Product Owner who is largely responsible for managing the triple constraint of scope, schedule, and budget. However, this role still shares responsibility for time management with the team by managing the project schedule at the release level, while the Scrum Team manages its time within each iteration. In general, the Product Owner participates, to a greater or lesser degree, in the management of other project management
knowledge areas (e.g. HR and communication), but is not chiefly responsible for those areas. An important distinction between the Product Owner and the traditional project manager are that the Product Owner monitors execution at the iteration level but DOES NOT control it. Similarly, the Product Owner does not assign tasks to development, but sets iteration goals for the Scrum Team based on the needs of the stakeholders and depends on the Team to manage task decomposition and assignment, etc. Finally, the Product Owner shares the responsibility of reporting progress toward project goals to the larger organization chiefly through the mechanism of the Sprint Review. PM Responsibilities of the Scrum Team A crucial difference between a traditional project management approach and Scrum is the level of autonomy and authority accorded to the Scrum Team, which includes several responsibilities traditionally assigned to the project manager. As Schwaber and Beedle explain: A team commits to achieving a sprint goal. The team is accorded full authority to do whatever it decides is necessary to achieve the goal. In other words, Scrum Teams are considered to be self-organizing and self-managed, which marks a fairly radical departure from the description of project team management in section 9.4 of the PMBOK Guide. As we shall see in our discussion of the ScrumMaster role, a handful of the activities associated with project team management (mostly related to facilitation) will fall on the ScrumMaster, but most are now the responsibility of the Scrum Team itself. Another significant feature of the Scrum approach is that Scrum Teams are small (seven people plus or minus two) and fully cross-functional. Instead of segregating people into disciplinary ghettoes by skill set, Scrum advocates grouping all the skills necessary to accomplish Sprint goals on a single team. This Scrum Team will likely be one of several fully cross-functional teams on larger projects. It is the Scrum Team that manages scope at the individual feature level as a result of the implementation decisions it makes, weighing input from the PO as to how best to meet stakeholder needs for a given feature. The Scrum Team manages time (i.e. the schedule) for a given iteration. It is the Scrum Team that is chiefly responsible for managing quality (based on criteria established by the PO), its people (HR), communication (with help from the PO and ScrumMaster), and risk. The Scrum Team also monitors and controls the execution of work
within each iteration. In short, many of the responsibilities formerly associated with the project manager are now the responsibility of the Scrum Team. What is a ScrumMaster Really? According to Ken Schwaber, The ScrumMaster is a new management role introduced by Scrum. The ScrumMaster is responsible for the success of Scrum. Given that explanation, there really is no analog of the ScrumMaster in traditionally managed projects. Further, The ScrumMaster is responsible for ensuring that Scrum values, practices and rules are enacted and enforced. The ScrumMaster is the driving force behind all of the Scrum practices. Thus most of the ScrumMaster s responsibilities fall entirely within the purview of Scrum itself. The ScrumMaster facilitates communication between individual team members, between the team and the PO and the larger organization. The ScrumMaster is also responsible for advocating continuous improvement in quality and the process itself. The ScrumMaster makes the progress reporting mechanisms and metrics in Scrum visible and educates the PO (and the larger organization) in their meaning and use. In short, it is the responsibility of the ScrumMaster to create and foster the environment in which the PO and the Scrum Team can take charge of all the project management responsibilities they have in a Scrum context and discharge those responsibilities effectively and successfully. It is important to note, however, that the ScrumMaster DOES NOT have any authority and IS NOT a manager of people or projects. The ScrumMaster doesn t, for example, assign tasks to team members or monitor team member performance and the team doesn't report to the ScrumMaster. The Project Manager and Scrum It should be clear from this discussion of project management responsibilities and the Scrum Roles that there is no single person in Scrum with all the responsibilities traditionally associated with project management. It should also be clear that the ScrumMaster role is a new role for which there is no direct analog in traditional project management. With the addition of the ScrumMaster, the responsibilities traditionally accorded to the project manager are now divided mostly between the Product Owner and the Scrum Team with the ScrumMaster, instead, serving as an intermediary between and facilitator of both.
Given that, where does the traditional project manager fit in a Scrum project? The short, if unsatisfying, answer is, It depends. According to Schwaber, We let them go where they think they best fit. Both SM and PO are management positions, one customer facing, the other engineering facing. In my experience implementing Scrum in various organizations over the past five years, the real determining factors are temperament, skill, and interest. Different project managers are, not surprisingly, suited for different roles. A perennial issue in project management is the balance between technical acumen and business savvy. In fact, this is an issue the Scrum roles largely solve. Some project managers are more technical and thus better at speaking the language of development and interacting with the development team. These project managers may actually do quite well as ScrumMasters provided they are not hung up on being in charge. Other project managers--particularly those that come from a business rather than a technical background--are often more comfortable with and skilled in the business context. This kind of project manager may enjoy and be suited to the role of Product Owner. Finally, some project managers assigned to Scrum projects end up outside the Scrum team and roles altogether. As long as they are supportive of the Scrum principles, practices and roles, this too is a workable position. Regardless of where a given project manager goes, the essential ingredient for success is that project managers serve in the capacity in which they are most comfortable and for whose responsibilities they are most suited. It is critical that PMs are not drafted into roles which they don t want. In fact, the PO, ScrumMaster, and Scrum Team members should all be doing Scrum voluntarily if Scrum is to help the organization succeed. It is similarly important that these new roles and responsibilities are adopted incrementally over time, preferably starting with a single pilot team doing completely uncompromised Scrum. In the end, Scrum does not prescribe where the individual currently serving as project manager should go in a Scrum project, only with whom the project management responsibilities lie and, as such, organizations should not assume that project managers always belong in a particular Scrum role. A Final Thought Transforming an organization with Scrum requires much more than simply adopting its language and mechanics. Following the process and filling the Scrum roles is a necessary, but insufficient condition for enacting real change. The challenge is not only finding the role that corresponds most closely with the traditional management role or
determining where to put the project manager on a Scrum project. Instead, the challenge lies in embracing the underlying values that enable Scrum's benefits in a meaningful way. It's much more than changing people s titles--it's literally learning to look at how work gets done differently. If done fully and properly, Scrum WILL radically transform the enterprise for the better. About the Author Jimi Fosdick is a Certified Scrum Trainer with more than 14 years of experience in product development including such diverse industries as publishing, software, advertising, and the public sector. Prior to joining Danube s ScrumCORE team in November 2008, Fosdick spent four years advocating agile approaches to project management: first as a program and project manager and, later, as an independent agile and Scrum consultant. He has worked to transition such companies as CIBER, Inc., Avenue A Razorfish, MTV Networks and Microsoft to an agile approach using Scrum. Fosdick is a PMI-certified PMP, a member of the Project Management Institute and received his MBA in project management from Keller Graduate School in Chicago and, as an undergraduate, studied mathematics and computer science at Loyola University Chicago. He currently lives outside Portland, Oregon with his wife, Christine, and their children, Jaz and Sophie.