Agiles Roadmapping mit Produkt-Routen

2 Kommentare

„Routenplaner (Streckenplaner, Wegplaner, von französisch: route = Weg) sind Computerprogramme, mit deren Hilfe ein Weg zwischen einem Start- und einem Zielort gefunden werden kann. Meistens können auch ein oder mehrere Orte dazwischen („via“) angegeben werden. Es können meistens Wünsche angegeben werden, ob die schnellste, die kürzeste, die wirtschaftlichste (ökonomischste) oder manchmal auch die schönste Route gesucht werden soll.“ (Wikipedia)

Das Bedürfnis nach (Planungs-)Sicherheit ist ein häufig auftretendes Phänomen bei Softwareprojekten. Erst an zweiter Stelle steht das Bedürfnis, etwas Nützliches und Relevantes liefern zu können. Das ist zunächst verwirrend: Sind agile Methoden nicht genau deswegen überhaupt erst eingeführt worden? Weil es eben keine Sicherheit gibt und wir uns daher lieber darauf konzentrieren, sicherzustellen, dass wir immer das Nützlichste und Relevanteste entwickeln?

Wenn es diese Sicherheit gäbe und wir genau vorhersagen könnten, wann wir welchen Umfang liefern können, wären agile Entwicklungsmethoden überflüssig. Warum sollte man also annehmen, man könne die Komplexität von Softwareprojekten planerisch in den Griff bekommen – speziell, wenn alle Studien und Fallbeispiele das Gegenteil beweisen?

Häufig kommen wir in Projekte, in denen die Planungsphase bereits abgeschlossen ist und wir das Ziel hinnehmen müssen, wie es ist. Leider sind diese Pläne meist schlecht. Die Tatsache, dass der Plan bereits geschmiedet ist, sollte aber keine Entschuldigung für uns sein, sie nicht in Frage zu stellen (auch wenn der Kunde das vielleicht lieber hätte). Wenn wir nicht hinterfragen, welche Ziele und Werte hinter dem Plan stehen, was das Ergebnis sein soll, wie eine Veränderung der Verhaltensweise der Kunden (und manchmal auch des Unternehmens) herbeigeführt werden soll, wenn wir nicht lineare Backlogs und unmessbare User Stories kritisieren, dann werden wir unserer Rolle als Berater nicht gerecht. Vielleicht gibt es ja die Chance, dass der Kunde versteht, worum es bei Agilität geht, statt in eine weitere Kostenfalle zu tappen.

Wie können wir Dinge ändern, die ganz offensichtlich schlecht sind oder nachweislich unpassend oder gar falsch, wenn wir nicht aktiv dagegen argumentieren und dafür andere, bessere Wege aufzeigen?

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. (Agile Manifesto)

Wenn Scheitern zum Standard wird

Man könnte jetzt dem Kunden erklären, dass er einige „schlechte Angewohnheiten“ hat und wir ihm helfen können, diese zu überwinden. Dummerweise hören Kunden nur ungern von externen Beratern oder Entwicklungsteams, dass alles, was sie die letzten 30 Jahre gemacht haben, vollkommen falsch war und dass sie endlich Transparenz und Vertrauen und andere agile Werte fördern sollten. Man darf auch nicht vergessen, dass diese Unternehmen 30 Jahre lang erfolgreich im Geschäft sind und immerhin den Mut haben, sich trotz dieser offensichtlichen Reife Hilfe von außen zu holen!

Trotzdem ist es besser, die Tatsache, dass es keine Sicherheit gibt, zu akzeptieren statt sie zu verleugnen und hinterher überrascht zu sein, wenn das Projekt fehlschlägt. Aber auch wenn es keine Sicherheit gibt, das Bedürfnis nach Sicherheit existiert in jedem Fall. So kommt es, dass in einigen Firmen schon so lange Projektfehlschläge (in Bezug auf den ursprünglichen Plan) passieren, dass jeder es vorher weiß, obwohl es keiner auszusprechen wagt.

Am Ende ist in solchen Firmen keiner überrascht, weil ja jeder damit gerechnet hat, dass das Projekt fehlschlägt und weil es ein „ganz normaler“ Prozess ist, der keinen Grund zur Beunruhigung gibt. Man ist es eben gewohnt, „betrogen“ zu werden. Manchmal wird dies auch ganz gezielt zur Diskreditierung von Personen eingesetzt. Dann rollt eben am Ende des Projektes ein Kopf, und man setzt einen neuen Projektleiter ein, den man sowieso viel besser leiden kann als den Querkopf, der das Projekt im Moment leitet.

Der Ausweg: volle Transparenz

Unser Vorschlag für einen Ausweg aus diesem Dilemma ist, dass wir das Akzeptieren des Bedürfnisses unserer Kunden nach Sicherheit über unser eigenes Bedürfnis stellen, ihm den Umgang mit Komplexität beibringen zu wollen – etwa so, wie wir dem agilen Wert folgen, das

Christian ist seit mehr als 15 Jahren Produktmanager für Softwareanwendungen aus verschiedenen Branchen und Agilist aus Leidenschaft. Er ist Experte für große Unternehmensstrukturen und komplexe Projekte und Verfechter von Wertschöpfungsgedanken und Customer-First-Attitude. Christian führt unsere Kunden durch das gesamte codecentric-Portfolio, von der Ideengenerierung bis zum Betrieb der fertigen Lösung als partnerschaftlicher Begleiter.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Artikel von Christian Prison

Product Routes (AKA „Roadmaps“)

Kommentare

  • Gero Seifert

    19. Mai 2017 von Gero Seifert

    Deine GPS-/Navi-Metapher finde ich hilfreich. Die Dimension „Transparenz“ hast du angesprochen, aber noch nicht weiter beleuchtet. Um in deiner Metapher zu bleiben: In den meisten unserer gewünscht agilen Projekte kennen wir leider die Verkehrslage und unsere Fahrzeug-Parameter mehr schlecht als recht.
    Meiner Erfahrung nach entsteht die Bereitschaft Pläne anzupassen zusammen mit dem Wunsch nach Agilität. Richtig schwierig wird es erst, wenn du die dazu erforderliche Transparenz schaffen willst. (Vgl. Weinberg’s Second Law Of Consulting: „No matter how it looks at first, it’s always a people problem.“)
    In diesem Sinne würde ich deiner 8-Punkte Zusammenfassung folgenden Punkt hinzufügen:
    (+) Mache sichtbar, in welchem Zustand sich dein Fahrzeug befindet und wer sich auf deiner geplanten Route noch alles drängelt.

  • Sash

    21. Mai 2017 von Sash

    Danke, endlich in Worte gefasst, was zu sagen ist! 👍🏻

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.