7 Agile Praktiken, die Sie in einer kontrollierten Umgebung anwenden können

Ihre Teams wollen also agil arbeiten, vielleicht haben sie sogar damit begonnen. Jetzt fragen sich Ihre Projektmanager, was Story Points sind und warum eine beliebige Anzahl von Personen ihrem Projektcode Stunden zuzuschreiben scheint. Die Frage ist also: Was können Sie einfach übernehmen, ohne die Governance Ihres Unternehmens auf den Kopf zu stellen?

[caption id="attachment_19380" align="aligncenter" width="680"] Prince2 kann Ihre Beweglichkeit stark einschränken, aber das ist kein Grund, mit dem Lächeln aufzuhören[/caption]

Ist das eine ideale agile Arbeitsweise? Nein, aber es ist ein guter erster Schritt, den Sie machen können, ohne die Umgebung zu sehr zu frustrieren. Das wird die weiteren Schritte erleichtern.

Wenn Sie eher der audiovisuelle Typ sind, sollten Sie sich das Video ansehen, das ich zu diesem Thema gemacht habe.

[embed]https://www.youtube.com/watch?v=jD5mdQRQACM[/embed]

Sie können sich auch die niederländische Version HIER ansehen. Ohne weitere Umschweife, hier sind die 7 agilen Praktiken, die Sie in einer prozessorientierten (z.B. Prince2) Umgebung übernehmen können und sollten.

1.) Holen Sie die richtigen Leute in den Bus Die Rolle des Product Owner ist in Scrum von größter Bedeutung. Die Zentralisierung der geschäftlichen Anforderungen und die ständige Interaktion zwischen denjenigen, die etwas schaffen können, und denjenigen, die wissen, welches Problem es zu lösen gilt, ist der Schlüssel zum Erfolg. In vielen Organisationen ist dies jedoch schwer zu erreichen.

Der Senior User, wie der Problemverantwortliche in Prince2 genannt wird, befindet sich normalerweise außer Sichtweite, irgendwo in einem Lenkungsausschuss und wird vom Projektmanager vertreten. Dies ist jedoch nicht zwingend erforderlich. Anstelle eines Senior Users oder Business Project Managers: sprechen Sie über einen Business Product Owner.

Wenn man von Produkten und nicht von Projekten spricht, ist es einfacher, über langfristige Auswirkungen nachzudenken, als über die Entwicklung und Übergabe. Der Zusatz "Business" unterstreicht zusätzlich, dass ein Product Owner das Geschäft wirklich "besitzen" sollte.

2.) Besorgen Sie sich einen richtigen Leitfaden Es ist nicht einfach, in einem Unternehmen etwas aufzubauen. Ich habe die Rolle des Customer Journey Expert eingeführt, um zu verhindern, dass die Vorstellung verwässert wird, wem das Produkt gehört. Der Customer Journey Expert sorgt dafür, dass der Business Product Owner den Prozess und die agilen Regeln einhält, damit er nicht auf den IT-Projektmanager zurückgreift, um seine Botschaft zu vermitteln.

Diese Leute kennen sich auch gut mit der Erstellung von User Stories aus, so dass sie in der Regel bei deren Erstellung helfen und Tools wie Jira usw. verwalten, um sicherzustellen, dass alles an einem Ort ist.

3.) Projektinitialisierungsdokumente müssen eine Story Map enthalten Projektinitialisierungsdokumente regeln alles außer dem Umfang, und im agilen Kontext ist der Umfang wahrscheinlich das erste, was aus dem Fenster fliegt. Warum also nicht damit beginnen, zu erklären, welcher Teil des Umfangs wichtiger ist als andere.

Dies hat tiefgreifende Auswirkungen. Zum Beispiel ändert sich die Definition des Begriffs "Produkt"! In Prince2 werden alle Artefakte, die ein Projekt produziert, als Produkte bezeichnet, aber die Story Map zwingt uns, über den Wert für den Endbenutzer nachzudenken. Wir unterscheiden also zwischen Prozessdokumenten (Entwürfen, Berichten, Berechnungen usw.), die wir benötigen, um einen Mehrwert für den Endbenutzer zu schaffen, und dem eigentlichen Produkt, das das Problem des Endbenutzers löst.

