Scrum Master or Agile Project Manager: Pick One

Let me start off by saying the Scrum Master and Agile Project Manager are mutually exclusive in a mature Agile environment. I’d pick Scrum Master.

Let me also say that businesses will continue doing whatever they feel comfortable with; it’s their business. If they wish to do Scrum ceremonies and have an Agile Project Manager leading the Development Team, they will.

I was recently talking with a group of Agile practitioners and two of them said they left their jobs because the company wanted an Agile Project Manager to lead the team rather than a Scrum Master to serve the team. I had also left a company when the role changed from Scrum Master to one befitting an Agile Project Manager.

There’s a lot of published work about the transformation from traditional management and project management to an Agile environment. This from Ben Linders on InfoQ gives an idea of the effort and trauma behind an Agile transformation in a traditional Command & Control environment. However, there is little work about the opposite direction. I found this question on Agile Connections about transitioning from Agile back to a waterfall model and presumably, back to having a Project Manager.

When looking at job ads, you often see a ‘Agile Project Manager’ role description having “drive on-time deliveries” or “Ensure estimates are accurate”. The business has Scrum ceremonies but often want an Agile Project Manager to ‘facilitate’ these meeting. The Agile Project Manager runs the show and is accountable to getting on-time deliveries based on accurate estimates for the entire project, not just the next two weeks.

In Scrum, the Scrum Master helps the Development Team and Product Owner find ways to meet their sprint commitments. The Scrum Master helps the Scrum Team groom and prioritize work so the most valuable work is done sooner. The Scrum Master serves the Scrum Team and the Scrum Team, not the Scrum Master, runs the show. The Product Owner and Development Team together are accountable for their sprint results and value delivered to the customers.

Agile Project Manager

If a business is uncomfortable with Agile and unable to relinquish control to the Agile teams but they still want the buzzword ‘Agile’ somewhere, they create the role, ‘Agile Project Manager’. The title itself should tell you the company wants a project manager. I’ve heard the arguments for and against the Agile Project Manager but almost always, the argument ‘for’ tends to revolve around stakeholder management and/or the failure of the business to adopt an Agile mindset.

I was at a meeting recently where I asked the question about Scrum Master Vs. Agile Project Manager. One person pointed out the governance of a financial institution, regulatory requirements, and large number of business stakeholders to justify the need for an Agile Project Manager. However, it was also noted that stakeholder management in Scrum is the responsibility of the Product Owner. When I was Scrum Master at a financial institution, I had all the governance and regulatory requirements written as non-functional requirements, applicable for each sprint. I thought the Product Owner did a great job addressing the various concerns of the business stakeholders by working their requirements each and every sprint. So stakeholder management, even for a complex business, can be done using the Scrum framework.

The person from a financial institution also said that the rest of the business wasn’t Agile and therefore needed an Agile Project Manager to bridge the gap. In the group of 15 there was a lot of agreement but the agreement was for the business to adopt an Agile mindset. This isn’t easy but there are executive Agile Coaches who speak the language of the c-levels and can help them better see the business reasons for adopting Agile. Simply put, a Scrum Master often doesn’t have the title or clout or skills to shift the c-levels in most organizations.

To help avoid the Agile Project Manager role or to phase it out, the Scrum Master can educate and coach the Scrum Team, (Development & Product), on backlog management, backlog grooming, sprint planning, and better engagement with customers. This sounds ‘bottom up’ but positive results can help shift the executives to a neutral stance or even a pro Agile position. Where I was at, the CEO didn’t care what process the product development team followed but just wanted positive results. We adopted Scrum, had that positive result, and the CEO then asked why all the development teams weren’t using “that agile thing” (I did a guest blog post at Pragmatic Marketing called, ‘Agile: Don’t Sell It, Demonstrate It‘ which describes this).

In big institutions, it is unlikely that transformation to Agile and Agile adoption will be even in all departments. Assume it isn’t and prepare to be very visible with progress and value delivered. Visibly create several non-functional requirements that directly address the governance or regulatory concerns your business stakeholders have. The real advantage and value was by making the progress and artifacts created for governance and regulatory requirements extremely visible for all business stakeholders.


