AgileCareers Blog
Blog Home All Blogs
Get the latest news on AgileCareers! is dedicated to connecting Scrum and Agile organizations with qualified, passionate Agile professionals. We strive to Transform the World of Work by offering a platform that has the resources and technology to help build those professional synergies.


Search all posts for:   


Top tags: agile  hiring  scrumpractices  agilepractices  interviews  job posting  scrummaster  leadership  scrum  talent  talent acquisition  bonus  compensation & benefits  culture  digital age  employee engagement  eyholzer  future of work  HR  human resources  learning  people operations  practices  principles  product owner  Recruiting  reward  Technology  transformation  values 

Can the Scrum Master also be the Product Owner?

Posted By Meghan Robinson, Thursday, June 30, 2016
Updated: Tuesday, June 28, 2016


If you’ve experimented with scrum, you’re likely familiar with the Scrum Master and Product Owner roles. But just in case you’re not, here’s a quick breakdown: The Scrum Master is responsible for ensuring that the team follows the Scrum process, while the Product Owner ensures that the team spends time building things that bring the most value to the organization. These roles sound so deceivingly simple that sometimes a single person will try tackling both.

This can happen in a ground-up implementation of scrum when a Product Owner is never officially assigned to the team, leaving the Scrum Master to fill these responsibilities. It can also happen when the team’s Scrum Master is also an individual contributor, and simply too overwhelmed to focus on the scrum process. In these cases the Product Owner may try to step up to lead the process, in addition to their own responsibilities.Regardless of the reason, when a team attempts to combine all responsibilities into a single role, it almost never ends well. Let’s look at some of the ways this can go awry, and how to fix it.

Scenario 1: Scrum Master acts as Product Owner

Most commonly, when these roles are combined, it results in the Scrum Master also wearing the hat of Product Owner. While it sounds logical, the Scrum Master may not have access to the customers to gather valuable feedback. Without actionable feedback, the team simply breaks an un-validated product down into smaller and smaller pieces delivering each incrementally. While incremental delivery is an improvement over a single large delivery, the reality is that it’s really just a more efficient way to deliver the wrong product.

When the Scrum Master acts as Product Owner, it’s easy to miss out on a coherent vision for the team, resulting in the delivery of low-value work. This can happen when the Scrum Master, lacking customer access or a true vision for the product, simply stacks the backlog with the items they find most interesting or familiar. This results in the team dusting the app by making minor enhancements to existing features or cleaning up low-priority bugs, but not accomplishing any meaningful work. In this case, low-value shouldn’t be confused with low-quality: While the team may be producing high-quality work, it doesn’t mean it’s making a meaningful impact on the product.

Scenario 2: Product Owner acts as Scrum Master

Product Ownership is a full-time job. This means that it’s easy for responsibilities outside of this role to slip. When the Product Owner acts as a Scrum Master we usually see the less tangible pieces of the scrum process slowly start to wane. Retrospectives are often the first casualty, as their outcomes can (incorrectly) seem less relevant to a busy Product Owner. While the Product Owner may not officially cancel a Retrospective, they may view it as most relevant to the development team and, therefore, leave the scheduling to them. These meetings appear unimportant to the organization and eventually die out.

Alternatively, the symptom may not be as blatant as a missed meeting. In some cases, regular meetings will still occur but you’ll start to notice that their focus subtly changes. For instance, daily standups still occur but rather than acting as a chance for the team to plan their work for the day, they slowly morph into a status meeting in which each team member reports their progress to the Product Owner. Likewise, sprint-planning meetings will still occur, but rather than the team arriving at estimates and a sprint plan together, they may find themselves bullied into uncomfortable commitments as the result of  an overzealous Product Owner.

How to fix it

Both Scrum Master and Product Owner, for the most part, are full-time jobs. When the same person attempts to fill both roles disaster almost always ensues. In the cases where the Scrum Master is filling the Product Owner’s responsibilities, the simplest solution can be to free the individual of their Scrum Master responsibilities, allowing them to focus on the Product Owner role entirely. Many Scrum Masters eventually gravitate toward the Product Owner role and, as of late, this has become a very popular career progression for those with a taste for Product Management.

