Agiler Adventskalender: Muss die Fachabteilung jetzt auch lernen agil zu arbeiten?

Agiler Adventskalender: Agiles Arbeiten in der Fachabteilung

Avatar von Björn Schotte

Anforderungen an das Produkt kommen direkt aus dem End2End-verantwortlichen Produktentwicklungsteam, richtig? Nun, in vielen Unternehmen gibt es eine strukturell andere Aufstellung. Ungeachtet der „Richtigkeit“ erreichte uns dazu folgende Frage, auf die wir im 23. Beitrag unseres Agilen Adventskalenders näher eingehen wollen:

Muss die Fachabteilung jetzt auch lernen, agil zu arbeiten?

Die ideale agile Produktentwicklungs-Welt

In der idealen agilen Produktentwicklungs-Welt gibt es End2End-verantwortliche Produktentwicklungs- oder Feature-Teams, die das ganze Produkt oder jeweils Teile davon verantworten. Verantwortung heißt, Product Discovery und Product Delivery (wir berichteten hier an anderer Stelle darüber) gleichzeitig zu übernehmen.

Diese Gleichzeitigkeit ermöglicht es, das richtige Feature zum richtigen Zeitpunkt für die richtige Zielgruppe (Nutzersegmente) zu bauen. Dadurch ergibt sich eine kurze Time-to-Market, kurze Feedback-Zyklen (haben wir das richtige Feature gebaut?) und idealerweise ein positiver ROI (Nachfrage / Bezahlung für das Produkt in kürzerer Zeit).

Dieser Wunsch nach Geschwindigkeit gepaart mit dem Wunsch, „das Richtige“ zu bauen, findet sich auch auf dem Wunschzettel des Managements vieler großer, meist klassisch strukturierter Organisationen.

Die reale Welt in vielen Organisationen

Dort sieht die reale Welt jedoch oftmals anders aus. Während die Softwareentwicklung in agile Teams strukturiert sind, kommen Anforderungen an das Produkt häufig von einzelnen Fachabteilungen. Manchmal gibt es sogar „Innovationsteams“ in den Fachabteilungen, die über viele Monate konzeptionell unterwegs sind (vom LoFi-Prototyping bis hin zu ersten Clickdummies), bevor der Auftrag in die Softwareentwicklung geht.

Die oben skizzierte Gleichzeitigkeit von Discovery & Delivery kann demnach gar nicht stattfinden. Lange Lead Times auf dem Weg von der Idee eines Features bis zur Auslieferung sind somit das Ergebnis. Hinzu kommt, dass Fachabteilungen auf die Geschwindigkeit, mit der Software-Teams liefern können, gar nicht eingestellt sind.

So passiert es also häufig, dass die Fachbereiche mit dem Testen der während der Sprints entwickelten Features nicht hinterherkommen, der Product Owner keine schnellen Feedback-Zyklen mit seinen Stakeholdern (den Fachbereichen) hinbekommt und somit immer mehr Verzögerungen auftreten.

Doch es gibt Abhilfe.

Wie können Fachabteilung und Entwicklung näher zusammenrücken?

Während die einen danach rufen, Silos einzureißen und die Fachabteilungen aufzulösen, gibt es noch weitere Möglichkeiten, wie eine bessere Zusammenarbeit gelingen kann.

Mitarbeiter aus der Fachabteilung verbringen dediziert Zeit mit dem Team

Organisiert Euch so, dass die relevanten Mitarbeiter aus der Fachabteilung eine bestimmte Zeit direkt mit und bei dem Team verbringen. Entweder direkt an der Tischinsel, oder remote in den (Dauer-)Videokonferenzen mit dabei sind und somit Rede & Antwort stehen sowie direkt mitwirken können. Überlegt, ob es feste Tage sein können, die „im Team“ verbracht werden. Als Product Owner solltest Du regelmäßige feste Timeslots mit diesen Mitarbeitern vereinbaren, um gemeinsam an der Product Discovery zu arbeiten.

Mehr Kompetenz in Richtung Product Owner ziehen

Mit dem POEM-Modell gibt es ein Visualisierungs-Werkzeug, um die Verantwortung / Kompetenzen des Product Owners zwischen ihm und dem Rest der Organisation zu visualisieren und mit den Stakeholdern und den Fachabteilungen auszuverhandeln. Über Zeit kann somit mehr Kompetenz direkt zum Product Owner wandern.

Die Fachabteilung zu Verbündeten machen

Hierbei gilt es, organisationale Gräben zu überwinden und Brücken zu schlagen. Als Product Owner, der das Stakeholder-Management gut beherrscht, wirst Du Wege finden, wie Du einzelne Personen aus den Fachabteilungen zu Deinen Verbündeten machen kannst.

Mit dem Herstellen von Augenhöhe, der Integration der Fachabteilung in die Produktentwicklung und dem Angebot, als Unterstützer der Fachabteilung zu dienen, schaffst Du die ersten Voraussetzungen dafür, dass Fachabteilung und Team besser miteinander zusammenarbeiten können. Schließlich ist die Fachabteilung froh, wenn Ihr Arbeit abgenommen und sie dadurch entlastet wird, nicht wahr?

Reviews als gemeinsames Ereignis gestalten

Im Review am Ende der Iteration präsentiert das Team, wie das erreichte Produkt-Inkrement aussieht. Hier besteht die Chance, Feedback einzusammeln und für die weitere Produktentwicklung zu adaptieren.

Oftmals stehen sich zwei Lager gegenüber: Das Management inklusive Fachabteilung (wenn sie denn am Review teilnehmen) sowie das Produktentwicklungsteam (inklusive Product Owner) auf der anderen Seite. Doch das muss nicht so sein: Sorgt dafür, dass die Fachabteilungen an den Reviews teilnehmen. Sprecht sie im Review gezielt auf Feedbacks an. Wenn die Fachabteilung Euer Verbündeter ist: Warum soll sie nicht auch mal im Review durch ein entwickeltes Feature führen und dies demonstrieren?

Sorgt für eine abwechslungsreiche Moderation und eine lockere Gesprächsatmosphäre während des Reviews, ohne dass Lagerbildung entsteht.

Fazit

Wie wir es also drehen und wenden: Die Fachabteilung hat einen entscheidenden Anteil daran, dass die Produktentwicklung nicht nur zügig voran schreitet, sondern auch das richtige Feature zur richtigen Zeit entsteht. Mit einem guten Empowerment des Product Owners, dem Schmieden von Allianzen mit der Fachabteilung, der Übernahme von mehr Verantwortung in Richtung Team (Product Ownership, Testing Ownership und Ähnliches) kann die Fachabteilung einen entscheidenden Beitrag zu einer besseren Produktentwicklung leisten.

Und jetzt?

Wir helfen Product Ownern und Fachabteilungen, das nächste Level von Product Leadership zu erreichen. Mit unserem Training „Become a Product Leader“ besteht vom 23. – 25. Februar 2022 die Gelegenheit, alles zu echter Product Leadership zu lernen. Frühbucher-Tickets gibt es hier.

Nicht nur Organisationen müssen sich modernisieren. Sondern Software-Systeme und digitale Produkte an sich, um wettbewerbsfähig zu sein. Wenn wir Euch auch mit Software-Modernisierung helfen sollen, dann schaut hier mal rein.

[smartblock id=11351]
Avatar von Björn Schotte

Kommentare

Schreibe einen Kommentar

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


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.