In the end, business needs will drive the adoption of a Scrum Master or Agile Project Manager role. In Agile, the Scrum Team assumes the role of project manager by taking on the responsibility to manager the value delivered in each sprint, something that solves or contributes to solving a customer problem.

If the business is adopting Agile from top down and the c-levels understand how the Scrum Team assumes the responsibilities and accountability once held by the project manager, they’ll probably go with a Scrum Master without too much drama.

If the c-levels are having difficulties seeing the advantages of Agile and Scrum, get an Executive Agile Coach to help with the transformation. Management will probably not allow the Scrum Teams the level of empowerment and autonomy necessary to function as a project manager and will likely go with a Agile Project Manager role.


Building Bridges: Closing the Communication Gap Between Product and Dev

Product Manager is the visionary who leads a product and is often held accountable for the product’s success or failure. In many Agile organizations, the Product Manager is also a Product Owner. Product Managers usually have KPIs based on deliveries and revenue or sales generated from their product. In normal circumstances, a Product Manager is doing marketing and sales planning, customer interviews (with UXD), managing their product portfolios, writing requirements and user stories, meeting with business leaders, presenting roadmaps, projecting revenues for this and the next fiscal year, and working with development teams.

It’s clear the Product Manager is a busy busy person who has little to no spare time in their day. When it comes to time budgeting, what often suffers first is direct communications with the development teams.

The problem

When Agile came on the scene, the requirements that were once written upfront become stories that are told just before implementation. The Product Manager, now Product Owner, needs to spend more time directly collaborating with the development team, especially during implementation. This is where communications tends to break down.

In VersionOne’s 7th Annual State of Agile 2012 Development Survey,

“communication between Dev/Product Owner”

is the third most frequent cause of agile project failures. In recent State of Agile reports, communications problems are consistently in the top ten causes of agile project failure. (See reports for 2013, 2014, 2015).

In talking with different Agile teams, I hear developers consistently mention the Product Owner and requirements as a problem. Developers would like to see the Product Owner write detailed requirement specifications. In a twist of irony, they would like these details written up as a user story.

Product Owners say they are frustrated at the apparent slow pace of development. They mention that developers seem to be ‘always’ interrupting them for clarification of requirements and are asking technical questions.

When I ask developers who writes user stories the answer is almost always the Product Owner. If I ask Product Owners who writes user stories they say themselves. This shows people having a strong attachment to traditional roles and job descriptions. It also implies a cultural impediment to Product Owner-Development collaboration. If I ask either Development or the Product Owner if they should talk with each other, the answer is yes but with a caveat: they each say the other should come to them.

There’s plenty of literature that speaks on how Agile user stories are developed. Roman Pichler writes that user stories are the result of collaboration. Atlassian suggests the full product team collectively decide the more detailed requirements. Mike Cohn says that the writing user stories is less important than discussing them.

By mentoring and training, the Agile Coach can convey both the reasons for and the expected results of better communications around user stories & requirements. However, this brute force method has taken me a year in some cases and even then, only with the strongest top down management support.

I’ve helped organize user story grooming sessions intended to create better understanding of the customer problems to solve. I’ve also organized customer interviews with the development team. These work well in the near term but constant vigilance is necessary to prevent falling back on old and easier habits. If the company’s culture puts great weight on roles, I’ve found communication reform and increasing collaboration to be most difficult.

Is there a way to establish and perpetuate the desired communications and collaboration between development and the Product Owners?

The solution

There’s usually a desire to improve but if the culture gets in the way, improving can be hard. If you’re a developer in a non-agile environment, you’re used to having work flow down to you. You’ve become acclimatized to being told what to do. Agile spins this around where collaboration becomes the objective and common understanding the results. Sounds easy but very hard in reality.

Mentoring and training can help but only as far as the cultural limits allow. What’s needed is a way to work around this and yet stay within the boundaries established, and enforced, by the company.

