Meiner Erfahrung nach birgt diese Aufgabenverteilung mehr Risiken als Vorteile. Doppelrollen sind in Scrum in den unterschiedlichen Konstellationen zwar gängige Praxis, aus meiner Sicht aber nicht zu empfehlen. Daraus entstehen für den Mitarbeiter Zielkonflikte, die den Scrum Prozess beeinträchtigen können. Egal ob Entwickler oder Product Owner, eine neutrale Position einzunehmen und nicht die Interessen der eigentlichen Rolle zu vertreten, ist schwierig und häufig auch einfach ineffizient. Eine mediative Rolle ist dringend nötig, um zwischen den verschiedenen Parteien zu vermitteln und kann so nicht mehr gewährleistet werden. Schafft der Mitarbeiter es zwar seine eigene Meinung zurückzustellen, um neutral zu bleiben könnte es andererseits einen Verlust für die Inhalte bedeuten, da sein Input gut und nötig ist. Auch für die Velocity ist es nicht optimal Doppelrollen zu vergeben. Die Aufgaben eines Scrum Masters sind sehr individuell und auch von Sprint zu Sprint in ihrer Intensität schwankend. Somit ist schwer einzukalkulieren, wie viel Zeit dem jeweiligen Mitarbeiter im jeweiligen Sprint zur Verfügung steht und ein angemessenes Planning durchzuführen. Besonders in kleinen Teams ist so eine Veränderung schnell spürbar. Aber auch auf Seiten des Product Owners würde die Qualität der User Stories in einigen Sprints leiden, wenn mehr Scrum Problematiken auftauchen als erwartet. Auch die Bereitschaft weniger technische und mehr zwischenmenschliche / coachende Aufgaben zu übernehmen, muss vom Mitarbeiter da sein. Natürlich stellt ein Scrum Master immer einen Kostenfaktor dar und ist in seinen Aufgaben schwer messbar. Dennoch lohnt es sich aus meiner Sicht hier zu Investieren und Probleme im eigentlichen Entwicklungsprozess, so schnell anzugehen und das Team voranzubringen, statt zu belasten. Die Rolle des Scrum Masters wurde nicht umsonst im Scrum Guide definiert und beim lesen der Aufgaben wird auch relativ klar, weshalb eine Besetzung in Volzeit Sinn macht.