Role of a Project Manager in Scrum


We had a great turnout at DFW Scrum last TUE for “The Role of the Project Manager in Scrum”. Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself facilitated this fascinating conversation. The reality is, there is not “standard” or “cookie-cutter” approach to the answer. Every culture, company, value system, etc… are a little different (or a lot for that matter). So we took the approach of facilitating conversation more than giving answers, because honestly; most people in the group have the answers, they just need validation if they are violating Scrum values.

The one big point that does apply to each company is that while the role itself is not described in Scrum, the responsibilities and duties still have to be done. Typically those duties and responsibilities are absorbed by the 3 roles in Scrum (Product Owner, Scrum Master, or Development Team). We also found some duties that aren’t necessarily part of Scrum, but needed by the organization to drive visibility, transparency, and coordination. Those burdens should be placed on the team and we should work together to figure those things out and who is best to serve those duties.

There are some organizations that exist where Development (the Scrum Team) is just a small piece of the overall “project”. In that case, we might have a project manager taking the metrics from the Scrum Team and providing visibility to the overall timeline for the other pieces. In Software, many of the Go To Market (GTM) activities might not involve the Scrum Team at all. As such, a Project Manager might piece together the finished software with the sales, support, finance, etc…

In other cases, perhaps a Scrum Master fulfills those duties in tandem with the Scrum Team duties. It really just depends. Whatever the case, the word “Project Manager” should not be a deterrent to doing Scrum. Scrum is very adamant about some things and does not outline a role for Project Manager, that doesn’t mean that we can’t figure out how to carry out the functions of the role in its absence (or presence). Be pragmatic and work as a team to figure out what works best. A traditional Project Manager tends to have duties and responsibilities that violate the tenants of Scrum. That is why aspects of that role are transferred to specific roles on the team.

Don’t let compliance and other “governance” terms deter you either. Those can be built into the definition of done for the team and considered in all aspects of our planning and completion. Naturally there are some governance processes that actually hinder productivity of the team, let’s be transparent about that and show the impact of the team and then have the team propose some possible solutions.

Attached is our Deck used to facilitate the discussion, the big take-away is this: “What kind of organization are you”? Each one presents benefits and challenges of Scrum.

Types of Organizations

  • All Scrum Masters (0:n)
    • No Project Managers, only Scrum Masters
    • Not the same as all Project Manager titles have been replaced by the title of Scrum Master
  • One Project Manager and One Scrum Master (1:1)
    • Every project has a Project Manager and a Scrum Master
  • One Project Manager and Several Scrum Masters (1:n)
    • Every project has a Project Manager but there are several Scrum Masters

September Dallas Recap: Integrating UX and Agile

This month was focused on one of the challenges commonly faced in agile adoptions: how to integrate UX and agile. We saw many new faces at our meeting, which confirmed what a hot topic this is. David Belcher, Director of User Experience at Improving Enterprises, shared his personal experiences and answered questions throughout the evening. As he reviewed the Good, the Bad, and the Ugly of uniting the UX processes with Agile, it was clear that there is no simple answer.

