Warum können der ScrumMaster und der Projektmanager nicht dieselbe Person sein?

Scrum unterscheidet zwischen der Unterstützung des Teams bei WELCHER Arbeit und WIE sie es tut. Der Versuch, eine Person beide spielen zu lassen, würde zu großen Konflikten führen. Wie wählen Sie in einer stressigen Situation zwischen Verhandlungsfunktionen oder der Unterstützung des Teams beim Wachsen und Erreichen eines Konsens? Ein Scrum Master ist ein Facilitator, wie kann er/sie moderieren, wenn ihm das Projekt auch gehört?

„Die Rollen Product Owner und Scrum Master ergänzen sich gegenseitig; der Product Owner ist in erster Linie für das „Was“ verantwortlich – das richtige Produkt zu erstellen. Der Scrum Master ist in erster Linie für das „Wie“ verantwortlich – Scrum richtig einzusetzen Das richtige Produkt wird mit dem richtigen Prozess hergestellt, um dauerhaften Erfolg zu erzielen." –Roman Pichler, „Agiles Produktmanagement mit Scrum“

Hier ist meine visuelle Ansicht zwischen den Rollen „Tradition“ und „Scrum“ …

http://skipstoneconsulting.blogspot.com/2011/12/identifying-with-titles-or-what-happens.html

Zusammenfassend, um konkret zu antworten: "Warum können der Scrum Master und der Projektmanager nicht dieselbe Person sein"? liegt daran, dass Sie nicht eine Person bitten können (sollten), die Verantwortung dafür zu übernehmen, WIE das Team seine Arbeit erledigt und WELCHE Arbeit das Team leistet, da die Person unter geschäftlichem Druck nachgibt oder eine Seite des Spektrums bevorzugt. Höchstwahrscheinlich der "Was"-Teil. Mit einigen, die über das „Hoch“ wachen, stellen Sie sicher, dass Qualität und gute Teampraktiken und mehr auch den Fokus erhalten, der erforderlich ist, um ein gesundes, leistungsstarkes Team zu erhalten, während sich der andere darauf konzentriert, sicherzustellen, dass ein gesundes, leistungsstarkes Team gut fokussiert wird Input und Vision aus einer Hand.

Warum können der Scrum Master und der Projektverantwortliche nicht dieselbe Person sein?

Es ist einfach der Interessenkonflikt und der Fokus. Das Hauptaugenmerk des Projektverantwortlichen liegt auf dem Erfolg des Projekts und seiner Durchführung, während das Hauptaugenmerk des Scrum Masters auf dem Team und seiner Entwicklung liegt. Zwei verschiedene Dinge, die nicht gleichzeitig von einer Person erfolgreich erledigt werden können.

Auf der anderen Seite gibt es das Zeitproblem. Der Projektinhaber kommuniziert mit Kunden und Stakeholdern und berichtet an die Geschäftsleitung, und diese Aktivitäten sind ziemlich zeitaufwändig, und ich habe noch nie jemanden gesehen, der es geschafft hat, sich dabei um ein Team zu kümmern.

Wie schneidet er im Vergleich zu einem traditionellen Projektmanager ab?

Wenn Sie eine Verbindung zum traditionellen Projektmanagement benötigen, dann ist der Projektinhaber der Projektmanager mit ein wenig architektonischem Geschick.

Der Scrum Master ist dafür verantwortlich, ein Umfeld zu schaffen, in dem das Team ehrlich und transparent kommuniziert und nach besten Kräften liefert. Dies liefert auch Daten, auf die der Projektmanager reagieren kann.

Der Projektleiter ist für den Projekterfolg verantwortlich.

Einige Projekte sollten nicht erfolgreich sein. Es gibt kein Rezept für dauerhaften Erfolg. Einige Projekte werden sich niemals amortisieren, und trotz vieler Behauptungen wird selbst Scrum diese Projekte nicht zum Erfolg führen.

Dies sind oft Projekte, die mit bestehenden Produkten auf dem Markt oder intern mit bestehenden Legacy-Produkten konkurrieren und die Mindestfunktionen dieser Produkte bereitstellen müssen, um erfolgreich zu sein, sodass eine iterative Bereitstellung in dieser Hinsicht nicht hilfreich ist.

