Wenn ein Backlog zur Anforderungsdatenbank verkommt und im Fachbereich Prozessentwicklung ohne konkrete Zielvorgaben betrieben wird, wird es schwierig, die richtigen Prioritäten zu setzen oder Wichtiges von Unwichtigem zu unterscheiden. Es bietet sich an, die Pflege bestehender Prozesse und Produkte lassen sich eingebettet in einer Produkt-Roadmap zu steuern.
Das Unternehmen, bei dem ich als Business Change Manager tätig bin, befindet sich in der Agilen Transformation. Während unsere Projekte ihr Denken und Handeln bereits nach agilen Werten und Prinzipien ausgerichtet haben und unsere Informatikabteilung DevOps auf die Fahne geschrieben hat, tut sich der Rest der gesamten Organisation noch schwer, eine nachhaltige Veränderung herbeizuführen.
Run the Business
Im Bemühen, Produkte laufend weiterzuentwickeln und Prozesse zu verschlanken, haben Mitarbeitende aus den Fachbereichen im Verlauf der Zeit alles zusammengetragen, was jemals gebraucht werden könnte. Dieser Rückstand ist keine Warteschlange für ausstehende Leistungen mehr, sondern eine Anforderungsdatenbank. Das macht es schwierig, Prioritäten zu setzen und es stellt sich die Frage, inwieweit einzelne Anforderungen überhaupt noch aktuell sind.
Anforderungen, die aus der Analyse von wiederkehrenden Supportanfragen resultieren, machen es einfacher, den unmittelbaren Nutzen zu bewerten, da sie auf Grundlage von Kunden- und Benutzerfeedbacks entstanden sind. Sie bergen aber die Gefahr, dass sie nur die Symptome nicht aber deren Ursache bekämpfen.
Es zeigte sich nach einigen Gesprächen, dass diese Fachgruppen zwar ermächtigt sind, selbstbestimmt ihr Zuständigkeitsbereich zu formen, doch haben sie für die Umsetzung ihres Auftrags keinen strategischen Rahmen, Leitplanken oder abstrakte Ziele, die sie über einem längeren Zeitraum verfolgen.
Fazit: Auch für Initiativen, welche die laufende Pflege der bestehenden Prozesse und Produkte verfolgen, bedarf es genauso Leitplanken und Zielvorgaben, welche auf die Unternehmens- und Marktstrategie abgestimmt sind.
Fazit: Fachgruppenleiter müssen ihr bisheriges Rollenverständnis ablegen und sich die Fertigkeiten eines Product Owners aneignen.
Nächster Schritt: vom Projekt zum Produkt
Sobald diese Zielvorgaben vorliegen, sollen die Fachgruppen darauf abgestimmt eine Produkt-Roadmap erstellen, für die Produkte und Prozesse, die sie verantworten. Weitere relevante Personen wie beispielsweise Verantwortliche des Produktportfolios, Vertreter anderer Fachgruppen oder Interessenvertreter, werden sie hierbei einbeziehen. Produkt-Roadmaps sind lebendige Dokumente, die sich entwickeln und verändern. Die Beteiligten geben darin zum Ausdruck, wie sie glauben, dass sich das Produkt entwickeln wird auf der Grundlage ihres derzeitigen Marktverständnisses. Abhängig von der Produktlebenszyklusphase und vom Markt ist ein realistischer Planungshorizont auf die nächsten 6 bis 12 Monate zweckmässig.
Fazit: Ein Produkt-Roadmap zeigt auf, wie sich das Produkt entwickeln wird. Es soll die drei bis fünf wichtigsten Funktionen nennen und deren voraussichtliches Einführungsdatum, die Zielkunden und deren Bedürfnisse. Eine Roadmap ermöglicht es dem Unternehmen, die Entwicklung und Einführung verwandter Produkte zu koordinieren, z.B. einer Produktlinie eines Produktportfolios.
Nächster Schritt: Ballast erkennen und eliminieren
In einem weiteren Schritt stellt die Fachgruppe die bestehenden Anforderungen in Bezug zur Produkt-Roadmap und den darin genannten drei bis fünf wichtigsten Funktionen. Nun lässt sich bereits eine klare Aussage darüber treffen, was als Nächstes gemacht werden soll und was zu entsorgen ist.
Fazit: Die Produkt-Roadmap schafft Ordnung. Die Priorität für die Umsetzung der Anforderungen ergibt sich aus der zeitlichen Abfolge, welchen die Produkt-Roadmap vorzeichnet. Ein nun darauf abgestimmte Backlog bietet eine bessere Basis für Entscheide und erleichtert den Dialog zwischen dem Entwicklungsteam und dem Product Owner.