Keep in mind, however, that your team still needs a Scrum Master. This is your opportunity to identify a team member who’s up for the challenge, and coach them into their new role. If successful, you’ll have a new, dedicated Scrum Master, brought up from within the team, and a new dedicated Product Owner with a background in the scrum process. That’s a pretty big win.

In situations where the Product Owner acts as Scrum Master, the solution is to find a new Scrum Master who can dedicate time to the role. Not only does this free the Product Owner from managing the Scrum process, but it also helps create healthy tension between Scrum Masters and Product Owners. Ideally, the Scrum Master and Product Owner act as opposing forces. While the Product Owner represents the interest of the customers, the Scrum Master represents the interests of the team. When a single person tries to fill both roles, this healthy tension is lost and the fulcrum inevitably tips too far in one direction.

This is often seen when the Product Owner attempts both roles, as the fulcrum may tip toward bigger feature sets and a rush to market, which not only sacrifices the team’s investment in quality, but can also take a toll on their overall well-being. Freeing the Product Owner to focus entirely on product ownership, while allowing a completely different individual to focus on the scrum process, helps restore balance and better serves the end result.


There are exceptions to every rule, and it is possible for one person to serve both roles successfully. Just keep in mind that this isn’t the norm, nor should it be a long-term solution. To give your organization the best chance for success when using scrum, allow two distinct individuals to serve these roles. Even if you’re struggling to find those with the right aptitude, you’ll be better off with two people who have a passion to grow into their respective roles, rather than one exceptional individual struggling to balance both.

Want to learn more about how agile really works? Check out Jeremy’s course, Agile in the Real World, for concrete strategies on making the best agile techniques work for your team.

This article was originally posted on PLURALSIGHT.

Tags:  Agile  product owner  scrummaster  scrumpractices 

Share |
PermalinkComments (0)

What Do You Look for in a Servant Leader or a Scrum Master?

Posted By Meghan Robinson, Wednesday, June 8, 2016


In my article, Which “Scrum Master” Are You Hiring?, I suggested you articulate the type of leader you might be hiring. Why? You might not be hiring a “Scrum Master” at all—but you are likely hiring a servant leader.

In this article, let’s discuss the kind of qualities, preferences, and non-technical skills you might need in a servant leader, your potential Scrum Master, agile project manager, potential account manager, or whatever role you need filled.

Start With Qualities, Preferences, and Non-Technical Skills

Your servant leader has talents that are different from the technical skills. You could lump them all into one bucket called “talents.” But I have found that not so useful. Instead, I like to differentiate those into qualities, the talents that a person exhibits that are culture-sensitive; preferences, innate behaviors that are part of a person’s personality; and non-technical skills, such as interpersonal skills that a person has acquired over the years.

No matter what position this person has, let’s start with non-technical qualities, preferences, and non-technical skills. Those are the characteristics that will help a candidate succeed in the position and fit into your organization’s culture.

Notice that I am not suggesting you start with a certification. Why not? While this person needs to embody agile values, principles, and of course, practices, a certification is no guarantee of that. However, the non-technical characteristics, the qualities, preferences and non-technical skills that you require in this servant leader role will help you define what you do need. We will discuss certification later.

What do you need in your position? Again, it depends on the servant leader you are hiring. Let’s take a few of the examples.

Is Your “Scrum Master” Working as an Agile Project Manager?

For the sake of argument, let’s say you have an agile project manager, someone who helps the team define the charter, set the release criteria for the project, facilitates the team’s work, and also is the interface with the operations committee or the PMO or some other decision-making or governance body. This person’s job is to represent the team at the project portfolio decision meetings, and to advocate for the team. This person is the outward face of the team.

In the previous article, Ruth decided to hire a very senior person who could perform both these servant leader activities and the project portfolio activities. You might disagree with Ruth’s decision, but that’s the decision she made (I certainly did!). What qualities, preferences, and non-technical skills would she look for in a candidate?

