Helfen Sie mir, meinen Titel Projektmanager mit der Ausübung der Rolle eines Scrum Masters in Einklang zu bringen

Ich habe als Projektmanager, als Scrum Master und als Projektmanager an dem gearbeitet, was grob als Scrum bezeichnet wird.

Wie Sie zu Recht erwähnen, gibt es große Unterschiede zwischen der Arbeitsweise als Projektmanager und als Scrum Master. Der wahrscheinlich wichtigste Unterschied ist, dass ein Scrum Master kein Manager ist, sondern ein dienender Leiter. Das ist ein grundlegender und unüberbrückbarer Unterschied.

Allerdings ist es möglich, den Titel Projektmanager zu führen, aber die Rolle des Scrum Masters zu übernehmen. Die größte Herausforderung liegt nicht beim Team, sondern bei Ihrer Beziehung zum Management und zu denen außerhalb des Teams. Es wird eine Zeit kommen, in der das Management etwas verlangt, das es zu Recht von einem Projektmanager erwartet, aber das ein Scrum Master niemals tun würde.

Ein möglicher Ansatz besteht darin, die Rolle des Scrum Masters zu übernehmen und einige Zeit damit zu verbringen, Manager und Personen außerhalb des Teams darin zu coachen, wie Scrum funktioniert. Wenn Sie dies tun und ein aufgeschlossenes Management haben, ist es möglich, ein erfolgreiches Scrum-Team zu führen.

Wenn wir uns auf Rollen und nicht auf Jobtitel konzentrieren, wobei PM auch eine Rolle mit Aktivitäten ist, dann erkennen Sie, dass Scrum das traditionelle Team-PM in den PO und den SM aufteilt. Der PO verwaltet das Produkt, während der SM den Prozess verwaltet.

Es gibt keine Rolle des Projektmanagers, wenn es um das Team geht, aber der Projektmanager kann für den Product Owner arbeiten und ihm helfen, Kunden und Lieferung zu organisieren.

Sobald Sie die Rolle des Projektmanagers mit der Aufsicht über das Team besetzen, werden Sie die Vorteile, die den Wert von Scrum ausmachen, zunichte machen.

Wenn Sie ein PM sind, der versucht, mit einem agilen Team zu liefern, müssen Sie auswählen, was Ihnen wichtig ist, Prozess oder Produkt. Beides kann es nicht sein...

Ich denke, Sie sollten sich daran erinnern, dass ein Scrum Master eine Rolle ist, nicht unbedingt ein Titel. Theoretisch könnten Sie als Project Master Manager Guy bezeichnet werden und trotzdem die Rolle eines Scrum Masters einnehmen.

In meiner vorherigen Position war mein Titel IT-Projektmanager, aber meine tägliche Rolle war Scrum Master.

Warum so konzentriert auf den Titel und nicht auf den Job?

Einige andere Antworten haben dies erwähnt, aber es gibt einen Unterschied zwischen Ihrem Titel und Ihrer Rolle. Ihr Titel in der Organisation kann Projektmanager sein, aber Sie könnten unterschiedliche Rollen in einem Scrum-Team haben. Sie können Elemente des Projektmanagers sowohl in der Scrum Master- als auch in der Product Owner-Rolle sehen. Da Sie auch erwähnen, dass Sie der funktionale Manager des Entwicklungsteams sind, interessiert Sie möglicherweise diese Frage, die darauf hindeutet, dass es Probleme mit dieser Anordnung gibt .

Die spezifischen Aufgaben, die Sie erwähnen, sind in der Regel den Verantwortlichkeiten des Product Owners zugeordnet. Das Verwalten von Umfangselementen, das Abgleichen von Arbeitselementen mit dem BRD/SRS und eingereichten Änderungsanforderungen unterscheidet sich nicht wesentlich vom Verwalten des Produktrückstands durch Hinzufügen, Entfernen und Priorisieren von Stories und die Zusammenarbeit mit dem Entwicklungsteam, um die Stories sicherzustellen. Das Einhalten von Fristen ist auch teilweise die Rolle des Product Owners, da ein Teil der Aufgabe des Product Owners darin besteht, sicherzustellen, dass der Wert für den Benutzer bereitgestellt wird, wenn er benötigt wird.

