Monate: Juni 2018

Das Team, das Produkt und der ganze Rest

Rund um Agilität gibt es ein grundlegendes Missverständnis. Dieses Missverständnis beginnt im Titel des Manifests für agile Softwareentwicklung. Unter Softwareentwicklung verstanden viele über zu lange Zeit das Übersetzen von Spezifikationen in Code durch austauschbare Programmierer, die dadurch (und oft verstärkt durch Vertragsverhältnisse) komplett den Kontakt zu ihren Kunden und ihrem Produkt verloren hatten. Und viele verstehen unter Softwareentwicklung genau das heute noch. Nur in kürzeren Zyklen. Agil eben. Den Autoren des Manifests, die allesamt leidenschaftliche Softwareentwickler waren, ging es aber um etwas anderes. Ihnen ging es darum, die Softwareentwicklung wieder als Zentrum der Wertschöpfung zu begreifen und die ganze in schwergewichtige Prozesse gegossene und in Organisationsstrukturen erstarrte Verschwendung um dieses Zentrum herum zu eliminieren. Es ging ihnen darum, als langlebiges Team in gemeinsamer Verantwortung erfolgreiche Produkte zu entwickeln. Und dazu darf es keine Mittelsmänner zwischen Team und Kunden mit entsprechenden Artefakten und Übergaben geben. Stattdessen müssen Fachexperten und Entwickler täglich zusammenarbeiten, um den Markt, das Produkt und den Lösungsraum gemeinsam zu erforschen.

Das Anti-Pattern der Kunden-Lieferanten-Beziehung

Einer der vier Hauptsätze des Manifests für agile Softwareentwicklung lautet „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.“ Und in den Prinzipen hinter dem Manifest heißt es weiter „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ Dieser Begriff des Kunden führt leider bis heute oftmals du dem was Jeff Patton als Kunden-Lieferanten-Anti-Pattern bezeichnet. Gerade in großen Organisationen mit eigenen IT-Abteilungen tritt dieses Muster auf, wenn der Product-Owner seine Rolle als Vertreter der internen Kunden begreift und Anforderungen an das Development-Team zur Umsetzung gibt. Die Kunden und ihre Nöte und Bedürfnisse zu verstehen ist wichtig, ist aber nur ein Aspekt, um ein Produkt erfolgreich zu machen und genau das ist die Aufgabe des Product-Owners. Um alle Aspekte abzudecken, darf der Product-Owner nicht genialer und einsamer Entscheider sein und sich nicht einseitig dem Business zugehörig fühlen, sondern mehr Anführer eines Expertenteams, das gemeinsam die Verantwortung für die nachhaltige Entwicklung des Produkterfolgs übernimmt.

Agilität Orientierung geben: Strategie als leerer Handlungsrahmen

Bei Agilität denken die meisten an Kanban oder Scrum auf Ebene der Teams. Und dann natürlich an die vielen Skalierungs-Frameworks wie LeSS, SAFe, DAD oder Nexus. In erster Linie adressieren diese Frameworks die Frage, wie die Arbeit von mehreren oder vielen Teams an einem oder mehreren Produkten koordiniert und synchronisiert werden kann. Gerade in gewachsenen IT-Landschaften mit vielen Abhängigkeiten eine berechtigte und oft gestellte Frage, die leider oft die viel wichtigere Frage nach der Entkopplung verdrängt, aber das ist eine andere Geschichte. Hier soll es nun eher um die Frage gehen, wie man agilen Organisationen auf verschiedenen Flughöhen mit entsprechenden Planungshorizonten Orientierung geben kann. Und darum, dass dabei Strategie immer ein leerer Handlungsrahmen bleiben muss der von unten nach oben mit Inhalt gefüllt wird.

Die agile Transformation in der Sackgasse

Wer Spotify kopiert oder irgendeine andere Blaupause einer agilen Organisation einfach umsetzt macht einen grundsätzlichen Fehler. Nicht weil die Modelle schlecht wären, sondern weil die von oben angeordnete Umsetzung eines von wenigen Managern, Experten oder Beratern ausgewählten oder erdachten Modells einer agilen Organisation dem ganz wesentlichen Prinzip der Selbstorganisation widerspricht. Modelle agiler Organisationen sind prinzipiell emergent in dem Sinne, dass sie aus der Zusammenarbeit von selbstorganisierten Teams in Richtung einer gemeinsamen Vision entstehen und sich ständig weiterentwickeln. Darum ist es entscheidend für eine nachhaltige agile Transformation, den Druck kurzfristige Erfolge zu liefern auszuhalten und den Menschen empathisch und vertrauensvoll den Raum und die Zeit zu geben, gemeinsam zu lernen und zu wachsen. So verlockend Blaupausen auch erscheinen und so schön aktionistisch ihre Einführung im großen Stil auch aussehen mag, so sicher führt genau das die agile Transformation in eine Sackgasse.