Gut gemacht, wird Scrum den Todesmarsch oder die Eskalation des Budgets frühzeitig aufzeigen. Dies steht oft in direktem Wettbewerb mit den Zielen des Projektmanagers, und deshalb ist die Rolle des Scrum Masters nützlich.

Damit ein PM die Rolle eines SM übernehmen könnte, müsste er in einer Organisation arbeiten, die eine transparente Kommunikation über der PM-Managementebene zulässt, und Projekte, die sterben sollten, töten. Dies ist in den meisten Organisationen nicht der Fall, daher können die meisten PMs nicht als SMs fungieren.

Gemäß den Richtlinien für Scrum ist der ScrumMaster dafür verantwortlich, Hindernisse für die Fähigkeit der Gruppe zu beseitigen, das Sprintziel/die Ergebnisse zu liefern.

Der Product Owner hat andere Aufgaben, wie die Vermittlung der Vision, die Organisation und Priorisierung des Product Backlogs, die Befragung von Stakeholdern, um festzustellen, was das Produkt zur Lösung ihres Problems leisten soll.

Das Einzige, was der Product Owner nicht tun darf, ist das Mikromanagement des Teams. Die Verantwortung des Product Owners zu übernehmen und Hindernisse zu beseitigen, wäre nicht nur eine unmögliche Kombination, sondern die Person, die versucht, zu viele Hüte aufzusetzen, würde am Ende wahrscheinlich genau das Gegenteil von dem tun, was der ScrumMaster tun sollte . Anstatt Hindernisse zu beseitigen, wäre diese Person wahrscheinlich das Hindernis.

Der ScrumMaster und der Projektmanager sollten nicht dasselbe sein, weil das Team das Gefühl haben muss, dass sie dem Team (nicht dem Scrum Master) gegenüber rechenschaftspflichtig sind. Tägliche Standups werden dem Team (nicht dem ScrumMaster) gemeldet. Der ScrumMaster ist da, um Hindernisse und Hindernisse zu beseitigen, nicht um das Team zu führen – das Team verwaltet sich selbst.

Das Team sollte sich auf einen Product Owner und einen Scrum Master einigen und nichts sollte das Team daran hindern, die besten Leute – oder Personen – für diese Rollen auszuwählen . Wenn das Team einer einzigen Person vertraut, die beides tut, und die Stakeholder mit dem vom Team gelieferten Wert zufrieden sind, dann sind wir hier fertig.

Die Befähigung des Entwicklungsteams ist der wesentliche Kern von Scrum. Sowohl der Product Owner als auch der Scrum Master müssen verstehen, dass ihre wichtigste Aufgabe darin besteht, dem Team aus dem Weg zu gehen und dem Team zu erlauben oder es sogar zu zwingen, zu lernen, seine eigenen Probleme zu lösen.

• Der Product Owner ist gegenüber den Stakeholdern für den Inhalt des Backlogs und den vom Team gelieferten Wert verantwortlich.

• Der Scrum Master ist die Ressource des Teams in Bezug auf die Regeln von Scrum und hilft auch sicherzustellen, dass Manager, Stakeholder, der PO und der SM selbst die Fähigkeit des Teams zur Selbstorganisation nicht beeinträchtigen.

An diesen Verantwortlichkeiten ist nichts Unvereinbares, und keine davon ist unbedingt ein Vollzeitjob (insbesondere wenn das Scrum-Team erfahrener wird), also gibt es keinen Grund, warum sie nicht von derselben Person ausgeführt werden können . Da keiner von ihnen dem Team sagen kann, was zu tun ist, sollte kein Interessenkonflikt entstehen.

Traditionelle/hierarchische Berufsbezeichnungen wie „Produktmanager“ (oder „Entwicklungsleiter“) sind für Scrum irrelevant und sollten vom Team ignoriert werden. Diese Personen können PO oder SM sein oder auch nicht. Bei der Auswahl von „Managern“ oder „Leads“ für Scrum-Rollen besteht ein besonderes Risiko, nämlich dass das Team die Angewohnheit hat, sich diesen Personen zu unterwerfen, was die Selbstorganisation untergräbt. In diesem Fall sind erhebliche Anstrengungen erforderlich, um sicherzustellen, dass sich das Team selbst verwaltet und Verantwortung für seine eigene Arbeit übernimmt!

Ein Projektmanager ist der Besserwisser Mann/Frau auf einem Machttrip, der einem sagt, was zu tun ist, und man hasst ihn deswegen.