Introducing the “Development Product Liaison”

Development Product Liaison is rooted in the world of Startups where the founders work closely together to develop an MVP. The idea is development needs to be across the customer problems and the potential business of solving these problems early in the product ‘ideation’ phase.

The Development Product Liaison is a member of the product’s development team who bridges both communication and understanding gaps between product and development.

What are the Development Product Liaison responsibilities

The Development Product Liaison will be a key position and gathers product and customer information very early in the product’s value chain. Involvement by the Development Product Liaison begins during ‘ideation’, before a new roadmap item is created. At a high level, the Development Product Liaison does the following:

  • Work with the Product Manager (Product Owner) to define the vision of the project and create a Business Canvas (Tip: use Ash Maurya’s Lean Canvas board),
  • Do feasibility studies on potential new products and features,
  • Participate on customer contact calls/meetings/interviews (Tip: see Justin Wilcox’s Customer Interviews),
  • Help develop high level user stories for new products and features,
  • Help the full product development team break down work, targeting high value work first (Tip: see Mike Griffith’s article, Value Driven Delivery)
  • Share the vision with the Agile development team; providing a critical link between the visionaries and owners of the product and the technical teams that will turn these visions into a reality,
  • Develop a product definition with the Agile development team (Tip: use Roman Pichler’s Product Canvas tool),
  • Help each Agile team member to empathize the needs of the user; carry into the team the customer perspective.

Who fits the role

Ideally, this is a person who is a member of the development team working on the product. This could be the team’s lead developer or architect. This person usually has the greatest product knowledge on the development team, both usability and technical. The Development Product Liaison is also a person who will put customers ahead of solutions. This is not trivial and is very hard for developers. It is difficult to put the pride one has for an eloquent solution second to customer satisfaction.

This shouldn’t be one person indefinitely but rotated among all the development team members.


What can you expect to happen by implementing the Development Product Liaison role? Here’s what I’ve seen over the years:

  • Better assure the most valuable work is done first. By being the strong link between the business side and technical side of the product or service, the full product team is better at assessing value and priorities.
  • The team and business are better able to estimate when the new product or feature will be delivered to customers. By sharing with the full product development team the business and technical impacts of new products and features, the full product team is better giving accurate estimates.
  • Development team has fewer surprises during sprints. By being involved with the new product or new feature starting at inception, the Development Product Liaison is the technical expert. The development team can reduce or eliminate most uncertainty and risk by the time a story becomes Sprint Ready.
  • Give the Product Owner room to focus more time on Product Management tasks during implementation. By being the technical expert and knowing the details of the business side of each story, the Development Product Liaison can help answer some, but not all, questions about user stories, testing, and acceptance that usually only the Product Owner could answer. The Product Owner and Development Product Liaison can share this responsibility.


No one has ever said having a Development Product Liaison is a bad idea but the Product Owner and developers need to do more than just agree. The liaison between Development and Product Owner must be a strong influencer and seen by everyone as an efficient way to organize the product team. I’ve seen where choosing to do development work over liaison work caused issues. I’ve seen where the Product Owner didn’t like having a liaison close by. But I’ve also seen where the liaison took on the work with great gusto and the Product Owner welcomed the close collaboration. Only the third option will breed success.

It is very important that someone can mentor a liaison in the beginning. A full-time coach would be able to do this. The iteration manager or scrum master can also provide the proper training and guidance. However, the ideal situation would be that former Development Product Liaisons do mentoring. This would be in keeping with a self-organizing Agile team.


The Product Manager benefits massively from having a Development Product Liaison. The trust between Product Manager and Development Product Liaison means that most nuances of customer/user product implementation can be dealt with from within the development team.

For the developer, being a Development Product Liaison can be a great career stepping stone. In one company I’ve been at, most of the Product Managers were former developers. The liaison role will provide valuable insight and learning for a developer move to the product/business side of product development. One of the advantages of working closely with the Product Manager will be learning finances and how a product company works. Forbes article, The Path to Becoming a Fortune 500 CEO lists a strong financial background in 30% of CEO’s. Something to shoot for.

