In einem neuen Team entschied sich ein ehemaliger Entwicklungsleiter, der diese Position seit vielen Jahren bekleidet, als Product Owner des Teams. Das Team hat sich für Scrum entschieden.
Die agile Mentalität des PO ist sicherlich vorhanden, aber er kann es sich nicht angewöhnen, sich auf das „Was“ zu konzentrieren und vom „Wie“ abzuweichen und dem Entwicklungsteam zu vertrauen, dass es sich um das „Wie“ kümmert. Als zusätzliche Schwierigkeit kommt hinzu, dass die Hälfte der Teammitglieder sehr junge Entwickler sind, und der PO versucht, sie anzuleiten (oder Papa zu spielen), damit er sie am besten unterstützt.
Diese "Führung" blutet jedoch im ganzen Team, bis zu dem Punkt, an dem alles durch ihn geht. Der Scrum Master hat das angesprochen und mit dem PO über dieses Verhalten diskutiert, und die Argumente des PO waren, dass erstens alte Gewohnheiten nur schwer sterben und er versucht, seine Haltung zu ändern, und zweitens, dass er den Junior halten muss die Hand der Entwickler ein wenig, bis sie das Produkt kennen und ein wenig reifen, sodass sie in der Lage sind, Verantwortung zu übernehmen und ihre eigenen Entscheidungen zu treffen.
Alles in allem hat der PO einen guten technischen Hintergrund und ist in der Lage, Vorschläge zu machen und Anleitungen zu geben (er tut dies jeden Tag im morgendlichen Gedränge), es besteht jedoch die Gefahr, dass dieses Verhalten in Zukunft die Norm sein wird, weshalb es zu Kürzungen kommt von den Flügeln der Entwickler.
Sehen Sie in diesem Paradigma etwas falsch, und wenn ja, was würden Sie diesem PO (oder Scrum Master) bei solchen Gelegenheiten raten?
Ich denke, der Zeitpunkt ist wichtig.
Während des täglichen Gedränges muss er sich auf das „Was“ konzentrieren.
Wenn er während des restlichen Tages das Gefühl hat, dass seine Erfahrung (für Junioren) wertvoll ist, gibt es keinen Grund, ihn davon abzuhalten, wertvolle Ratschläge zu erteilen.
Aber er kann den Alltag nicht verunreinigen.
Sobald er „herumlaufen“ muss, um seine Ratschläge individuell zu erteilen, wird er wahrscheinlich wählerischer sein, wen er unterbricht , und das „Bluten“ wird auch aufhören.
Dies ist ein Problem mit einer einfachen Lösung, die leider schwer zu implementieren ist.
Es ist einfach, weil der PO nur seinen Stil ändern muss, von Händchenhalten oder Entscheidungen für das Team treffen oder Vorschriften machen, zu jemandem, der sich eher wie ein Trainer verhält und sich hauptsächlich darauf konzentriert, „die richtigen Fragen“ zu stellen, damit die Leute die Dinge herausfinden sich. Jeder muss auch mit dem Scheitern zufrieden sein, denn Menschen werden Fehler machen und man muss akzeptieren, dass Fehler manchmal der beste Weg sind, etwas zu lernen.
Es ist schwer umzusetzen, weil es bedeutet, Gewohnheiten zu ändern und die Situation immer im Auge zu behalten. Sie müssen sich selbst dabei erwischen, wie Sie das aktuelle Verhalten ausführen, und auf das neue Verhalten umstellen. Das ist einfach aufgrund der menschlichen Natur schwierig. Die PO muss sich bewusst sein, was sie tut, und über die Auswirkungen nachdenken. Sie müssen sich fangen und sagen "Hey, ich mache das Ding wieder". Der SM kann eine Diskussion mit dem PO führen und sich darauf einigen, wie die Dinge zu handhaben sind, dann kann der SM helfen, das alte Verhalten abzufangen und sagen: „Hey, du machst das Ding wieder“.
Sie haben sehr gut festgestellt, dass die derzeitige Arbeitsweise zur Norm werden und eine Abhängigkeit von einer Person schaffen kann, während der Rest des Teams sich nur um sie kümmert, aber Sie können nicht einfach aufhören. Sie müssen auf eine neue Arbeitsweise umsteigen. Sprechen Sie dieses Thema also bei Ihrer nächsten Retrospektive mit allen an (nicht nur etwas zwischen PO und SM). Und entscheiden Sie gemeinsam, was Ihrer Meinung nach der bessere langfristige Ansatz ist und was einige erste Schritte sind, um Sie dorthin zu bringen (vielleicht koppeln Sie ein Programm, vielleicht beißen einige Leute in den sauren Apfel und versuchen, etwas zu tun, indem sie weniger mit dem PO interagieren, vielleicht einige Schulungen sind erforderlich usw.). Dann prüfen und anpassen.
Ich würde empfehlen, das Team zusammenzubringen, um Rollen und Verantwortlichkeiten zu besprechen.
Sie könnten die Vor- und Nachteile einer Person in der Rolle des Product Owners auflisten, die einen technischen Beitrag zur Arbeit leistet und auch Autorität über Teammitglieder hat.
Versuchen Sie im Idealfall, einen Weg zu finden, um zu verfolgen, ob das Verhalten problematisch oder vorteilhaft ist. Vielleicht ein häufiger Check-up in den Retrospektiven?
Sie können die Praxis (Vereinbarung) einführen, dass die Junior-Entwickler zuerst zu ihren erfahreneren Kollegen im Team gehen.
Tun Sie dies entweder reaktiv (die Junioren haben Fragen) oder proaktiv (ein Senior setzt sich vorher/zu bestimmten Zeitpunkten mit einem Junior zusammen).
Die Tatsache, dass Sie sagen, dass sich diese Person für die PO-Rolle „angemeldet“ hat, scheint Teil des Problems zu sein. Üblicherweise wählen sich POs nicht selbst aus. Von einem PO wird normalerweise erwartet, dass er ein Business Manager ist, kein Entwickler oder IT-Management-Experte. Ein PO ist jemand, der für einen Geschäftsbereich oder ein Produkt verantwortlich ist, Entscheidungen über die Produktausrichtung treffen und umsetzen kann und gegenüber den wichtigsten Interessengruppen und der Geschäftsleitung für den kommerziellen Erfolg rechenschaftspflichtig ist.
Hat Ihr PO diese Art von Verantwortung? Wenn dies der Fall war, hat er sich nicht für die Rolle "angemeldet", sie wurde ihm entweder zugewiesen oder er wurde durch Vereinbarung mit einer größeren Gruppe von Personen ausgewählt. Wenn Ihr PO nicht wirklich jemand mit dieser Art von Rolle und Verantwortung ist, dann versucht er vielleicht, als Stellvertreter für die wirklichen Stakeholder zu fungieren. Die beste Lösung könnte darin bestehen, dass sich das Team mit tatsächlichen Stakeholdern befasst und sie dazu bringt, ihre PO zu benennen.
Ich war in einer ähnlichen Situation und als agiler Evangelist sah ich in der gegebenen Situation keinen Ausweg. Ich werde also die Probleme auflisten, die Sie lösen müssen, damit Ihre Bestellung damit aufhören kann.
Ihnen fehlt ein technischer Lead
Während das Verhalten des PO es schwieriger macht, die technische Verantwortung zu übernehmen, ist er nicht Vollzeit in Ihre technische Lösung involviert. Er muss mit Stakeholdern sprechen, User Stories schreiben und viel „Papierkram“ erledigen. Wenn er bei alledem noch so viel Wissensvorsprung hat, dass „alles durch ihn geht“ , fehlt Ihnen ein fachlicher Gegenpart.
Der technische Leiter sollte in der Lage sein, alle Fragen von PO so weit zu beantworten, dass die technische Beratung von PO obsolet wird. Auch der technische Leiter muss eine Persönlichkeit haben, die sich gegen die Haltung von PO stellt.
Trotzdem sollten Sie den Rat von PO nicht ignorieren, wenn er wertvoll ist. Arbeite daran, den Rat nicht mehr zu brauchen.
Der Scrum Master macht seinen Job nicht
Ich habe gelesen, dass Ihr Scrum Master bereits PO aufgerufen hat, aber warum hat sich nichts geändert?
Als ersten Schritt würde ich PO verbieten, sich im täglichen Stand-up zu äußern. Er ist da, um Fragen zu beantworten und ansonsten zu schweigen. Wenn er ausdrücklich um technischen Rat gebeten wird, kann er sein ganzes wertvolles Fachwissen weitergeben. Gleiches gilt für die Zeit zwischen den Zeremonien. Er darf das Team nicht mit unerbetenen Ratschlägen stören.
Als nächstes sollte der Scrum Master alle Teile in den Akzeptanzkriterien der User Stories entfernen, die das „Wie“ anstelle des „Was“ erklären. In meinem Fall habe ich Hinweise als Kommentare hinzugefügt, um dem Team einen Ausgangspunkt zu geben, aber klargestellt, dass dies nur schnelle Gedanken und keine Anforderungen sind. Manchmal waren meine Ideen hilfreich, manchmal waren sie nutzlos. Der Scrum Master muss dieses Screening zusammen mit dem Product Owner durchführen, denn etwas, das wie ein Implementierungsdetail aussieht, könnte tatsächlich eine harte Anforderung sein, zB ein anderes System verlässt sich darauf.
Bilden Sie Ihren Product Owner kontinuierlich weiter
Er muss verstehen, wie sein Verhalten das Team zurückhält. Vielleicht versteht er einige Arbeitsabläufe nicht. Scrum ist sehr vage und gibt Ihnen keinen klaren Aktionsplan. Deshalb braucht PO jemanden, der ihn anleitet und Best Practices vermittelt. Optimalerweise wäre das der Scrum Master, aber wenn sie nicht auf persönlicher Ebene verbunden sind, ist es möglicherweise besser, nach jemand anderem in Ihrer Organisation zu suchen. Da sich das Team im Laufe der Zeit verbessert, muss auch der Product Owner an kontinuierlichen Verbesserungen arbeiten.
Bogdan