Der Scrum Master ist ein Weiser wie Herr Miyagi, der dem Helden der Geschichte beibringt, wie man gewinnt. Wir alle lieben Herrn Miyagi.

Menschen können dich nicht gleichzeitig lieben und hassen, also kannst du nicht beides sein.

Jetzt eine ernsthafte Antwort.

Wenn Sie bereit sind, die Definition von „Projektmanager“ als jemand zu akzeptieren, der Wissen, Fähigkeiten und Techniken anwendet, um die Projektanforderungen zu erfüllen, ist ein Scrum Master ein PM. „Facilitation“ und „Autorität über den Prozess“ ist das Management, damit die Anforderungen erfüllt werden. Wenn Sie die Definition eingrenzen möchten, stehen Sie im Widerspruch zu "Industrie" (ich habe die Definition vom PMI).

Scrum ist ein agiles Prozess-Framework. Die Leute vergessen, dass ein agiles Projekt durch Zeit und Kosten begrenzt ist. Anstatt den Umfang im Voraus zu definieren, tun agile Projekte, was Zeit und Kosten zulassen. Sie priorisieren einfach den Umfang (Backlog) nach dem Geschäftswert und beten, dass genügend Zufriedenheit erreicht wird, um als „erfolgreich“ zu gelten. Agile ist entstanden, weil einige Projekte (Softwareprojekte) eine Menge Ungewissheit aufweisen und es wurde festgestellt, dass der beste Weg, mit Ungewissheit umzugehen, darin besteht, sie schnell zu beseitigen. Sie können annehmen, dass ein „Projektmanager“ niemals in einem solchen Umfeld arbeitet, und Sie würden sich irren.

Manchmal ist eine Person mit PM als Berufsbezeichnung nur ein Scrum Master für ein nicht agiles Projekt. Sie treffen keine Entscheidungen. Sie erleichtern einen Prozess. Sie sollen „Hindernisse beseitigen“. Sie definieren oder erledigen keine der eigentlichen Aufgaben. Die einzige Autorität, die sie haben, ist der Projektmanagementprozess. Manchmal können sie mehr tun, genauso wie ein Scrum Master möglicherweise aus seiner Rolle heraustreten und mehr tun muss.

Ein wesentlicher Unterschied zwischen einem PM und einem Scrum Master besteht darin, dass ein PM den Prozess auf das Projekt abstimmt. Das Scrum-Framework scheint ein „Malen nach Zahlen“-Projektmanagement-Framework für kleine Softwareteams zu sein, und das Färben außerhalb der Linien gilt als „schlecht“.

Wenn Sie das Problem in Bezug auf Konflikt, Fokus, unterschiedliche Ziele, WAS, WIE und Segregation sehen, ja, SM und PO können nicht dieselbe Person sein, es sei denn, es hat eine doppelte Persönlichkeit.

Aber wenn Sie Dinge von kooperativer Teamarbeit, übergreifender Kompetenz und Leidenschaft sehen, um dem Kunden einen Mehrwert zu bieten (Agile), sehe ich keinen Grund, warum SM und PO nicht dieselbe Person sein sollten.

Wenn Sie die Aufgaben und Verantwortlichkeiten auf der Mikroebene sehen, ja, das ist ein riesiger Unterschied. aber wenn Sie von der Perspektive der Makroebene aus schauen, ändert sich das erheblich. es ist Ansichtssache, wo man seine Perspektive einstellt. Ich habe diese Lektion von einem großartigen Typen gelernt, der tatsächlich etwas für die Agile-Community schafft, das er "Dude's Law" nennt.

Ich muss auch zugeben, dass die zweite Perspektive in hoch hierarchischen, segregierten, nicht agilen Unternehmen nur sehr schwer zu erreichen ist.