Servant Leaders Must Enjoy Working with People

One of the major qualities of a servant leader is that he or she enjoys working with people. Servant leaders serve the people on the project. They also serve the people in the organization. They might have to keep the goals of the project in mind, as they facilitate the people, but remember, they are not “driving the project to completion.” That is not the job of a servant leader, no matter what this job is called.

This role facilitates the people doing the work. Here, Ruth decided to hire a senior person, because this person needs to interact at the project portfolio level to advocate for the team. Ruth suspects that the team will be able to facilitate itself pretty soon. I was nervous about Ruth’s assumption, because in my experience it takes a while for a new team to fully transition to agile. She wanted someone who was also a great negotiator, and could communicate well, both in email and in person.

She needed someone who was, as she said, a good “diagnoser.” Someone who could look at the project measurements, hold up a mirror to the team, and ask, “What’s going on?” Ruth was sure that was some sort of an agile skill, so she knew she needed someone experienced in agile. She also knew she needed someone who could learn enough about their system quickly.

If we summarize Ruth’s criteria for her servant leader, here’s what her first iteration looks like:

Essential skills for Ruth’s Agile Project Manager
  • High collaboration skills with the project team and project portfolio team
  • High facilitation skills with the project team
  • High negotiation skills with the project portfolio team
  • High communication skills across the organization
  • Diagnostic skills for what’s going on in the team
  • Able to learn our system quickly

Ruth might have other desirable qualities, preferences, or skills, such as budgeting, or ability to travel. The fact that she wants someone who can work at the project portfolio level is part of her culture.

That’s just one kind of servant leader. There are others.

What Happens When Your “Scrum Master” is a Manager?

Harry was the senior manager who was trying to make Scrum stick. He noticed that the teams were not sticking to Scrum—they were doing water-scrum-fall—because the people are not being loyal to their project teams. The people were loyal to their functional silos.

When you have a strong matrix organization and a weak project organization, as Harry had, it’s quite easy for people to do the work for their functional teams. Their managers ask them, “Can you do this little task for me?” Who wants to say “No,” to a manager?

Those little tasks take time away from project work and make it more difficult to accomplish the project work.

What can you do? Ask the managers to help the projects, not help other work.

I had suggested they change the organization to remove the many managers and create project-based teams instead. You should have seen the look of horror on his face! Not going to happen. Instead, he suggested that the managers become Scrum Masters for other project teams—not their own projects. Well, okay, that might work.

When Harry wrote the job description for these Scrum Masters, it was clear he was focusing on impediment removal:

  • High collaboration skills with the other managers
  • High facilitation skills with the project team
  • High negotiation skills with the other managers
  • High diagnostic skills for what’s going on in the team

Harry wanted the organization to complete its transition to agile and he was willing to make the managers Scrum Masters for cross-functional teams. He wanted the managers to work across the organization to accomplish this.

When Your Servant Leader’s Primary Role is Coaching

I normally separate facilitating the team from the coaching. But Valerie decided that she needed just one person in this position. And, the coaching would have to be subtle.

To me, this is a tall order. Subtle coaching as part of facilitation? This might require a very special person. I asked Valerie what the activities and deliverables were. “Retrospectives with action items are the first piece. If we don’t have retros with action items, we are still doing something wrong. So we need someone who can facilitate our retrospectives.” I asked about metrics, because I had not seen any velocity or burn-up charts or any other useful charts.

“Yes, we need data, too. But we can’t have someone beating the team over the head with data. Otherwise this will turn into command and control again”. I agreed with her.

Valerie needs someone with very strong facilitative skills. They need the ability to run retrospectives and be able to suggest alternative approaches to the team at any time. Someone who understands what data is valuable in agile and what data is not valuable.