Improving communications between development and Product can only help serve the customers and the business. Once development teams understand the customer and the business, they can contribute greater value faster. The development team acts as a sounding board for the Product Manager. The ability to collaborate and possibly compromise will be enhanced with a Development Product Liaison.

As long as someone on the development team and the Product Manager can agree to work together, the Development Product Liaison experiment should be successful. Egos, lack of trust, traditional role definitions will quickly disappear in the matter of weeks as these two form a union. An eagerness to learn and help on the developer’s part, plus a willingness for the Product Manager to hear other points of views will ensure success. After all, talking is better than not talking.


6 Steps For Improvement

I wrote last week about Asking the Right Questions to improve through open-ended questions. This week’s post focuses on the steps needed to develop action plans, the environment necessary for analyst and developing actions based on your results, and how openness and trust breed success. We’ll also talk a little about how anonymous surveys can hurt more than help your improvement efforts.

Surveys are a good way to get general thoughts about one topic or another from groups. The key to a valuable survey lies with both the questions and how survey results are analysed & used afterward.

An Agile Retrospective is usually set up as a survey with two questions, “What went well?” and “What can we improve?”. The true value of an Agile Retrospective comes from the immediate analysis, planning, and actions resulting from a group effort.

6 Steps For Surveys and Retrospectives Actions

The Gallup organization provides this advice to companies doing employee surveys: do action planning. Gallup’s six steps for action planning after an engagement survey are:

  1. Introduce the action-planning session and state its purpose. This will help employees understand what engagement is, why the survey was conducted and what it measures, what the survey items mean to them and to their workgroup, and why action planning is a vital step in improving employee engagement.
  2. Distribute and explain the survey results.
  3. Discuss what those results mean for the workgroup, item by item.
  4. Select two or three key items to work on over the next 12 months.
  5. Brainstorm follow-up actions and complete a plan for improvement.
  6. Follow up regularly on the plan, and on how people are feeling about the team’s progress toward meeting its goals.

In an Agile Retrospective setting, those 6 steps are:

  1. Facilitator explains the workings of the Retrospective, its components, the hoped for outcomes, and establishes a safe environment. Agile Retrospective often run following Norm Kerth’s Prime Directive, “Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
  2. Conduct the survey-there are many styles and formats for retrospectives but they mostly require the participants to answer questions. See Retrospective Plans for a list of planning ideas. However, the ‘what went well/what can be improved’ format is eloquent in its simplicity and directness.
  3. Team members discuss the results-individual team members explain their choices, comments, and recommendation to the group. The group discusses these comments to better understand motivation and context.
  4. Select one or two key items to work on over the next sprint-the group collaboratively makes this selection, usually based on value.
  5. The team creates follow-up actions and completes a plan for improvement-the group collaboratively defines the problem, what the desired outcome should be, how to achieve the desired outcome, what measures are necessary to track, and how to validate the outcome has been achieved.
  6. Create a user story for the next sprint, including acceptance criteria so the team can measure progress toward meeting its goals and know when they’re done.

Between Gallup’s 6 steps and the Agile Retrospective step, most are reasonably similar and the outcomes are the same:

  1. create an atmosphere of safety and openness,
  2. ask open-ended questions on improvement,
  3. identify the key improvements,
  4. create an improvement plan,
  5. develop actions to complete the plan, and
  6. create measures to know the plan is working.

An example of an Agile Retrospective

When facilitating Retrospectives for Agile Teams I’ve asked the team to write on sticky notes the things they thought went well and put these under the ‘What Went Well’ column. Then I do the same thing for things that need improvement and place these under the column ‘What We Can Improve’. Now if you’ve ever been in a Retrospective, you’re probably familiar with this. What just happened is the survey. What follows, is a frank, open discussion within the team to make sense of the survey results. The survey by itself provided information but without the group discussion there’s no depth of understanding what the comments on the sticky notes truly mean.