Die Prozessdokumentation kann als der Standard bezeichnet werden, den Sie verwenden. Es besteht keine Notwendigkeit, sie zu wiederholen, es sei denn, Sie weichen vom Standard ab. Es handelt sich um einen Projektplan, nicht um ein Referenzdokument. Aber der Wert für den Endbenutzer liegt in den "auslieferbaren Inkrementen".

...die zuverlässigste Form der Selbstvermarktung ist es, eine lange Geschichte atemberaubend guter Arbeit zu haben, die verschickt wird. - Seth Godin

Aus Projektmeilensteinen sind jetzt "versendbare" Inkremente geworden! Wir führen nicht mehr die Diskussion am Ende des Budgets: "Wann wird alles fertig sein?", sondern sie wird zu "War das letzte Inkrement gut genug? "War das letzte Inkrement gut genug".

4.) Verwenden Sie die relative Größenordnung Größe der Projekte relativ zueinander. Sowohl hinsichtlich der Auswirkungen auf den Benutzer als auch hinsichtlich der Komplexität der Erstellung. Sie können dies tun, indem Sie neue Projekte mit Projekten vergleichen, die Sie in der Vergangenheit durchgeführt haben. Die Erstellung von Business Cases kann eine komplexe Aufgabe sein, und all die Variablen führen zu mehr Unsicherheit, wenn Sie Projektionen für mehrere Monate oder sogar mehrere Jahre erstellen. In der Praxis bedeutet dies: Das Risiko und die Ungewissheit aus einer absoluten Planung zu entfernen, um genauer als relative Schätzungen zu werden, überwiegt die Kosten.

Wenn also die Benutzer von Funktion A doppelt so begeistert sind wie von Funktion B, haben Sie eine gute Einschätzung des Wertes, den diese Funktionen bringen. Wenn Sie eine ähnliche Übung zur Komplexität durchführen, haben Sie einen sehr guten Ausgangspunkt für die Priorisierung Ihrer Projekte.

5.) Überprüfen Sie die Priorität regelmäßig Wir haben also die anfängliche Priorität festgelegt und dabei das Project Delivery Board beachtet, wissen aber auch, dass alles immer im Fluss ist. Daher treffen sich die Business Product Owner regelmäßig, um die Priorität auf der Grundlage des aktuellen Inkrements, an dem die Teams arbeiten, neu zu bewerten.

Sie vergleichen jetzt also die Priorität von Schritt 4 von Projekt A und Schritt 8 von Projekt B. Da die Produktentwicklung dem Gesetz des abnehmenden Ertrags folgt, werden wir irgendwann immer weniger Wert für den Endverbraucher pro Arbeitseinheit schaffen. Analog zum Judo: Wenn das Spiel fast zu Ende ist und Sie sich verheddert haben, wird es viel mehr Mühe kosten, etwas zu bewirken, als zu Beginn des Spiels. Vermeiden Sie das also (und seien Sie beim Judo nicht auf der Empfängerseite).

Wir haben dieses Alignement Meeting wöchentlich. Hier besprechen wir die vom Project Delivery Board und Project Management Office (Resourcing) festgelegte Aufteilung. In dieser Sitzung hören wir uns die Probleme an, die die anderen Projekte zu lösen versuchen, und welche Auswirkungen ihre nächste Version haben wird. Dies hilft uns bei der Festlegung der mittelfristigen Prioritäten und der Anpassung. (Kommunikation und Einfühlungsvermögen für das jeweils andere Projekt sind ein schöner Bonus!)

Benötigen Sie Hilfe bei der Einrichtung des Projektabgleichs auf agile Weise? In diesem Buch finden Sie eine ausführliche Beschreibung, wie Sie mehrere Teams, die an mehreren Produkten arbeiten, auf agile Weise abstimmen können.

6.) Holen Sie sich frühes Feedback Das Geheimnis von Agile ist frühes Benutzerfeedback. Es ist also das Privileg des Business Product Owners , die Benutzer, die er vertritt, zu versammeln und sicherzustellen, dass sie über alles, was das Team liefert, informiert werden. Gute Agile-Teams werden etwas Wertvolles und "potenziell Auslieferbares" liefern. Der Customer Journey-Experte kann dabei helfen, die gelieferte Funktionalität so zu gestalten, dass sie für die Rückmeldung geeignet ist.