Valerie’s initial draft for her essential qualities, preferences, and skills were these:

  • Strong facilitation: in retrospectives, team meetings, and one-on-one
  • Strong coaching skills: one-on-one and in teams
  • High collaboration skills in the team
  • Able to suggest data gathering approaches to the team

As an initial draft to use in a job analysis, these are great. Valerie will be able to use these to create her interview questions and auditions.

Leading Geographically Distributed Teams is More Difficult

Once you add in the stress of managing a geographically distributed team, you need not only a change agent, as in Anne’s case, but someone who can understand the cultures of the people in different places.

If you are lucky, and you have a geographically distributed team with people in just one country, you might not have too many cultural issues. My experience is that when you have distributed projects, you have projects with people who are many time zones away, and who represent multiple cultures. You have problems with language, how to share the stories, and coming to a common understanding of what done means.

Your servant leader needs to help facilitate the team meetings. First find a meeting time that everyone can make. Then make sure everyone understands what’s going on.

Does your servant leader need to access the people on the project through managers in different countries? Sometimes that happens. Does the leader need to make it easy for people to explain, “I don’t understand the wording of the story. I need more information.” That happens too.

It’s quite common that a story that appears easy to one person in one time zone is non-trivial to a person in another time zone. A servant leader may have to act as a coach, to help people articulate why they are not done with a story, and diagnose remaining work to see if the rest of the team can assist with work for that story. This can be quite difficult, the more time zones separating the people. It can also appear to the distributed people that the leader is criticizing the distributed folks. This takes talent and subtlety. Maybe the team doesn’t have a common definition of done.

Arriving at a common definition of done is not trivial when people are partway around the world. It is easy for people to misunderstand words and not just miss a deadline, but create the wrong thing entirely.

Servant leaders for geographically distributed teams need to learn to build trust, to help people learn to collaborate, to help people learn to speak in a way that creates teamwork, and to avoid the management insertion that too often occurs. There are many potential pitfalls in geographically distributed agile teams.

Anne decided these were the essential qualities, preferences, and skills:

  • Able to facilitate phone calls all over the world
  • Able to manage these people’s managers—high negotiation skills, political capital
  • Able to recognize small wins and help the team deliver without being command and control
  • Influential in the team to deliver fast wins

Anne was so successful the project grew into a program. That turned into a headache for Anne.

Managing Programs Requires Other Skills

A geographically distributed project is one thing. A geographically distributed program is another beast. A program is several projects, all coordinated to meet one business objective.

Managing programs requires coordination and collaboration across the organization.

What Does a “Real” Scrum Master Require?

By now, you’re probably wondering, what the heck are the qualities, preferences, and non-technical skills for a real Scrum Master? Let’s assume we have a collocated five-to-seven person team and the Scrum Master only has this job, no other.

Tags:  agile  Leadership  scrummaster  Technology 

Share |
PermalinkComments (0)

Product Owners and Scrum Masters: Partners in Adversity

Posted By Meghan Robinson, Tuesday, May 24, 2016
Updated: Tuesday, May 10, 2016


Despite their differing priorities a Product Owner (PO) and Scrum Master (SM) must be on the same team. More specifically, in a successful scrum team the PO must be a partner to the SM. Their adversity comes from the roles they play. The sentiment applies equally well to Agile Project Managers and Agile Coaches. That said, framing it in the context of Scrum makes the narrative easier.

Tug Of War Between Two Girls Stock Photo

meepoohfoto –

The PO is beholden to the customer or end-user as well as the business. Their main function is to maximize value delivery. The SM is beholden to the team. Their main function is ensuring and enacting scrum through servant-leadership of the team. With no SM a PO might very well burn a team out by requiring too much of them. Without a PM a SM might hinder value delivery by shielding the team from more than they should or allowing more experimentation than the business can support. Hence a partnership must form between the PO and SM for a successful team to emerge. The adversity arises due to the difference in priorities between these two roles.

The PO and SM have to work together to find the right balance between pushing the team for higher performance and sustaining the team for long-term endurance. Together they need to know what level of change is tolerable by the organization, the user, and the team at any given point. Using this knowledge, they need to decide how much time the team can spend on self-improvement versus value delivery every iteration. In a solid partnership they might be able to discover ways to accomplish both improvement and value delivery at the same time.

