Yesterday afternoon, while I was doing some CrossFit training (and I was finally able to close my first muscle up!!!) I noticed a team mate that had a tattoo on the back of his neck:
</head>. I couldn't but tell him he had a very great idea! Then he asked me if I worked in the IT as well, and what my job was.
When I replied "Scrum Master" (among other things) he was surprised to hear that there are some realities having a "real Scrum Master" person.
Most of the time, organizations - in particular those that are new to Agile and Scrum - think that the Scrum Master role (or to use the words of the Scrum Guide, the Scrum Master Accountabilities) may be covered by professionals wearing also other hats, because they don't see the need of a person working eight hours a day, five days a week, just to care about processes and people interaction.
Bear in mind that if Scrum Masters combine multiple roles, they can wear only one hat at a time and they have to be clear and say in which role they are speaking or acting. Otherwise they won't be transparent, and all roles will suffer.
The Scrum Master is a Developer
When the Scrum Master is part of the developers, there is mutual trust between him/her and the developers. The Scrum Master not only has a good understanding of Scrum, but also of team weaknesses from the inside, and can easily point them out at a Retrospective.
If the Scrum Master is too much engaged as a developer, (s)he lacks the overall view and system thinking ability. (S)he may lack leadership and change management skills too. In addition (s)he may be less willing to improve the team, therefore (s)he cannot move the team to the next level.
The Scrum Master role is usually treated as not important, and often disappears. When wearing the hat of a Scrum Master, the developer is demoted to the level of a team assistant, so maybe it's better to continue helping the team with their work and don't care about improving processes at all.
The Scrum Master Is a Product Owner
Usually a Product Owner is seen as a judge, a boss, a person that has always to point out things that are wrong about the increment. A Product Owner who is also a Scrum Master is more likely to be treated as part of the team.
There is a huge conflict of interest because the Scrum Master and Product Owner accountabilities have conflicting goals. The Scrum Master should not be responsible for delivery, but should aim at making the process (people and interactions) better. It's the Product Owner's main goal to care about the product and its delivery. When a Scrum Master is a Product Owner too, there is a conflict between business needs and team self-awareness. It's about balancing long-term versus short-term improvements and results.
As above, in most cases the role of Scrum Master is neglected and the Product Owner controls everything. The Scrum Team usually lacks any deep Scrum understanding and self-organization, and the whole team may be loose motivation.
A full-time Scrum Master works with multiple Scrum Teams
Dealing with multiple contexts, the Scrum Master gains experience in less time, and is able to find a general approach to problem solving. Studies say that a Scrum Master should at maximum work for two or three teams at one time.
If the teams are too many, the Scrum Master can't have the time to prepare the work to be done, and can't process the necessary information to prevent conflicts and move the team forward. Even independent problems may arise at the same time. The inability to facilitate discussions early enough and prevent conflicts from growing often makes the job quite difficult.
Such a Scrum Master has more experience and is usually much better at system thinking because he understands that every team is different. Based on his experience of different environments, he is more likely to be successful in implementing Scrum in different cultures. He is also more likely to apply Scrum over the entire organization and will not be too attached to a specific development team
The Scrum Guide does not prohibit the Scrum Master to cover other roles, but does not recommend it either. Since every context is different, you should evaluate what situation better suits your needs.