Zusammenarbeit

Strategie und Orientierung

Eine Strategie ist erst dann eine Strategie, wenn sie Entscheidungen leitet, die ich nicht selbst treffe. Ich arbeite mit dem Strategy Kernel nach Rumelt, aber nicht nur als Analysewerkzeug: Die Guiding Policy wird zum expliziten Entscheidungsmaßstab, an dem sich auch dezentral entscheiden lässt. Prinzipien gehören dort hinein, Best Practices nicht. Unternehmens-, Produkt- und Transformationsstrategie müssen dabei nicht identisch sein, aber sie müssen zusammenpassen.

Schwierig wird diese Arbeit, wenn ein Unternehmen unter wirtschaftlichem Druck steht, denn sie zahlt zunächst nicht unmittelbar in die Wertschöpfung ein. Bei iterativem Vorgehen ändert sich das früher als erwartet: Die gemeinsamen Entscheidungen werden schon besser, bevor die Strategie fertig ist.

Organisation und Führung

Strukturen entscheiden darüber, welche Informationen Menschen erreichen, mit wem sie zusammenarbeiten und wie unmittelbar sie die Wirkung ihrer Arbeit erleben. Ich schneide Organisationen entlang des Kundennutzens statt entlang der Technik und entkopple Struktur und Architektur, damit beide beweglich bleiben. Dazu gehört die bewusste Trennung von fachlicher Produktverantwortung und disziplinarischer Führung, mit gleichwertigen Entwicklungswegen und gleichen Karrierechancen. Und die Frage, wer eigentlich was entscheidet: Der Kontext bestimmt, wer entscheidet, die benötigte Wissensbreite bestimmt, wer beitragen sollte.

Am häufigsten scheitert die Trennung dort, wo der Product Owner die fachliche Führung formal hat, aber nicht wirklich. Fachbereiche oder Linienvorgesetzte stellen Priorisierungen immer wieder in Frage, halten an Meilensteinen fest oder verlangen vorab fixe Budgets. Der Product Owner verliert seine Wirksamkeit, ohne die Verantwortung abgeben zu können. Ich habe mehrfach erlebt, dass Menschen in dieser Rolle ausbrennen und kündigen.

Der Kern des Konflikts ist eine Position, die es in Organigrammen nicht gibt: nach oben Wasserfall bedienen, nach unten Agilität ermöglichen. Wer dort sitzt, braucht Kompetenz in beiden Welten. Die meisten bringen nur eine mit, und das ist keine persönliche Schwäche, sondern eine strukturelle Überforderung. Aus dieser Notlage ist meine Backlog-Visualisierung entstanden. Sie übersetzt zwischen beiden Welten, indem sie Prognosen liefert, mit denen die eine Seite planen kann, ohne dass die andere Seite ihre Arbeitsweise aufgeben muss.

Backlog-Visualisierung

Produktentwicklung und professionelle Exzellenz

Discovery und Delivery sind ein gemeinsames System, und die technischen Voraussetzungen entscheiden mit, ob es funktioniert. Ein Schwerpunkt liegt darauf, aus einem komplexen fachlichen Zusammenhang einen kleinen durchgängigen Anwendungsfall herauszuschneiden, verbunden mit konkreten Beispielen als Akzeptanzkriterien. Damit das trägt, braucht es Continuous Integration, automatisierte Tests und inkrementelles Design. Continuous Integration verstehe ich dabei als Arbeitsprinzip und nicht als Werkzeugkette: Man kann auf isolierten Branches technisch exzellent arbeiten und trotzdem die Integration des Produkts verhindern.

Dazu gehört die Rückkopplung vom Product Backlog in die Roadmap und weiter in die Strategie, damit Planung sich an dem ausrichtet, was tatsächlich geliefert wird. Für Prognosen nutze ich Wasserstandslinien, statistische Bandbreiten und Trends. Schätzungen sind dabei willkommen, aber auf Item-Ebene und zu dem Zeitpunkt, an dem das Team die Aufgabe versteht. In sehr großen Organisationen arbeite ich meist ohne, weil Teams unterschiedlich schätzen. Für die Prognose macht das kaum einen Unterschied, weil Flow und verbleibende Backlog-Größe in derselben Einheit gemessen werden.

Der wichtigere Nutzen der Visualisierung ist dabei nicht die Prognose. Wer Flow sieht, erkennt, wodurch er entsteht, und schneidet Anforderungen anders, nämlich stärker von Ende zu Ende. Dadurch wird nicht nur die Vorhersage besser. Die Organisation verändert sich und wird berechenbarer.

Dieser Ansatz kann eigentlich nicht scheitern, denn er macht nur sichtbar. Die Frage ist, was eine Organisation mit der Transparenz anfängt. Wer den Flow sieht und nichts ändert, hat ein besseres Reporting und sonst nichts. Der Nutzen entsteht erst, wenn aus dem Gesehenen andere Entscheidungen folgen.

KI in Organisation und Produktentwicklung

Künstliche Intelligenz wirkt quer durch alle anderen Felder, von Strategie über Zusammenarbeit bis in die Implementierung. Der häufigste Fehler ist dabei nicht technisch: Wenn ein einzelner Mensch ein KI-Ergebnis beurteilt, bleibt die kollektive Intelligenz der Organisation ungenutzt. Ich arbeite mit KI-Agenten über zusammenhängende Aufgaben hinweg und kann deshalb aus eigener Praxis sagen, was sich an Rollen, Qualitätssicherung und Verantwortung tatsächlich verschiebt.

Aus dieser Arbeit ist ein Kollaborationsguide mit über zwanzig konkreten Anleitungen entstanden. Die Erfahrungen daraus habe ich in einem Vortrag bei einem Automobilhersteller zusammengefasst. Die organisationalen Auswirkungen einer KI-Transformation begleite ich als Querschnittsthema: Welche Fähigkeiten werden gebraucht, wie verändern sich Rollen und Verantwortungsbereiche, und welche Feedback- und Qualitätssysteme sichern Ergebnisse ab, wenn deutlich schneller deutlich mehr entsteht.