Just as changing around a development team causes a reset of the teams developmentchanging the PO or SM does the same for their partnership. Having multiple PO’s on a single product exacerbates the problem, and is a bad practice to begin with. The PO is supposed to be the one and only person who can speak to what the most important deliverable is at any time. If there are multiple people trying to fill the role there will inevitably be a time where they disagree, potentially causing confusion when the SM is looking for clarification or guidance. Similarly, a dedicated SM can establish a relationship with the PO and continue through storming and norming to performing. Choosing to instead rotate the SM role among team members can result in that relationship never progressing beyond the storming phase.

When a PO and SM are on the same page it becomes easier for the team they are on to deliver the best value possible. If they are at odds then their conflict itself will become a value blocker for the team. Keep both roles dedicated, on the team, and in a partnership for the best outcome possible.

This article was originally posted on

Tags:  product owner  scrummaster 

Share |
PermalinkComments (0)

Six tips for hiring Agile people with Lena Bednarikova

Posted By Meghan Robinson, Friday, April 15, 2016

 "One of the most effortless ways to enable your cultural change is to “let the right one in” – to hire people who already possess the desired attributes of your intended culture and your future organisation. These people will do all the hard work for you, without even knowing it."

Lenka Bednarikova is passionate about creating great teams. Her experience spans across specialist IT agencies, regional companies, and multinational organisations such as Nokia and Microsoft where she helped transform their recruitment processes to create the right environment for Agile and customer focus. Lenka is well versed in hands-on recruitment, Agile and traditional project management. She is a board member of the Institute of Recruiters and currently also enjoying herself as a Scrum Master at BankWest.


Interested in what she has to say? Click HERE to read more!   

Tags:  agile  hiring  interviews  IT  scrummaster  scrumpractices  Technology  workplace 

Share |
PermalinkComments (0)

Who’s who in agile teams?

Posted By Meghan Robinson - Scrum, Friday, March 4, 2016
Updated: Thursday, March 3, 2016

Agile teams are structurally different than their waterfall counterparts. Agile teams focus on the team itself, whereas waterfall teams often follow the structure of the organization. In traditional waterfall development, scheduling is often “top down,” meaning management sets the pace and schedule. In agile, the team is self organizing, and sets its own schedule and destiny within the larger organization. As I was learning scrum, one of the questions that kept coming to mind was, “How do development managers and scrum masters share responsibilities in the team?” Let’s explore the answer to this question.

Waterfall teams vs. scrum teams

Most waterfall teams are manager centric. They look to the the manager to set priorities, track progress, and evaluate performance. Agile teams are self-organizing. They work with a product owner (not usually in the team’s management chain) who sets the vision for what should be built. The team, through a series of sprints, drives how the product should be built.

Self-organizing teams own their destiny. In sprint planning, they decide how much work to commit to the sprint, and because of that, their level of ownership in the success of the program remains high. Engineers who own their own schedules build products of higher quality more consistently because they own their schedules. Engineers want to build high quality products on time. Everyone in the organization has the same goal. As a company we all want to succeed. Tuckman’s stages of group development outlines how teams form and thrive. Agile, self-organizing teams are no exception.

Mutual trust and candor are essential to well-performing agile teams. Management that continually focuses on hiring the right team is able to trust the team to get the job done. The need to then micromanage every detail of the team’s work doesn’t exist. The scrum master and the development manager protect the team from outside distractions such as feature creep, waterfall anti-patterns, cross functional thrash, or side projects that will compromise the integrity of the sprint.

Role 1: scrum mastersAgile teams_scrum master

Scrum masters are the project leaders in agile teams who focus on optimizing performance of the scrum process. They work between the product owner and the team ensuring consistent, successful sprints by running stand-ups, and working to reduce blocking issues for the team. Cross-functional thrashing can be costly for teams, so successful scrum masters own cross-team coordination so the core team can focus on product development. This practice keeps everyone efficient and on the same page.

