Wie ändert sich der Job eines Projektmanagers beim Übergang von Wasserfall zu Agile?

Was ändert sich konkret in den täglichen Arbeitsaufgaben eines PM, wenn man Agile einführt und sich vom Wasserfall wegbewegt? Ich bin besonders daran interessiert, von PMs zu hören, die den Übergang vollzogen haben (oder dabei sind).

Bob, ich würde gerne auf deine Frage eingehen, ich habe einige Gedanken, aber ich hoffe, dass du zuerst ein paar Übungs-PNs bekommst, um zu antworten. Vielleicht hilft es, weitere Tags hinzuzufügen, und ich sehe, dass 5 Seiten zur Auswahl stehen.

Antworten (2)

Ich habe den Übergang vollzogen und auch anderen dabei geholfen (mit unterschiedlichem Erfolg :-)

Änderungen auf hoher Ebene:

  1. Sie werden mehr in einer Serverrolle sein als in der Rolle eines "Kapitäns des Schiffes" (aber Sie haben immer noch Rechenschaftspflicht und Verantwortung ...)
  2. Sie werden schnell feststellen, dass Ihre Zeit für die Verwaltung von Dingen (z. B. das Verfolgen von Stundenzetteln) weniger wird
  3. Ihre abteilungs- und teamübergreifende Kommunikation (face to face) wird dramatisch zunehmen
  4. Sie konzentrieren sich weniger auf den Status und mehr auf Probleme und Risiken
  5. Sie werden einen Großteil Ihrer Zeit damit verbringen, mit Kunden oder Produktmanagern/Eigentümern zu sprechen, um Beteiligung, Klärung und Informationen zu erhalten
  6. Ihr Komfortniveau wird stark sinken, bis Sie und Ihr Team einander wirklich vertrauen

Viele davon sind umstritten. Ich kenne viele Leute, die viel von der "alten" Verwaltung eines Projekts nicht loslassen, obwohl das Team keinen Wert darin sieht und agile Methoden dies nicht ohne Weiteres unterstützen (Earned Value ist ein großartiges Beispiel dafür ) Außerdem gibt es agile PMs, die nicht so praktisch mit dem Team umgehen, sodass Problemlösung und „Beseitigung von Hindernissen“ auf andere Funktionen/Personen verlagert werden.

Einzelheiten der täglichen Aktivitäten sind schwer zu verallgemeinern, aber ... (viele der untenstehenden Personen gehen davon aus, dass Scrum Ihre agile Methode ist)

  1. Sie nehmen an einem täglichen Standup-Meeting mit dem Team teil
  2. Sie werden über dem Product Backlog schwitzen, um sicherzustellen, dass es auf dem neuesten Stand ist
  3. Sie werden einige Zeit damit verbringen, sich die Burn-up- und Burn-down-Charts anzusehen (und zu pflegen).
  4. Sie werden retrospektive Notizen überprüfen und Vorschläge für das Team zur Verbesserung ihres Prozesses machen
  5. Sie arrangieren eine Kundenbewertung des hergestellten Produkts
  6. Hoffentlich sitzen Sie mit dem Team zusammen und hören ihren Diskussionen zu und nutzen Ihre Erfahrung, um bei persönlichen und zwischenmenschlichen Problemen und Hindernissen zu helfen

ymmv!

Zunächst möchten Sie vielleicht einen Blick auf die sehr verwandte Frage zur Rolle des PM in agilen Projekten werfen .

Dann hängt der spezifische Übergang stark von der Art der Projekte ab, die Sie ausführen. Wenn Sie an Lösungen arbeiten, über die Sie die volle Kontrolle haben, wie z. B. interne Projekte ohne zahlende Kunden außerhalb der Organisation, können Sie an dem Punkt landen, an dem es keine formelle PM-Rolle im Projektteam gibt. Dies wäre ein klassisches Beispiel für die Implementierung von Scrum nach Vorschrift. In solchen Situationen wird der PM oft zum Scrum Master, aber es ist eine knifflige Lösung, da der Scrum Master eher ein Coach als ein Projektleiter ist. Eine andere Idee, und die bessere, ist, sich der Rolle des Product Owners zuzuwenden, obwohl es mehr um den Umgang mit dem Produkt als um den Umgang mit dem Projekt geht. So oder so verteilt Scrum einen Teil der typischen PM-Aufgaben über das Team.

Die andere Art von Projekten ist, wenn Sie tatsächlich eine Art externen Kunden haben und dieser Kunde sich wahrscheinlich daran gewöhnt hat, Projekte auf formellere Weise durchzuführen. Denn wenn die Umstellung für Sie neu ist, ist sie wahrscheinlich auch für Ihre Kunden neu. In diesem Fall besteht die wichtigste Rolle des PM darin, die Arbeitsweise des Teams auf den Kunden zu übertragen (auch umgekehrt) und eventuelle Lücken zu füllen. Diese Lücken beziehen sich normalerweise eher auf die formale Seite des Projektmanagements, da agile Teams im Allgemeinen versuchen, sie zu minimieren, obwohl Kunden manchmal ziemlich viele formale Artefakte erwarten. Sie können mehr über einen solchen Ansatz in der Frage zur Zusammenführung verschiedener PM-Ansätze innerhalb derselben Organisation lesen .