Meiner Erfahrung nach wächst Agilität in mittleren bis großen Softwareunternehmen meistens aus der Ingenieurorganisation heraus. Entweder an der Basis, auf Teamebene oder von der technischen Geschäftsleitung gesponserte Führungskräfte. Dies bedeutet, dass die Entwicklungsorganisation Agile oft lange vor dem Rest des Unternehmens einsetzt.
Die Herausforderung besteht darin, dass die Produktmanagementorganisation immer noch nach ihrem traditionellen Modell arbeitet. Dies kann zu einer großen Hürde für die Übernahme agiler Projekte führen. Die Entwicklungsorganisation versucht, in einem iterativen Stil zu arbeiten, aber Anforderungen werden immer noch in den Anforderungsdokumenten des alten Stils geliefert und alle im Voraus detailliert. Der Widerstand gegen das agile Modell kann oft hoch sein. "Es ist mir egal, wie die Technik es baut, ich baue einfach, was ich will." Produktmanagement-Organisationen wollen auch selten den Zeitaufwand eingehen, den ein Product Owner auf sich nehmen muss. Sie sind zu sehr damit beschäftigt, zum nächsten Kundentermin zu rennen.
Ich kenne zwei Modelle, um zu versuchen, die Produktmanagement-Organisation einzubeziehen.
Der Projektmanager/Scrum Master fungiert als PO-Schnittstelle: Arbeitet mit der PM-Organisation zusammen, um sie zu coachen und ihre Anforderungen zu übersetzen. Vertritt den PM als PO in regelmäßigen Meetings. Ich habe persönlich mit diesem Modell gearbeitet und ich glaube nicht, dass es gut funktioniert.
Erstellen Sie ein Product-Owner-Büro: Ich habe von einem mittelständischen Unternehmen gehört, in dem der VP von Eng ein Product-Owner-Büro eingerichtet hat. Dieses Büro ist im Ingenieurwesen und wird von Technikern mit kaufmännischen Kenntnissen besetzt. Das Produktmanagement liefert seine Anforderungen an dieses Büro und von dort geht der normale agile Prozess weiter. Keine Informationen darüber, wie erfolgreich (oder nicht) dies ist.
Irgendwelche Vorschläge?
Ich würde die Situation aus der Change-Management- Perspektive angehen. Was Sie beschrieben haben, ist ein häufiges Problem und tritt ständig auf, nicht nur bei Agile. Die Änderung kommt von innerhalb der Gruppe – von Entwicklern – und anstatt die Gruppen anzupassen, entscheidet sie sich dafür, gegen die neue Norm zu kämpfen.
Was Sie brauchen, ist etwas, das in diesem Video gezeigt wird . Da ist ein Typ, der anfängt zu tanzen – ein komischer Typ –, und eine Weile tanzt er alleine. Etwas später gesellt sich der Frühaufsteher zu ihm, er zeigt ihm, wie man tanzt und sie tanzen zusammen, während andere zuschauen. Nach ein paar Minuten schließen sich die anderen an und sie tanzen zusammen. Für mich ist der erste Tänzer ein aufgeschlossener PO , der Tanz ist der Agile, aber so schnell wird es nicht gehen.
Die TODO-Liste, um etwas Ähnliches zu starten:
Den richtigen PO zu finden ist eine schwierige Aufgabe , aber es muss einen Mann geben, der vorher Entwickler war oder neugierig auf neue Dinge ist. Ich bin mir ziemlich sicher, dass es ihn gibt. Ohne ihn wird die Veränderung nicht passieren, also musst du ihn finden.
Ihm zu helfen, ein Initiator zu werden , bedeutet, dass Sie mit ihm zusammenarbeiten sollten, um ein großartiger PO zu werden. Es gibt kein gutes Rezept, aber ich glaube, dass die Shuhari- Methode die beste für diese Art von Aktion ist. Erstens ( shu ) muss er lernen, was Agilität bedeutet, zweitens ( ha ) muss er seine Version von Agile entwickeln und drittens ( ri ) setzt er seine Reise alleine fort, wird ein Meister und verbreitet das Wort.
Der letzte Schritt erfordert, dass er weiß, wie er mit seinem Verhalten eine Organisation verändern kann . Das Influencer -Buch ist der beste Einstieg. Es beschreibt, wie man etwas durch Verhalten ändern kann. Der PO braucht dieses Wissen, denn ein lustiger Tanz zieht mehr Menschen an als eine ausgefallene, schwer anzupassende Softwareentwicklungsmethodik.
Ich habe einmal mit einem erfolgreichen Projektmanager gesprochen, der die erfolgreichste Organisation in seinem ehemaligen Unternehmen leitete. Er führte Empowerment in seiner Organisation ein. Er lebte mit den Normen, die dafür erforderlich waren, und nach einer Weile tauchten seine Kollegen auf und fragten nach dem Rezept. Und die Veränderung begann zu geschehen. Natürlich folgten nicht alle, aber nach Erreichen der kritischen Masse blieb ihnen nichts anderes übrig . Mir ist bewusst, dass dies keine agile Geschichte ist, aber es geht um die Veränderung, also denke ich, dass es zutrifft.
Normalerweise bevorzuge ich es, Teams rund um Produkte, Zielkunden oder Zielmärkte aufzubauen. In diesem Szenario wäre das Produktmanagement nur ein anderer Teil eines Teams, das auch alle technischen Rollen umfasst. Das dürfte aber nicht machbar sein.
Einige Organisationen, die Sie beschreiben, scheinen eine davon zu sein, sind nach Funktionen organisiert, Produktmanagement in einem Teil der Organisation und Engineering in einem anderen Teil der Organisation. Es gibt verschiedene Techniken, die ich in der Vergangenheit mit unterschiedlichem Erfolg angewendet habe.
Eine Option, die in manchen Fällen funktioniert hat, besteht darin, eine Person im Engineering-Team als Schnittstelle zum Produktmanagement zu haben. Diese Person wäre aus Sicht des Engineering-Teams der Product Owner. Auch wenn das Produktmanagement immer noch alles in großen Stapeln aufschreiben würde, kann der Product Owner es dann für das Team in kleinere Stücke zerlegen. Meine Empfehlung wäre, dem Produktmanagement jedes kleinere Stück nach Fertigstellung zur Verfügung zu stellen und es einzuladen, das Erreichte zu überprüfen und Feedback zu geben.
Die ersten paar dieser "Review"-Meetings können sehr herausfordernd sein. Meiner Erfahrung nach gibt es jedoch immer wieder Mitglieder des Produktmanagements, die den Wert eines frühen Einblicks in den Projektfortschritt entdecken und frühzeitig die Möglichkeit haben, Feedback zu geben. Sobald sie dies als Vorteil sehen, besteht die Chance, dass das Produktmanagement nach mehr drängt. Als Ergebnis haben Sie einen Prozess der schrittweisen Verbesserung hin zu kleineren Anforderungssätzen und einem agileren Prozess gestartet.
bobo2000