“Scrum masters are leaders in agile teams who focus on optimizing performance of the scrum process.”

The scrum master coordinates most of the inputs and outputs required for an agile program. He or she drives the sprint kickoffdaily stand-upssprint review, and sprint retrospective. The scrum master is also an agile coach, helping the team to adopt and own agile practices throughout the product life cycle: story point estimation, sprint planning, and continuous delivery. The coaching aspect of the scrum master’s job is critical as they not only help the team to be agile, but advocate for agile development throughout the organization, and spread the good word about why agile development is right for the project and for the company. Often times, when agile methodologies are new at a company, the advisers and stakeholders outside of the team need agile coaching as well.

The scrum master works with the team and the development manager to estimate items in the backlog. At first, the team will need some guidance from the scrum master and development manager. As the team is forming, it builds shared knowledge of the program through successful sprint planning. As the team moves into a performing stage, the scrum master focuses less on estimation and more on optimizing the velocity of delivery.

Role 2: development managersAgile teams_Dev manager

There’s a lot of uncertainty for engineering managers when their team adopts agile – an Admiral Stockdale moment, if you will. But despite the fact that agile development teams don’t rely on their manager for estimation and prioritization, managers still play a vital role.

Hiring well

The most important thing a development manager does is hire. Why spend so much time on hiring the right candidate? Team changes are expensive on two levels:

  • Searching for candidates takes focus away from building great product.
  • When new employees join, the existing team needs to spend time onboarding them. Teams will experience a drop in velocity over a few sprints as each new person integrates into the team.

“The most important thing a development manager does is hire.”

When a team is truly self organizing and performing well, everyone in the organization sees it through the product quality and delivery. No one has more impact here than the development manager.

One of the big differences between agile and waterfall teams is that the development manager is a partner in the estimation process. In a waterfall team, a conversation like this wouldn’t be unheard of:

  • “Hey, how long is it going to take to deliver this feature?” – manager
  • “It’s going to take six weeks. We need to do A, B, C to get the feature to market.” – engineer
  • “Hmm. That makes sense, however, you need to find a way to get it done in four weeks.” – manager

But an agile development manager knows to hire great people, then trust them. A fundamental tenet of the agile process is that those closest to the work are best able to scope and deliver. The team sets the schedule. The development manager adds unique value in inquiring and vetting assumptions made in the estimation exercise – partnering in the process, rather than dictating it.

“A tenet of the agile process: those closest to the work are best able to scope and deliver.”

Developing well

While scrum masters focus on team velocity, development managers build up team members’ velocity by coaching individuals one on one. Development managers curate and inspire great talent in their organizations. Great managers are adept at the fundamentals of management: one on ones, giving feedback, and coaching their teams. Successful development managers mentor engineers to bring greatness to the table: ideas, code, tests, and culture. Great development managers partner with their teams. At times, the team will struggle or come to an impasse with architecture design decisions. Adept development managers know when to intervene to break the impasse or let the team continue to struggle to grow the team. The scrum master may not be as technical as the rest of the team so the development manager lends valuable context between the scrum master and the team when there is a clear knowledge gap.

In addition, they also partner with the senior developers in the company to set the development culture. They’re often influential in the technology choice for the program, and continue to own responsibility for the quality of the product from the code architecture to the end-user experience. Development managers engage in code reviews to ensure team members are contributing code that meets the short and long term goals of the program. They also set context internally for the team and in the larger organization.

To learn more

We’ve spent a fair amount of time looking at what makes a great manager in an agile culture and now we’d love to know: how does your team practice the agile methodology? Drop us a line in the comments!


  • This article was written by Dan Radigan, Technical Account Manager JIRA 
  • Read more of his content HERE 


Tags:  agile  agilepractices  hiring  scrummaster  scrumpractices 

Share |
PermalinkComments (0)

Have Questions?
Contact us

Join The Conversation