Sie sagen nicht, wie groß Ihr Entwicklungsteam ist. Scrum hat nur drei Rollen – Product Owner, Scrum Master und Mitglied des Entwicklungsteams. Es ist nicht unvorstellbar, dass ein hochrangiges Mitglied des Entwicklungsteams (vorzugsweise mit einigen Grundkenntnissen in Scrum) in die Rolle des Scrum Masters wechseln kann, während es weiterhin als Mitglied des Entwicklungsteams fungiert, sodass Sie die volle Rolle des Product Owners übernehmen können , die Ihren derzeitigen Verantwortlichkeiten entsprechen würde. Wenn Sie nach dieser Anpassung aus irgendeinem Grund unterlastet sind, sollten Sie erwägen, etwas Arbeit im Testen (hauptsächlich Akzeptanztests) oder als Domänenexperte zu übernehmen (vorausgesetzt, Ihr Team hat noch keine Domänenerfahrung).

Was Ihre "Nicht-Scrum" -Sachen angeht, würde ich mich nicht allzu sehr um diese kümmern. Ihr konkretes Beispiel, dem Management eine Vorstellung davon zu geben, welche Stories kommenden Sprints zugeordnet werden können, mag eine gute Idee sein. Dies kann ihnen beim Übergang von plangesteuerten Methoden, bei denen jede Aufgabe ein festes Datum hat, zu agileren Methoden helfen. Der Schlüssel hier ist sicherzustellen, dass jeder erkennt, dass alles außerhalb des aktuellen Sprints vorläufig ist – Prioritäten können und werden sich ändern, weshalb es nicht zu viele feste Zusagen zu weit in die Zukunft gibt.

Denken Sie daran, dass Scrum ein Framework ist. Es gibt einige Puristen da draußen, aber Sie müssen bedenken, dass Sie von plangesteuerten Methoden zu agilen Methoden übergehen und es Zeit braucht, den neuen Ansatz zu lernen und ihn vollständig einzuführen – es ist nicht nur das Umlegen eines Schalters. Sie sollten den Rahmen gegebenenfalls auch anpassen und dabei die Erfahrungen von Personen berücksichtigen, die vor Ihnen den Übergang vollzogen haben.

Versuchen Sie nicht, sich an Namen, Rollen und Methoden zu halten. Holen Sie sich diejenigen, mit denen Sie und Ihr Team gerne zusammenarbeiten.

Zwei Gedanken – 1. Wenn Sie sich nicht mit einer CSM-Schulung befasst haben (z. B. Scrum Alliance), da dies die Theorie hinter der Scrum-Bereitstellungsmethode vermittelt. 2. Erkennen Sie, dass ein PM in Scrum bedeutet, dass Sie ein Coach und Guide sind, kein Leader. Die Führungsrolle liegt beim Team. Es ist eine Herausforderung für einen PM, kein PM zu sein- Ihre Rolle besteht darin, sicherzustellen, dass das Team über alle Ressourcen verfügt, die es benötigt, um den Sprint rechtzeitig abzuschließen. Dies beinhaltet den Zugang zu KMUs sowie den technischen Kram. Es soll auch sicherstellen, dass die Scrum-Rollen für alle klar sind – Team und Stakeholder. Der Product Owner sollte im Geschäft sein. Scrum Master ist beim Team (könnten Sie sein). In der Praxis muss man meiner Meinung nach auch sehen, ob es eine Architektenrolle gibt – das „Hervortreten“ der Architektur macht manche Leute im Business / IT-Management nervös. Auch das Vorsehen von Grenzen (Geschäftsarchitektur und Technologiearchitektur) ist keine schlechte Sache – hält die Entscheidungsfindung fokussiert. Ideal - experimentieren! Versuchen Sie, die Rollen zu wechseln, und sehen Sie, was sich verbessert. Fragen Sie das Team, was es braucht. Gleiches gilt für den Product Owner. Es könnte einfach Spaß machen!