FrankSazamaEine persönliche Reflexion über Erfahrungen, Prinzipien und Praktiken im agilen Automotive-Umfeld
Wenn ich heute auf meine Arbeit mit agilen Teams, Chief Product Ownern, Train-Architekten oder Solution Managern schaue, dann begegnet mir immer wieder ein zentrales Thema: der Wunsch, Dinge wirklich auf die Straße zu bringen – nicht nur in Form von abgeschlossenen Tasks, sondern als wirksame Ergebnisse, die das große Ganze voranbringen.
Doch in der Realität sehen wir oft ein anderes Bild: Teams liefern, doch das „Was“ und „Wozu“ bleibt diffus. Feature-Backlogs wachsen, Stakeholder verlieren den Überblick, Prioritäten werden gefühlt statt fundiert gesetzt. Es herrscht Unsicherheit – darüber, ob das, was wir tun, überhaupt das ist, was am meisten gebraucht wird.
Diese Herausforderungen kennen wir alle. Und genau deshalb möchte ich meine Erfahrung teilen, wie es besser gelingen kann. Wie wir es schaffen, als agile Organisation nicht nur produktiv, sondern wirklich wirksam zu sein. Dafür braucht es meiner Meinung nach nicht mehr Tools, sondern mehr Verbindung zwischen den Ebenen. Es braucht vertikale Zusammenarbeit.
Vom Task zur Lösung – eine Frage des Maßstabs
Wenn wir über Zusammenarbeit sprechen, denken viele zuerst an die Team-Ebene. PO, Scrum Master, Entwickler*innen – sie synchronisieren sich täglich, schätzen gemeinsam Stories, planen in zweiwöchentlichen Sprints. Das ist gut und wichtig – aber es ist nur ein Teil des Ganzen.
Denn schon die nächste Ebene – der Agile Release Train – bringt eine neue Dimension ins Spiel: Features statt Stories, mehrere Teams, längere Planungshorizonte. Noch eine Stufe höher denken wir in Capabilities, Architekturroadmaps, Produktstrategien. Und hier beginnt oft das Problem: Jede Ebene agiert in ihrer eigenen Logik – aber selten miteinander.
Was ich in der Praxis erlebe: PO, CPO und Solution Manager nutzen unterschiedliche Sprache, haben unterschiedliche Ziele und oft auch unterschiedliche Zeitfenster im Kopf. Das Resultat: Verzögerungen, Missverständnisse und Reibungsverluste.
Die Lösung liegt für mich nicht in einem zentralistischen Steuerungssystem – sondern in einem gemeinsamen Betriebssystem, das von der Team- bis zur Unternehmensebene reicht. Ein Betriebssystem, das auf geteiltem Verständnis, klarer Verantwortung und transparenten Mechanismen basiert.
Die Rollen entlang der Wertschöpfungskette – verbunden durch Verantwortung
Eine zentrale Erkenntnis: Auch wenn PO, CPO und Solution Manager in verschiedenen Kontexten wirken, verbindet sie eine gemeinsame Aufgabe: den Weg von der Idee zum Kundenwert so effizient und wirksam wie möglich zu gestalten.
- Der Product Owner arbeitet mit Stories und denkt in Tagen bis Wochen.
- Der Chief Product Owner verantwortet Features, koordiniert Abhängigkeiten zwischen Teams und denkt in Monaten.
- Der Solution Manager denkt in Capabilities, Geschäftsmodellen und strategischen Roadmaps – sein Blick reicht oft über Jahre.
Was sie unterscheidet, ist der Maßstab – was sie verbindet, ist das Ziel.
Doch dieses Ziel erreichen wir nur dann, wenn diese Rollen nicht isoliert agieren, sondern in einem kontinuierlichen Dialog stehen. Wenn sie Verantwortung nicht weiterreichen, sondern gemeinsam tragen. Und wenn sie den Mut haben, nicht nur ihre eigenen Prioritäten zu vertreten, sondern das Ganze im Blick zu behalten.
Backlogs sind keine To-do-Listen – sie sind Spiegel unserer Produktstrategie
Was mich dabei besonders umtreibt: In vielen Organisationen sind Backlogs zu Ablageplätzen für Anforderungen geworden. Hier ein Stakeholder-Wunsch, dort eine Kundenmeldung, zwischendrin technische Schulden. Alles wird gesammelt – aber selten strategisch priorisiert.
Ein Backlog sollte kein Wühltisch sein, sondern ein Strategieinstrument.
Dafür braucht es klare Priorisierungskriterien. Ich arbeite hier gern mit einer Kombination aus zwei Modellen:
- MoSCoW – weil es einfach ist, schnell anwendbar und ein gemeinsames Verständnis schafft.
- WSJF (Weighted Shortest Job First) – weil es hilft, objektiv zu bewerten, was den größten Nutzen bei kleinstem Aufwand liefert.
WSJF zwingt uns, die Wertdimensionen explizit zu machen:
- Welchen Business Value bringt ein Feature wirklich?
- Wie zeitkritisch ist es?
- Welche Risiken verringert oder Chancen eröffnet es?
- Und wie aufwändig ist die Umsetzung?
So wird Priorisierung vom Bauchgefühl zur fundierten Entscheidung – und das ist entscheidend, wenn Ressourcen knapp und Anforderungen vielfältig sind.
Rhythmus statt Aktionismus – der Wert vertikaler Synchronisation
Ein weiterer zentraler Erfolgsfaktor ist für mich der gemeinsame Rhythmus über die Ebenen hinweg.
Teams arbeiten im Sprint-Rhythmus – aber wie oft sprechen CPOs mit POs? Wie regelmäßig stimmt sich der Solution Manager mit den Trains ab? Wie eng sind Business Owner in Priorisierungen involviert?
Was ich empfehle, ist eine Struktur aus regelmäßigen Touchpoints:
- Backlog Refinements auf allen Ebenen – nicht als Event, sondern als kontinuierlicher Prozess.
- Vertikale Reviews, in denen nicht nur Teams, sondern ganze ARTs zeigen, was entstanden ist.
- Synchronisations-Calls, in denen Impediments, Risiken und strategische Entscheidungen diskutiert werden.
Ich nenne das: vertikale Transparenz. Sie schafft Vertrauen, fördert Entscheidungen und verhindert blinden Aktionismus.
Stakeholdervielfalt ernst nehmen – auch intern
Oft wird übersehen: Unsere Stakeholder sind nicht nur Kunden und Nutzer. Es sind auch unsere Architekt*innen, Testverantwortlichen, Security-Experten oder Betriebsverantwortlichen. Sie bringen wichtige nicht-funktionale Anforderungen ein – und auch sie müssen gehört und priorisiert werden.
Ebenso wichtig sind Enablement-Themen – Tools, Infrastruktur, Schulungen. Sie zahlen auf die langfristige Leistungsfähigkeit ein, stehen aber selten „oben“ auf der Liste.
Hier braucht es eine bewusste Entscheidung: Auch diese Themen gehören ins Backlog – mit klarer Sichtbarkeit und systematischer Priorisierung.
Was „Get the Things Done“ für mich wirklich bedeutet
Viele verstehen unter „Getting Things Done“ das effiziente Abarbeiten von Aufgaben. Für mich bedeutet es etwas anderes:
Die richtigen Dinge zu tun – zum richtigen Zeitpunkt, mit der richtigen Unterstützung.
Dazu gehört:
- Den Kundenwert zu verstehen – und nicht nur zu vermuten.
- Den Kontext zu erfassen – sowohl technisch als auch organisatorisch.
- Die Zusammenarbeit so zu gestalten, dass sie nicht von Prozessen, sondern von Verantwortung getragen wird.
- Und Feedbackzyklen zu schaffen, die nicht nur Fehler aufdecken, sondern Lernen ermöglichen.
Am Ende geht es darum, aus agiler Methodik ein wirksames Betriebssystem für Produktentwicklung zu machen. Ein Betriebssystem, das Silos überwindet, Lernen ermöglicht und Wert schafft – auf jeder Ebene.
Mein Appell: Zusammenarbeit ist kein Buzzword – sie ist der Kern agiler Wirksamkeit
Wenn ich einen Wunsch hätte, dann diesen:
Lasst uns wieder mehr miteinander arbeiten – nicht nur nebeneinander.
Lasst uns Backlogs als strategische Werkzeuge begreifen. Lasst uns über Ebenen hinweg Verantwortung übernehmen. Lasst uns unsere Systeme so bauen, dass sie Klarheit ermöglichen – für uns, für unsere Kunden, für unsere Unternehmen.
Denn nur dann wird aus „Doing Agile“ wirklich „Being Agile“.