Es gibt eine Jobrolle, die Aspekte von Projektmanager und Scrum Master in einer agilen Umgebung kombiniert. Die Rolle des Delivery Managers ( https://gds.blog.gov.uk/2012/12/12/a-day-in-the-life-of-a-delivery-manager/ ) wurde von der britischen Regierung genutzt Digital Services & andere Organisationen seit mehreren Jahren.

Die Rolle des Delivery Managers führt die Servant-Leader-, Stand-up- und andere zeremonielle Aspekte des Scrum Masters sowie die Projektplanungsaspekte des PM aus.

http://itsadeliverything.com/delivery-manager-a-new-role-for-an-agile-world

Kurz gesagt, sie haben unterschiedliche Verantwortlichkeiten und die Rolle des Scrum Masters ist nicht festgelegt, während der Product Owner normalerweise für jedes Produkt gleich bleibt.

Langfristig ist der Product Owner schuld, wenn das Produkt fehlschlägt, während der Scrum Master nichts damit zu tun hat.

In den meisten Antworten, die ich gelesen habe, argumentieren viele, dass der Projektmanager nicht die Zeit hat, das Team im Mikromanagement zu führen. Wir brauchen also einen Scrum-Master, der das Team leitet, und der Projektmanager übernimmt die größeren Aufgaben wie die Kommunikation mit Kunden usw. Ich habe nie so gehandelt. Ich habe das Team, für das ich verantwortlich war, immer vollständig geleitet. Ich würde niemals ein Scrum implementieren, ich würde mich eingeschränkt fühlen in dem, was ich tun möchte und wie ich es tun soll.

Daher spreche ich lieber von:

1. Projektmanager : Die Person, die für alle Managemententscheidungen verantwortlich ist.
2. team : diejenigen, die den Job liefern.
3. Kunde : Diejenigen, die das Geld bezahlen, um ein Projekt zu erledigen.

Das ist die traditionelle Art, ein Projekt zu managen, aber ich denke, es ist immer noch die beste.

Das Problem bei jedem Projekt ist die effektive Kommunikation. Ich ziehe direkte menschliche Beziehungen E-Mails vor, aber nicht immer. Ich bin davon überzeugt, dass das direkte Gespräch mit Ihren Teammitgliedern, um Probleme zu lösen und innovativ zu sein, einen besseren Teamgeist aufbaut als alles andere.

Ich bevorzuge ein leichteres, selbst entworfenes Modell, auf das sich jeder nach einem Treffen einigen kann.

E-Mails oder Planungssoftware sollten verwendet werden, um sich regelmäßig wiederholende Aufgaben zu erledigen, um den Projektmanager dabei zu unterstützen, stattdessen etwas anderes zu tun: sein Team zu verwalten und einen Teamgeist aufzubauen. Es ist eine sehr persönliche Ansicht, die auf meiner eigenen Erfahrung basiert.

Ich habe gelernt, auf meine eigenen Fähigkeiten zu vertrauen, wie wir alle, und auf die meiner Teammitglieder, insbesondere wenn es darum geht, innovativ zu sein und die Arbeit rechtzeitig zu erledigen, aber vor allem, wenn es darum geht, sich gemeinsam darauf zu einigen, wie man es macht. Es macht mir so viel Spaß, so zu arbeiten.

Ich habe oft gesehen, wie Leute die meiste Zeit damit verbrachten, ein Modell zu implementieren, das eigentlich nicht so nützlich war. Ich finde Modelle manchmal sehr komplex, um einfache Verwaltungsaufgaben zu erledigen.

Ich habe in meinem Studium die Grunddimensionen des Managements für jede Situation kennengelernt:

1) Planung : Was werden Sie tun und mit welchen Ressourcen.

2) Organisieren : Menschen mit materiellen Ressourcen zusammenbringen, um die Arbeit zu erledigen.

3) Regie : Führung des Teams durch den Prozess von Anfang bis Ende.

4) Bewerten : Ständiges Feedback, um zu bewerten, ob die in Schritt 1 gesetzten Ziele erreicht werden.

Das sind die vier Dimensionen des Managements für alle Situationen. Ich wende sie immer an, finde aber jedes Mal einen neuen und innovativen Weg für neue Projekte. Wenn das Projekt dasselbe ist, wiederholen wir eine erfolgreiche Erfahrung aus der Vergangenheit. Ehrlich gesagt mag ich es nicht, in einem zu starren Rahmen zu sein.

Mein Standpunkt ist, dass jede Art von Projekt nur einen Projektmanager haben sollte, keinen anderen Manager wie zum Beispiel einen Scrum Master. Im Scrum-Modell habe ich das Gefühl, dass sie die Aufgaben des Projektmanagers unnötig in 2 oder mehr aufgeteilt haben. Es ist aus meiner Sicht aufgrund meiner Erfahrung ein Rezept für Autoritätskonflikte.