Ich habe z.B. einmal mit einem Team zusammengearbeitet, das eine hochentwickelte Suchmaschine entwickelt hat. Anstatt nur an komplexen Algorithmen zu arbeiten, schuf das Team eine einfache und hässliche (sonst würde das Marketing in die Produktion gehen) Benutzeroberfläche, mit der wir den Benutzern demonstrieren konnten, wie die Suche funktionieren würde. Bei jeder einzelnen Demonstration erfuhren wir etwas Neues darüber, wie das Produkt von echten Menschen genutzt werden würde, und die Benutzer bekamen Verständnis für die (in ihren Augen) ewig dauernde mystische Arbeit, die wir leisteten. Feedback mit den Benutzern ist eine zweiseitige Straße: Es schafft Vertrauen in beide Richtungen. 7.) Vergessen Sie nicht die Umgebung Die Samurai waren darauf trainiert, sich ihrer Umgebung jederzeit bewusst zu sein. Wenn Sie sich im Kampf mit einem Gegner befinden, kann sich sein Freund von hinten an Sie heranmachen. Nun glaube ich nicht, dass Ihre Kollegen kriegerische Absichten haben (zumindest hoffe ich das), aber wenn Sie die Umgebung nicht so handhaben, wie sie es erwarten, wird das tödliche Folgen für Ihr Projekt haben.

Das bedeutet: Seien Sie klug mit Ihrer Berichterstattung. Der Lenkungsausschuss erwartet immer noch die regelmäßigen Berichte, aber Sie können mit dem Inhalt spielen, Burndown-Diagramme, Fotos von Demos, Whiteboard-Sitzungen usw. einbauen. Der Zweck der Berichte ist es, ein Gefühl dafür zu bekommen, ob das Projekt auf dem richtigen Weg ist, um Werte zu liefern. Agile Projekte können dies schon viel früher zeigen. Das einzige Risiko besteht darin, dass der Lenkungsausschuss feststellt, dass Ihr Projekt seinen optimalen Wert vor dem Ende des Plans erreicht hat und es stoppt. Aber eigentlich würde das bedeuten, dass sie die agile Denkweise angenommen haben und Sie auf dem Weg zu einer vollständigen agilen Transformation sind.

Die Finanzberichterstattung ist wichtig, da sie den Cashflow regelt. Wenn Sie zu viel Geld ausgeben, könnten andere Projekte Schwierigkeiten haben, finanziert zu werden. Jetzt gibt es einen Haken: Wenn Ihre Organisation zu viel Wert auf Kontrolle legt, haben Sie vielleicht viele kleine Projekte, was zu mehreren Projekten pro Team führt. Der Mechanismus der Finanzberichterstattung betrachtet die Stunden, nicht den Wert. Das bedeutet, dass es wichtig ist, zu wissen, wie viel Geld von wem wofür ausgegeben wird. Dies wird zu vielen Überraschungen führen, da die Vorhersagbarkeit für die Teammitglieder wahrscheinlich zugunsten einer höheren Vorhersagbarkeit des Teams verringert wird.

Die Symptome sind große Schwankungen bei den pro Woche/Monat/Sprint aufgewendeten Stunden. Das führt zu Verwirrung und einem Projektrisiko aufgrund unruhiger Kontrolleure. Die Lösung besteht darin, Projekte zu einer vernünftigen Größe zu gruppieren. Jetzt wird die erhöhte Vorhersehbarkeit des agilen Prozesses zu Ihrem Vorteil sein! Außerdem werden die Teams ihre Anstrengungen auf ein einziges großes Projekt konzentrieren, anstatt auf ein halbes Dutzend kleiner Projekte. Wenn Sie Projekte aufgrund interner Regeln nicht zusammenlegen können: Führen Sie das Konzept eines Programms ein.

Zurück zu meinem Eingangsbild: Agilität funktioniert nicht, wenn Sie sich in einem Haltegriff verfangen haben, also schaffen Sie etwas Platz und lächeln Sie!

---

Möchten Sie mehr über den Einsatz von Kampfsportarten im Produktmanagement erfahren? Bestellen Sie das Buch bei bol.com, wenn Sie in den Niederlanden oder Belgien leben, oder melden Sie sich an, um die internationale Ausgabe zu erhalten.