I have joined a new team as a developer but they also want me to be Scrum Master as I have the most Agile development experience. Do you think that is a conflict of interest?
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.
I would suggest you read the responsibilities of the Scrum Master on ScrumGuides http://www.scrumguides.org/scrum-guide.html#team-sm (Whenever in doubt refer to this guide)
As you can see there is no mention of a developer can not be a Scrum Master. However, with all the services the SM providing to PO, Organization and Dev Team and responsibilities, it is very hard to do both.
If you find a Developer that can do both, awesome! Through my whole career, I think I only know one person that can do both and is doing both.
CodeGnome gave a very good answer, but I have a little to add.
I don't think it's impossible to take on both roles at once. I actually do that myself, and having previously worked exclusively as a developer, I am seeing that I can bring about improvements both within the team, and the wider organisation.
However it does limit the impact of the Scrum Master, and there are certainly some conflicts of interest. Development Team member and Scrum Master are separate roles. They may have the same ambition of delivering value to the business, but the ways in which they do this do not always overlap. For instance, a Development Team member might focus on the Sprint Backlog as the best way for them to deliver value; a Scrum Master may focus on systemic matters, and could, for instance, take a longer-term view. This is most sensitive when the team are under pressure. A Scrum Master may be required to focus on protecting the team and their system of working. A Development Team member may be expected to focus on work in the Sprint Backlog. Depending on how the Scrum Master has been empowered, this may result in them not being able to do their job.
The Scrum Master is described as a servant leader, and as such, it is a legitimate tactic of a Scrum Master to avoid interfering too early, when they notice a potential problem in the way the Development Team are working. The rationale is that it is better to let the self-organizing Development Team see the impact of this way of working, and then take responsibility for implementing their own solution. The conflict here is that as soon as the Scrum Master has seen an issue, one member of the Development Team has too; but it doesn't necessarily mean the other members of the Development Team recognize the issue, or will be convinced of the need to make a change. Given that the Development Team's focus isn't on understanding Scrum systems as a whole, it is likely that in many cases, the Scrum Master will detect an issue before the other Development Team members. The risk of raising the matter too soon, is it may deny the remaining members of the Development Team the opportunity to understand the problem, and fully self-organize; but waiting too long might undermine an expectation of all Development Team members to raise issues when they see them.
These conflicts do not prevent one person fulfilling both roles, but in the spirit of openness (one of the Scrum values), it would usually be wise to identify and discuss them with both the Scrum team and management.
It is also likely that specific conflicts will arise over time, depending on the nature of the organization and individuals involved. If they can't be eliminated, identify and acknowledge them.
No. Why would this be a conflict of interest?
The role of the Scrum Master is to remove any blocking issues from the team - if there is something stopping the team from getting its work done, the Scrum Master is the one to remove said impedance. They act as a buffer between the team and the outside world.
The best analogy I can come up with is a Scrum Master is the Head Slave - they had more responsibility in the household, but they were still a slave.
They are NOT Project Managers.
I have an experience wearing two hats simultaneously. There are some my thoughts:
I do not think that there is enough work for Scrum Master if he coaches one team only on a regular basis. After a while Development Team, PO and Company can follow Scrum process without Scrum Master or have technical part-time one.
I think that the main challenge for the Developer/Scrum Master is to stop influence on a team and let them make decisions by themselves.
...They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality...
...Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team...
Only a person that understands Scrum and can coach others (Development Team, PO, Organisation) should be chosen for the Scrum Master role.
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
The Scrum Master helps those outside the Scrum Team understand which of their interact ions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
If you "have the most Agile development experience" in the Development Team then you are the only one right person for the Scrum Master role. There will be you challenge to make sure that everyone will be experienced in Agile as you in a while. If you decide to be a Scrum Master I suggest you read The Scrum Guide.
Do you think that is a conflict of interest?
Based on my experience I personally feel this is a conflict of Interest.
In addition to what is mentioned by CodeGnome , there are high priority items for a developer for example, high severity defects, a build break.. As a developer you should be able to prioritize these & might require addressing them ASAP
As a scrum master you have to give priority to removing the biggest blockers for team in addition to other role related duties
At one point your high priority developer duties & high priority scrum master duties will complete for your time. As a result the quality of output on both roles will suffer.
A conflict of interest only happens in this situation if the person in question allows corruption on the roles.
I used to think you could not be. However I changed that to should not be, because I have known someone balance it very well with great integrity.
Can it be done? Yes.
Should it be done? Probably not.
Take a look here for more http://adaptagility.co.uk/can-the-scrum-master-also-be-a-developer
There is no conflict of interest between a role of "member of the Development Team" and "Scrum Master" being shared by the same person.
The specific responsibilities of a Scrum Master are to ensure that all stakeholders understand and enact the principles of Scrum, help the Scrum Team to understand which internal interactions are beneficial, help stakeholders outside the Scrum Team understand which interactions are beneficial, and change interactions within the Scrum Team and between the Scrum Team and external stakeholders.
There are specific interactions between the Scrum Master and the Product Owner, the Scrum Master and the Development Team, and the Scrum Master and the organization that is implementing Scrum. To all of these people, the Scrum Master provides a service. That is, the Scrum Master does not command or control, but collaborate, help, and facilitate.
To the Product Owner, the Scrum Master helps to find out techniques to manage the Product Backlog (including organization, writing good backlog items, arranging by value), gives an understanding of empirical project planning and how previous Sprints can be used to predict future Sprints work, and help in facilitating events (in my experiences, the Product Owner tends to drive the Sprint Planning, any backlog refinement or grooming activities, and the Sprint Review).
To the Development Team, the Scrum Master enables them to be self-organizing and cross-functional, to deliver value, to remove impediments and road blocks, to facilitate events, to coach the team on what it means to be agile or to be following Scrum.
To the Organization, the Scrum Master assists in the leadership understanding and embracing Scrum, helping to plan implementation, to help everyone understand the purpose of the various team roles and events and artifacts, and coordinate with other Scrum Masters across the various teams.
For each of these, I'd argue that a member of the Development Team is the best candidate.
As a member of the Development Team and a Scrum Master, I:
Participate in every event and ceremony. I am witness to most interactions between members of the Scrum Team among themselves and with external stakeholders (outside of one-on-ones with their manager or deeply technical discussions on work that I am not personally involved in) I can put on my Scrum Master hat at any time to make sure that everyone else on the Scrum Team is adhering to the practices and rules of the Agile Manifesto and the Scrum Guide.
Have to use the Product Backlog to drive my work. I see, first-hand, any problems that may have arisen with the creation or management of Product Backlog Items. This allows me to raise issues that I experience to the Product Owner. Of course, other Development Team members also see things and can bring them up to me to raise to the Product Owner at the same time. However, cutting out the middle man is helpful sometimes in getting things corrected.
By being at every event, I'm there to facilitate it. At standup, I can go to the defined location a few minutes early to make sure that screensharing and voice calling is set up if any team members are remote. I can set up to support meeting notes to capture decisions or questions. I can set up deployment of the software to facilitate myself or other members of the Development Team walking through a review.
By being on the Development Team and involved in the day-to-day work, I can raise questions or concerns when I see cross-functionality not being developed. If one person is trying to take a leadership role, I can point that out. By living my working day with the team, I can ensure that they follow this Scrum principle and encourage it.
I am especially motivated to remove impediments. Often, impediments to one team member also affect me. For example, they may be unable to help me solve a problem or perform a peer review or pair program with me because of a pressing concern.
By living on the Development Team, I can give first hand reports on the impact that Scrum is having on the team's ability to deliver to the organization. I can better reason about Scrum implementation and changes knowing how it will affect the bulk of a Scrum Team.
That said, there are things to watch out for.
The primary concern is that the Scrum Master should not have power over the Development Team. They are a servant-leader, not a manager or director. It's important for the Development Team to remain self-organizing.
The next concern is that the Scrum Master responsibilities do take away from development time. The organization must consider the tradeoffs. Although there are many advantages to the Scrum Master being on the Development Team, that does mean that the Scrum Master has to take on additional work and meet all commitments or that they need to plan for less development output from the Scrum Master.
Finally, the Scrum Master does need to be someone who is supportive of the agile methods and the Scrum framework. Otherwise, this person may be in a position to be apathetic or even detrimental to the organization implementing Scrum. That is not to say that Scrum is the be-all-end-all process model - I regularly look toward Extreme Programming, Disciplined Agile Delivery, Kanban, and other agile methods and practices. However, one must do so in an appropriate manner.
These drawbacks are just that - drawbacks. Every decision has pros and cons. The fact that there are pros and cons does not make a conflict of interest between the two roles.
The only conflict of interest in roles is between the Product Owner and Scrum Master. That is, the same person should not be performing both of these roles. The Product Owner is responsible for driving the product while the Scrum Master protects the team and the integrity of the processes against business or client demands. There is some level of negotiation between these two roles on what capabilities and commitments that the Development Team should make.