For example, when an Agile Team first forms there’s an abundance of ‘What Went Well’ comments like, “We worked well together as a team”. This is a great comment and is very encouraging but doesn’t mean too much by itself. The lingering questions in my mind are, “how did you work in the past that wasn’t so great?”, “what allowed you to work well together now?”, “what does the team need to do to ensure you work well together tomorrow and beyond?”. The environment is set to discuss these and other questions to fully understand the meaning. Some advantages of the team retrospective are:

  1. everyone knows who made the comment and how they’ve worked with that person. Team members often know ‘where they’re coming from’;
  2. everyone’s opinion on the comment is welcomed;
  3. specific examples are explored by everyone; and
  4. a list of actions to continue a positive result or to make changes to improve a result are made by everyone, for everyone.

What’s needed for success? Trust.

The best results can happen when the group or team fully trusts one another. Agile Retrospective are conducted in an environment of trust which brings with it the openness necessary to truly improve.

FireRescue magazine’s article, The Absence of Trust in Dysfunctional Teams,  the importance of trust can be seen as a matter of life and death. Where most of us work, trust is rarely a matter of life and death. However, when looking to improve, we need to be open, honest, and feel safe. This can only happen in an environment of trust. The Agile Retrospective is seen as an event that cultivates openness and trust. When doing any type of improvement activity, from Retrospectives to employee engagement surveys, the way to get the best results is trust. Trust that:

  • observations and opinions matter
  • something good will result
  • as a team or group, we can improve
  • there are specific actions developed to improve

What did ‘Anonymous’ mean when they said …

The last few companies I was at gathered anonymous feedback using surveys. This was a key point to get you to participate. Interestingly, it also shows that distrust has been institutionalized. Claire Lew, CEO of Know Your Company, wrote in, Anonymous feedback breeds a culture of distrust, how anonymous surveys can introduce higher levels of distrust and suspicion. She also points to the difficulty in acting upon anonymous feedback.  A survey marketed as ‘anonymous’ can serve as warning that open discussions with actions may not occur. If the company provides the results from an ‘anonymous’ survey, it is very hard, if not impossible, to understand what a person was thinking when they made a comment.

One company where I was at did Engagement surveys with all staff but held a follow-up meeting with each team individually. The best the group could do was speculate on the results and comments. There was a discussion as how our group felt about the questions but these often had little bearing on the survey results. The team couldn’t ask the people who commented what they meant.

In contrast, in the Agile Retrospective, understanding and feedback are immediate due in part because you see and hear the person commenting.

In 10 Core Business Values That Really Matter And Why, from the Stanford School of Business, some of the top values are openness, honestly, respect, or trust. Having an anonymous survey would seem to contradict all these values.

When might anonymous questions or surveys work?

An anonymous survey might be the best place to start if you have a company culture of blame. In these environments, open, frank talk can be difficult. I was told at one place that being critical of company decisions or just making a mistake could get you fired. They told me people were dismissed in the past. Several years later, people still believed this to be true although no one had been dismissed for being critical or for making a mistake. But because the culture of blame lived on, it was necessary to promise anonymity.

It might also benefit you to promise anonymity if you’re conducting a survey individually with team members for your own use. I do this often to get a more personal response. I still circulated the results but without attribution.


Surveys done alone or as part of an Agile Retrospective can surface issues both positive and negative. Starting with good open-ended questions, people are compelled to think and see their world more objectively. Having the full team exploring individual comments with the person who made them is critical to success.

Anonymity can severely hamper getting to the truth. It can result in a growing culture of distrust and limit the ability to create a coherent action plan. The answers and ideas on improving require an open and frank discussion. This usually requires the people making comments to describe what motivated them. This is a critical link toward group understanding.

An atmosphere of trust and openness is necessary to achieve the greatest success. People should not fear speaking their mind. The team or group needs to be welcoming of all opinions and points of view.

Surveys and Retrospectives both must result in actions for success to flourish.