Skip to main content
Project Management

Return to Answer

replaced http://pm.stackexchange.com/ with https://pm.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

Summary

This previous PMSE answerPMSE answer clearly summarizes why there is an inherent conflict in having a Development Team Member perform double-duty as Scrum Master:

The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles.

— CodeGnome, PMSE AnswerPMSE Answer

Scrum Master and Development Team Member are Separate Roles

The Scrum Master is defined as a separate role within the framework by The Scrum Guide:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

— The Scrum Guide, Schwaber & Sutherland, p. 5

While a separate role doesn't always require a separate person, effective Scrum practice requires that this triumvirate should have a clear separation of duties in order for the framework to operate as designed.

The Scrum Master is also has a full page of unique responsibilities within the framework. See The Scrum Guide (Schwaber & Sutherland, pp. 5-6) for the complete list, as it's too long to simply and copy and paste here.

In short, while the framework doesn't forbid a team member from also wearing the Scrum Master hat, it is extremely unlikely that a full-time developer will have the bandwidth to be an effective Scrum Master (or vice-versa). Part of a Scrum Master's job is to manage Scrum artifacts and provide an interface to the broader organization; such tasks limit the capacity of a single person to provide service delivery as members of the Development Team, and will create a more or less permanent drag on the team's potential velocity. In my considered opinion, this unnecessary drag is itself a conflict of interest.

Responsibility vs. Authority

Any organization that doesn't value the Scrum Master role sufficiently to create a proper separation of duties is unlikely to understand the inherent conflict of interest between service delivery and process refereeing. This means that the Scrum Master's job of removing process impediments and enabling organizational change may be limited by politics and org charts.

Any time a position has responsibility without sufficient organizational power or delegated authority to carry out those responsibilities creates a situation ripe for failure. Even if one disregards the inherent conflict of interest in the roles, the consequences to the project in disregarding the separation of duties may be dire.

Perhaps your organization will understand that you will have less time to develop when wearing the Scrum Master hat in addition to your other responsibilities. Perhaps they are also enlightened enough to see you as more than just another member of a service delivery team, and will actively engage with you on essential business process re-engineering issues. Perhaps and perhaps...but I have never personally seen this work out well for a project, or the dual-hat wearing person stuck in the middle.

Your mileage may vary. However, I wouldn't bet my career on it.

Summary

This previous PMSE answer clearly summarizes why there is an inherent conflict in having a Development Team Member perform double-duty as Scrum Master:

The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles.

— CodeGnome, PMSE Answer

Scrum Master and Development Team Member are Separate Roles

The Scrum Master is defined as a separate role within the framework by The Scrum Guide:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

— The Scrum Guide, Schwaber & Sutherland, p. 5

While a separate role doesn't always require a separate person, effective Scrum practice requires that this triumvirate should have a clear separation of duties in order for the framework to operate as designed.

The Scrum Master is also has a full page of unique responsibilities within the framework. See The Scrum Guide (Schwaber & Sutherland, pp. 5-6) for the complete list, as it's too long to simply and copy and paste here.

In short, while the framework doesn't forbid a team member from also wearing the Scrum Master hat, it is extremely unlikely that a full-time developer will have the bandwidth to be an effective Scrum Master (or vice-versa). Part of a Scrum Master's job is to manage Scrum artifacts and provide an interface to the broader organization; such tasks limit the capacity of a single person to provide service delivery as members of the Development Team, and will create a more or less permanent drag on the team's potential velocity. In my considered opinion, this unnecessary drag is itself a conflict of interest.

Responsibility vs. Authority

Any organization that doesn't value the Scrum Master role sufficiently to create a proper separation of duties is unlikely to understand the inherent conflict of interest between service delivery and process refereeing. This means that the Scrum Master's job of removing process impediments and enabling organizational change may be limited by politics and org charts.

Any time a position has responsibility without sufficient organizational power or delegated authority to carry out those responsibilities creates a situation ripe for failure. Even if one disregards the inherent conflict of interest in the roles, the consequences to the project in disregarding the separation of duties may be dire.

Perhaps your organization will understand that you will have less time to develop when wearing the Scrum Master hat in addition to your other responsibilities. Perhaps they are also enlightened enough to see you as more than just another member of a service delivery team, and will actively engage with you on essential business process re-engineering issues. Perhaps and perhaps...but I have never personally seen this work out well for a project, or the dual-hat wearing person stuck in the middle.

Your mileage may vary. However, I wouldn't bet my career on it.

