Over the past several years, there has been much debate and confusion over the role of a project manager as the majority of organizations undergo Agile transformations. In fact, industry data suggests that approximately 53% of organizations are blending Agile methods with Waterfall.To be honest, I really never understood the debate. I started executing projects back in 2001 using XP (Extreme Programming) and I never had any issues with team members regarding role confusion during project execution. Agile wasn’t evil – Agile worked. Well, fast forward to 2012 and the debate continues to rage on. I finally got sick of watching the continuous debate and decided to take action. I took the classes, passed the test, and became a Certified Scrum Master. And after all that money and time spent, I can honestly say with certainty, I’m not a scrum master – I AM a project manager!
Fundamentally, I think the root cause of the debate is not based on scrum master versus project manager responsibilities but based on our fundamental definition of a project. In the Agile world of minimum marketable features (MMF’s), product backlogs, and continuous integration, the lines of the traditional project have now been blurred. I find that the Scrum team has no issues with their responsibilities back to the product owner and scrum master, but for some reason, the entire project team doesn’t feel accountable to the project manager.
My goal in writing this article is to end the confusion and the debate once and for all. To do that, I need to remind you of what a project manager is and how the two roles should co-exist. Let me get some quick definitions on the table to help structure our conversation:
The Scrum Master - The Scrum Master focuses on the development process and mentors the Scrum team. The key responsibilities of the scrum master are:
- Maintains and removes impediments
- Manages the Scrum process, making the process work
- Plans the release
- Plans the Sprints
- Shields the team from external interfaces
- Facilitates Scrum meetings as requested
- Ensures crystal clear communication among everyone involved in the project
- Technical expertise
- Understands the Product Owner's Intent
- A good team player and mentor
- Understands the teams capabilities
- A good motivator
- Problem solver
Now let’s take a closer look at the program and project management roles and responsibilities by defining a project and a program…
Project: A temporary endeavor undertaken to create a unique product, service, or result. At most organizations, the boundaries of our “temporary endeavors” are defined through our business cases.
Program: A series of related projects designed to achieve a specific outcome(s).
To state it concisely, the role of the project manager is to manage all (Ideation to post-Launch Support) aspects of the project to achieve the expected outcomes identified within the established business case (investment) - not just the Scrum Team. The size, scope, and complexity of the business case will determine the size of the project. Achieving outcomes called out in the investment may take a series of related projects – called a program. At which point, the program manager is now accountable for managing all aspects of the program, with project managers and other accountable resources managing their smaller project portions.
Right now, there are three, possibly four basic categories of “temporary”:
- Product line execution – Temporary relative to a 1 year planning cycle. Basically covering minor incremental enhancements to an already existing product line.
- Big custom projects / new product development
- Within the product line – Specific temporary initiative/projects. For example, a SQL server upgrade.
- Cross organization initiatives - Examples that come to mind are rebranding, ICD-10 (healthcare), data center migrations, etc.
These projects / temporary endeavors at most organizations typically look like this:
And it looks like this…
And it looks like this…
If this is a project, then the project manager needs to be the one accountable person responsible for managing all of this work (or for understanding and managing HOW we’re going to get the answers to the questions above in each circle) - They are not responsible for answering the questions!
To put it simply – the project manager is responsible for managing all the boxes together to achieve the desired outcome. They may or may not be responsible for managing the individual boxes. Individual box responsibility is typically done by the subject matter experts.
As you can see, Agile development and the Scrum team are only one box!
Specifically, the project manager is responsible for:
- Understanding the intended outcomes of the project and ensuring the outcomes are realistic and measurable. They need to understand the outcomes expected from the business case!
- Collaborating with the team to define the scope of work (e.g. under each colored box above, what’s in it, what is the expected outcome), who is responsible for delivering it, and when will it be delivered. Specifically:
- Deliverables required to complete all the project work
- Cross-functional resource assignments
- Estimates to complete the work and dependencies between work items
- Understanding the point person from each functional team(s) associated to the work (each colored box) and how they have been allocated for managing their work. If allocation bandwidth issues exist, this person would be responsible for facilitation and ultimate resolution of the resourcing issue.
- The job of the project manager is to remove ambiguity in roles and responsibilities by clearly mapping out activities against expected outcomes relative to time. Identifying the interdependencies between deliverables and functional teams up front will better determine what teams should be more integrated and when, relative to the overall product development process.
Important note: if the scope of work is large enough, another project manager/person may be assigned to specific items (smaller box). The relationship would be a dotted line from this other person to the project manager.
Said another way, if each one of the smaller boxes above is large enough in scope to be considered its own project, then the program would consist of several related smaller projects rolled up underneath the program.
- E.g. Hardware or software procurement, installation, and configuration – Application Operation Project Manager
- E.g. Agile product development – Product owner/scrum master
- Understanding the process and tools required to manage the scope of work relative to the outcomes identified in the business case. Understanding the metrics and the process for achieving those metrics/goals.
- If an identified metric is that the project be completed within a certain capital budget, then the project manager is responsible for understanding the tools and processes required to forecast and track the work. They are NOT responsible for creating or establishing those processes – unless of course that creation has been identified as another project!
- Project managers are responsible for the overall communication regarding the project (not just the development portion of the product). They’re the primary single authoritative source of information to ensure a shared understanding of all parameters:
- Scope
- Cost management
- Timing
- Assumptions / constraints
- Risks / issues
- Resources
- Quality
- Special considerations / exceptions
- Development methodology considerations
- Team members and associated roles and responsibilities
- Policies and procedures
So, if you agree with all of the above, is there really a debate between the two roles?
There’s no way, going through Scrum Master training that I could be responsible for all the responsibilities of a project manager. It’s just not fathomable and would lead to ultimate project failure. To set the record straight, project manager is NOT synonymous with Scrum Master. A Scrum Master is critical to the facilitation and execution of the Scrum team. But they’re not responsible for all the components of a product development project. If anything, a Scrum master should be a dotted line to a project manager as part of the reporting structure.
However, for all these relationships to work together, we also need to know what the responsibilities are of the team back to the project manager.
Essentially, the project manager has to know just about everything that’s going on during the course of a project in order to determine if the right action and the necessary progress is being made against the tasks and deliverables. It’s unrealistic for every meeting and every action to be in the project manager’s schedule. However, they still need to know what meetings are occurring and when communication and decisions are expected in order to ensure the team is working effectively and efficiently relative to the agreed upon scope and success criteria of the project.
This relationship between the project manager and the team is not meant to be based on command and control, but rather based on trust and optimizing collaboration. If the project manager has any chance in managing these responsibilities while not having authority over most, if not all, of the team resources, then they need to rely on those team leads for basic and fundamental information. The following are the characteristics of the entire product team including the project manager:
- Openness regarding truthful task and deliverable progress
- Frequent and constant communication
- Commitment to achieving the success criteria
- Courage to tell the truth
- Respect for each other
- Communication regarding the prioritization (and change) of requirements, MMF’s, sprint backlog items, and tasks
- Commitments to results based on agreed upon milestones
- Communication of estimates of effort to implement User Stories and tasks to complete all project deliverables
- Communication of dependencies between tasks and team members
- Identification of obstacles and informing the project manager when those obstacles may occur and when they have occurred.
- Self-organizing – Individual teams within a project have to be self-organizing and can’t rely on a command and control style project manager. However, self organizing means informing the project manager on how the team is self- organized and how they intend to complete the work. Project manager’s need to have context for any of this to make sense.
- The team has the right to do everything within the project guidelines boundaries to achieve the project goals.
In the product development world, project managers, more than ever, are critical in the successful execution and delivery of projects/products to market. Role clarity and collaboration is essential. The project manager and the scrum master are meant to work collaboratively with each other not against each other. If we can get our definition of a project correct and we can enforce the responsibilities of the team back to the project manager, then I can say confidently “Project managers, there is no need to worry about job security. You’re still a valuable member to your organization. If anything, your job just got easier by the introduction of the scrum master and product owner roles.” Happy delivery!
Don't forget to leave your comments below.
Comments
I had always assumed that the client(s) already "knew" this, as it was quite apparent to me (30 years PM'g...) but you have provided a nice Communications Item that lays out the definitions, the responsibilitie s and the expectations of the roles.
I know, I know - never assume, right?
In my role as a Scrum Master, I am responsible for the agile development of products... as well as interfacing with SMEs and the business to coordinate and manage all other tasks/expectati ons/deliverable s for launch.
It sounds like your role as Scrum Master is stretching the boundaries of how the role is defined by our friends at Scrum Alliance. I would say you may be called a Scrum Master... but you are, in fact, acting like a project manager... and your org is probably thankful for it. ;-)
Keep it up!
Steve
You both have good points but I think that the PM role starts with smaller firms & sizes up to the point where a Scrum Master is required in a Team Lead specialization role.
You could, for a specific software development firm, say the SM is first, but reality says, it's a project.
BTW, I've been doing this for 28 years now -- starting long before it was called a "real" job. I hold PMP, CSM and other certifications but at the end of the day I also know it's more about what value those I work with (and more importantly I) believe I contribute than any business title.
Thank you Leyton for your comments. I sincerely appreciate them.
I also agree with you on the helpfulness of your article. Any discourse promoting respect for the profession and those of us in it cannot but help be that.
My disagreements are your assertion of the root cause behind this topic's life, that a Scrum Master's focus is the development process (i.e. a scrum master too can manage all the boxes together), that they are usually the team lead, and that the PM and the SM are two different roles and/or people rather than approaches to tackle the challenge of yet to be realized deliverables. The current, long term tangible example I'd offer is my experience interacting with the Disney corporation. People are not managers, PMs, SMs, developers, testers, etc; they are cast members. One of my favorite quotes is from Walt Disney himself who was once quoted from his berating of an executive who was behaving poorly to a gardener working outside his office. Walt called that exec into his office and told him "There's only one tyrant in this place; and that's me!" (Walt was not a tyrant) meaning that we all do our part and the parts working collaboratively together doing what they each do best are what create the greatest value. Hope this helps. :-)
My job, however, is to enable, motivate and empower groups of people so they are as effective and productive as they can be to create, enhance and innovate new software, business practices and release initiatives to meet customer needs and expectations as efficiently as possible. I prefer to do this using whichever Agile methodology or framework best suits (aligns to) the initiative. Whether I'm called 'Project Manager', 'Scrum Master', 'Joe Schmoe' or any other label is really inconsequential to doing my job.
Philosophically, I think we are more aligned than you think. I do think we get caught up in roles and forget about the value we are supposed to be providing. Hell, I wrote a book about it... and perhaps I need to write an article on that.
I do understand your perspective and comments now. Your explanation really helps. I know your comments are directly related to the article... but I bet under different circumstances we would probably be sharing very similiar view points over coffee. ;-)
Thanks for commenting!
Just because the same person is assigned to multiple roles does not mean that one role encompasses the duties of all assigned roles. It just means that one person has been delegated the different roles and that they have the responsibility to perform each of the multiple roles as if each role was their sole responsibility. Hopefully, this occurs in a "small project" environment. When personnel are spread too thin on larger efforts, the cost savings usually is insufficient to pay for the project failures that result from mismanagement and/or oversights.
To further support your assertion that there is confusion by many in their general understanding of the difference between a PM and an SM, look at the "Qualifications " required for a Project Manager position in all of the employment offerings on the internet. A large percent require "Scrum Master" or "Agile" experience. And, many are with large corporations where the assignment of multiple roles is less likely to occur.
I've been a project management consultant to the govt. for 36 yrs., the last 8 as a PM of a s/w devel team internal to the U.S. Navy. I can tell you that there are more challenges for a PM than the development effort; funding cycles, expiring funds, customer's expectations and their need to fully define rqmts before project approval, to name a few.
Once again, Steve, thank you for a very insightful discussion of this critical point.
I ran into the same type of issue while working for an organization that made Six Sigma part of it's DNA.
Six Sigma took over the PMO and defined the role of a PM - as nothing more than a project co-ordinator. They were so focussed on Six Sigma DMAIC and DMADV methodology that they completely discounted/deva lued the importance of Project Management.
I worked with the Six Sigma project teams for many years and, in the process, tried to adapt the PMBOK into the Six Sigma project methodology, without success.
In the end, there was an outright revolt between our IS department (who needed to use SDLC methodology) and the Six Sigma department. Six Sigma simply couldn't execute projects.
I no longer work for the company but I am happy to report that Six Sigma no longer plays the lead role in Project and Program management within the company - but it was a painful, costly and useless lesson to learn.
Like you, I am also tired between various debates between Agile and Tradional project management. Both the groups writing innumerable articles to prove their point.
You have really balanced your article by providing the facts about both the methodolgies and then concluding it by adding your expereinces. We need more people with your line of thoughts so that we can take the positive points from the two lifecycles rather than finding the shortcoming of them :-)
I think the confusion around the Scrum Master and Project Manager roles is due to a lack of understanding that Scrum facilitates organizational change. The change does not simply occur on the technical side, but on the business side as well. That's been my experience in an organization that has failed to make the full transition to agile methods.
What I think happens is that the IT department decides that an incremental and iterative process will yield better results. Rather than simply modify their processes to allow for iterative and incremental development, they adopt a methodology. They mistakenly think Scrum is just like any other agile method, and adopt it. But they hit a roadblock, because it's a project management methodology, not strictly a software development methodology. It requires organizational change in order to produce its intended results. Business organizations are highly resistant to changing just because the IT department got the brilliant idea to use some new development process. From their perspective, "IT has their processes, and we have ours."
Scrum is a tool for transforming an organization, not simply a better way to develop software. Because of this, it is being used to build all sorts of products that have nothing to do with information technology. It is not equivalent to Extreme Programming, although many of the practices of XP are used if the Scrum team develops software.
All the responsibilitie s of a Project Manager are present in Scrum, but they're divided among different roles. This is either not accepted or understood, hence the confusion.
I may be off to some degree, but that's my perspective.
http://tech-book-store.amazon.com/post/Tx1ZW9I0O0HAQLJ/A-Hybrid-Approach-to-the-Product-Lifecycle
Let me know what you think.
Thanks again!
Steve
I am wary about "industry" best practices. I'm not sure there's value in believing in such a thing. There are practices used in the industry. Some will work superbly for you, given your organizational culture, knowledge and skill of your teams, etc. Some will not. You are free to choose to do what works best for your organization as it is, or to evolve your organization to the point of being able to adopt something that will be more effective than what you currently do.
The biggest problems in projects, and with the development of products, that I see at the moment is there is a level of thinking and communication that is insufficient for producing high quality results. Reflecting on the level of quality and excellence you currently achieve, and considering and experimenting with ways of taking that to another level are the best that I think you can ask of yourself. If you continue with a process of reflection and experimentation , followed by adoption of successful experiments, I believe you will eventually arrive at a way of structuring people and performing work that would at first glance seem bizarre (if not awe inspiring) to outsiders.
I agree with the title of your article, let's end the debate. Do what works best for you, and then explore ways of getting better at what you do.
Thanks again!
Steve