If you missed the session and want to know ideas for a successful UX and agile merger for a project team, there is a video of this same presentation available online from the AgileDotNext Houston conference (thanks to

About David Belcher: 
David is a Consultant and Director of User Experience at Improving Enterprises. He has over 10 years of experience doing UX and most of that time has been working on Agile teams. UX is David’s passion and enjoys doing everything from user research, visual design and even gets into front-end development. When he is not working enjoys life and tries to live it the fullest by traveling and learning new things.

Agile Jeopardy–Not as Easy as You’d Think

Last month we played Agile Jeopardy, and the questions and answers related directly to the Agile Manifesto. Four values and twelve principles—how bad could it be? Turns out most people don’t have them memorized, and our teams had a rough time.

Should we know the Agile Manifesto by heart? Quote it in the office? Recite it when we wake up and before we go to bed each day? Unless you’re playing Agile Jeopardy on a frequent basis with me as the judge, you probably don’t need to go to such extremes. But there is tremendous value in reviewing the Agile Manifesto periodically (a couple of times a year) and revisiting the significance of the values and principles. What does each piece contribute? What if it were written differently? Just how agile is your team?

I worry sometimes as an organizer that I’m not doing enough to serve the community’s needs, and I feared that our game of Agile Jeopardy might have been too much for some folks. Games bring out competition, and our teams were struggling to respond with just the right answer. Thankfully our teams took it in stride, and Chris Murman even wrote his own blog post on what he learned from the evening’s activity. We all need a good reminder now and then of “the basics.”

Recap of Dallas’s July meeting: Overcoming the fear of Sprint Retrospective

July’s topic was posted by a community member on our meetup site, and after receiving a number of votes, we decided to make it the focus of a Wisdom of the Crowd night. What’s a Wisdom of the Crowd night? It’s one with no formal speaker or presentation—we enable our community to share their experiences and questions to generate new ideas and learning for all of us! We use an open space format to allow for deeper discussions of subtopics in smaller groups; if a member is interested in more than one subtopic or isn’t engaged in the group he’s in, he can move to another group without questions or judgment. Best of all, each group shares its findings at the end of the night with everyone, so we can all benefit from their learnings.

The meeting topic was Overcoming the fear of Sprint Retrospectives:

The sprint retrospective is by far the most underutilized and under appreciated meeting. Team members dread to go these meetings. Every Scrum Master has his own technique on how he overcame this and there is always room to grow.

We kicked off with some of the questions on our minds and split into multiple groups based on which question we wanted to explore further. The groups had rich discussions and came up with so many ideas that they used the whiteboards to capture them:

DFW Scrum - retrospectives 2 DFW Scrum - retrospectives 3DFW Scrum - retrospectives 4DFW Scrum - retrospectives

DFW Scrum – Second Quarter Summary

Here’s a recap of our meetings for the quarter:

April: Definition of Done, Chris Murman

Many companies practicing agile talk about the definition of done, but how many teams adhere to it on a sprint-by-sprint basis? Expectations that are either unmet, not communicated, or mismanaged are usually the source of our problems.

Chris presented some practical ideas on how to define “done” in your organization and didn’t stop there. He presented a bigger idea that surrounded the topic and gave everyone something to take back to their offices.

May: Using NPS Scoring at Sprint Reviews with Customers, Simon Cockayne

It’s extremely difficult to understand the link between a given user story and the money that could be saved/made by customers. But could customer happiness serve as a proxy to the actual or perceived value that the customer sees? Could we determine how happy each delivered user story made the customer?

So Simon introduced a Net Promoter Score (NPS) approach to determine how happy customers were with a delivered user story in a sprint review. NPS is based on a direct question: How likely are you to recommend our company/product/service to your friends and colleagues? The scoring for this answer is most often based on a 0 to 10 scale.

The results were wonderful:

  • customers were super keen to try something new.
  • the scores showed that they LOVED the stuff we were doing.
  • the scrum team was STOKED to see the high scores–that helped boost scrum team morale in the next sprint.
  • customers started interacting with each other as they discussed the value they perceived, lots of good spirits and good humor, to boot.

June: You Want to Use Scrum, You are Told to Use CMMI (How They can Work Together?), Neil Potter

The CMMI-DEV model is a collection of practices aimed at organizations that develop products, systems and IT solutions. The model is organized into five levels; each level defines more advanced practices to improve schedule, budget, risk and quality performance. The levels provide a road map for sustained incremental improvement.

CMMI practices can be implemented within any life cycle or methodology (such as Scrum, Waterfall, Spiral or Incremental). The benefits from using CMMI Level 2 and 3 practices are:

  • Clarify customer requirements early
  • Scope, plan, estimate and negotiate work to manage expectations and achieve commitments
  • Track progress to know project status at any time
  • Maintain defined quality standards throughout the organization and report strengths and problems to management
  • Manage versions of documents and code so that time is not wasted using incorrect versions or recreating lost versions
  • Manage and coordinate multiple teams that have cross dependencies
  • Employ engineering practices for design, implementation, verification and testing to reduce defects
  • Use defect data to understand and manage work quality throughout the project
  • Collect lessons learned and project data to systematically improve future organizational performance

For more information, view Neil’s presentation here.

Certificate of Occupancy


Have you ever been in your building and noticed a “Certificate of Occupancy”? These gems enforce a safe occupancy number that are built around fire codes. How many people could realistically exit this building in the case of a fire? My question, as it relates to software development and Scrum Teams is; why don’t we use this same kind of approach to protecting the sustainable development pace for our team?

This came to me really quickly as our office is expanding. No matter what WE want to do, we are bound by the occupancy certificate stating that we can only fit X number of people in this building. If we violate that (and are caught) the consequences would be great with the city, but even greater if we did have a fire and were not able to get out. Part of Scrum’s role in our teams is to help us identify and stick to a constant and sustainable development pace (throughput). As such, we should have “certificates of occupancy” in place to help us legislate that rate. Most often however, we are constantly pressed by management or our Product Team to do more, regardless of the cost. Most teams are actually rewarded for their outstanding effort and exceeding their capacity. Don’t get me wrong, we want our Product Team to want the world and push us. But, what happens if you run your engine at 15,000 RPM for a long time? What happens when your CPU is at 100% capacity? What happens if the highway system is at 100% (or even more)? Things come to a screeching halt and permanent damage ensues.

People (like computers and engines) are not built to operate consistently at 100% capacity or more, and doing so has grave consequences for productivity in the long term. Helping a team become aware of their sustainable rate, and predicting delivery off of those metrics inherent in Scrum; help maintain that level of stability. The team has control over what to commit to and what to hold. The pressure is less because the backlog and roadmap are built with their sustainable pace in mind. Believe me, if you don’t give dates for delivery, someone will. So it might as well be the development team, armed with great historical evidence of their ability to deliver as well as planning deliveries based on those realities and accomplishments.

I am certainly not saying there isn’t times where we do come together and work extra hard to get things done. I’m just saying those times have to be throttled and well understood by everyone. In addition, we should be really good at what we do and have discipline and rigor in our processes. As we continuously improve and search for better and better ways to do things, we will be productive and increase our output within our sustainable rate.

If we wanted to have more than X people in our building, we could petition the city for a permit that would increase that number (or not). The burden of proof would be on us to indicate the value of such exercise and the safety measures we put in place to allow the increase. The point is, we just can’t arbitrarily state “we need to work harder this sprint to get Y done”. Next time it will be “Z”, “A”, and “B”. That will never go away. Put checks and balances in place to ensure when you violate the sustainable and constance pace in Scrum, that we recognize the impact of that and that we are doing it for real reasons. If you want to increase the certificate of occupancy in your backlog and sprints, do so with the team and build roadmaps based on sustainable pace. Running our engines at high RPMs should be the exception, not the rule.

The Flat Tire


In regards to Scrum, many people struggle to wrap their heads around the process. While it is a fairly simple framework with very little rules and prescription, it is very difficult to actually do; logistically speaking. Build a backlog…ok, well how do I do that? Have a sprint review…ok, well how do I do that?

What actually holds this thing together is the vision and goal of Scrum. The goal is to enable us to get / manage / expose our work in a consistent process while consistently increasing our Agile Engineering practices that will allow us to ship the most valuable software we can for our customers when we want to ship it. This implies that whatever is getting in the way of you shipping software needs to be resolved. Scrum’s goals are to actually expose all of those reasons why we can’t get our code from our developer’s machines into Production with little to no human interaction along the build, test, and deploy path.

Manual testing will eventually show you that you aren’t able to move quick enough each and every time you want to ship. Not having a good backlog before your next sprint will show you that you are very reactionary and as such aren’t able to ship valuable software each sprint. Scrum exposes those leaks and that’s a good thing, celebrate when you find an inefficiency; that is something that we can all fix and improve.

One of my close colleagues in the industry has always said that Scrum is like a syringe that injects Agility into the organization. I love that analogy; I have also thought of many myself. Scrum is like going to the tire repair center. If you suspect a leak in your tire, a lot of the times, you just don’t know where it is coming from. We take it to the professionals as they can expose the leak with a tried and true technique. Take the tire off, soak it in some soapy water, and voila’ your leak appears (or maybe several leaks appear). Now, we can actually fix those leaks and get the car back on the road. What if, we found those leaks, and simply just put the tire back on the car and said “yes, there are leaks, we just don’t have time to fix them now”. At that point, you would likely drive off and continue to waste time by putting air in your tires; only to have it leak out later. Worse, you could be left stranded on the side of the road because of a flat. The right thing to do is to stop down, fix the leak, and then move on.

Scrum exposes those leaks. We the people, still have to fix our problems. No one thing or process can fix our problems, we humans have to dig in and find out the best way to solve the problem. Scrum is that agreement between the team to react to things in an empirical way, not a planned/predictive way. Take the time to take the tire off the wheel, soak it in water, find the leaks, and fix them. Some leaks are so big that we have to replace the tire. That’s ok too, celebrate that we learned of that problem. Our goal is to ship valuable-quality software when we want to and leaks prevent that from happening. Fix the leaks.