Summary

This previous PMSE answer clearly summarizes why there is an inherent conflict in having a Development Team Member perform double-duty as Scrum Master:

The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles.

— CodeGnome, PMSE Answer

Scrum Master and Development Team Member are Separate Roles

The Scrum Master is defined as a separate role within the framework by The Scrum Guide:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

— The Scrum Guide, Schwaber & Sutherland, p. 5

While a separate role doesn't always require a separate person, effective Scrum practice requires that this triumvirate should have a clear separation of duties in order for the framework to operate as designed.

The Scrum Master is also has a full page of unique responsibilities within the framework. See The Scrum Guide (Schwaber & Sutherland, pp. 5-6) for the complete list, as it's too long to simply and copy and paste here.

In short, while the framework doesn't forbid a team member from also wearing the Scrum Master hat, it is extremely unlikely that a full-time developer will have the bandwidth to be an effective Scrum Master (or vice-versa). Part of a Scrum Master's job is to manage Scrum artifacts and provide an interface to the broader organization; such tasks limit the capacity of a single person to provide service delivery as members of the Development Team, and will create a more or less permanent drag on the team's potential velocity. In my considered opinion, this unnecessary drag is itself a conflict of interest.

Responsibility vs. Authority

Any organization that doesn't value the Scrum Master role sufficiently to create a proper separation of duties is unlikely to understand the inherent conflict of interest between service delivery and process refereeing. This means that the Scrum Master's job of removing process impediments and enabling organizational change may be limited by politics and org charts.

Any time a position has responsibility without sufficient organizational power or delegated authority to carry out those responsibilities creates a situation ripe for failure. Even if one disregards the inherent conflict of interest in the roles, the consequences to the project in disregarding the separation of duties may be dire.

Perhaps your organization will understand that you will have less time to develop when wearing the Scrum Master hat in addition to your other responsibilities. Perhaps they are also enlightened enough to see you as more than just another member of a service delivery team, and will actively engage with you on essential business process re-engineering issues. Perhaps and perhaps...but I have never personally seen this work out well for a project, or the dual-hat wearing person stuck in the middle.

Your mileage may vary. However, I wouldn't bet my career on it.

Source Link
Todd A. Jacobs ♦
Todd A. Jacobs ♦
  • 50.7k
  • 7
  • 60
  • 181

Summary

This previous PMSE answer clearly summarizes why there is an inherent conflict in having a Development Team Member perform double-duty as Scrum Master:

The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles.

— CodeGnome, PMSE Answer

Scrum Master and Development Team Member are Separate Roles

The Scrum Master is defined as a separate role within the framework by The Scrum Guide:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

— The Scrum Guide, Schwaber & Sutherland, p. 5

While a separate role doesn't always require a separate person, effective Scrum practice requires that this triumvirate should have a clear separation of duties in order for the framework to operate as designed.

The Scrum Master is also has a full page of unique responsibilities within the framework. See The Scrum Guide (Schwaber & Sutherland, pp. 5-6) for the complete list, as it's too long to simply and copy and paste here.

In short, while the framework doesn't forbid a team member from also wearing the Scrum Master hat, it is extremely unlikely that a full-time developer will have the bandwidth to be an effective Scrum Master (or vice-versa). Part of a Scrum Master's job is to manage Scrum artifacts and provide an interface to the broader organization; such tasks limit the capacity of a single person to provide service delivery as members of the Development Team, and will create a more or less permanent drag on the team's potential velocity. In my considered opinion, this unnecessary drag is itself a conflict of interest.

Responsibility vs. Authority

Any organization that doesn't value the Scrum Master role sufficiently to create a proper separation of duties is unlikely to understand the inherent conflict of interest between service delivery and process refereeing. This means that the Scrum Master's job of removing process impediments and enabling organizational change may be limited by politics and org charts.

Any time a position has responsibility without sufficient organizational power or delegated authority to carry out those responsibilities creates a situation ripe for failure. Even if one disregards the inherent conflict of interest in the roles, the consequences to the project in disregarding the separation of duties may be dire.

Perhaps your organization will understand that you will have less time to develop when wearing the Scrum Master hat in addition to your other responsibilities. Perhaps they are also enlightened enough to see you as more than just another member of a service delivery team, and will actively engage with you on essential business process re-engineering issues. Perhaps and perhaps...but I have never personally seen this work out well for a project, or the dual-hat wearing person stuck in the middle.

Your mileage may vary. However, I wouldn't bet my career on it.