Ausbreitung

Wie breitet sich “Agilität” in einem Unternehmen aus?

Um diese Frage zu konkretisieren, möchte ich Antworten auf folgende Fragen geben:

1) Wie sollte sich die Arbeit in mehreren agilen Entwicklungsteams gestalten?

2) Warum sollten sich agile Werte und Prinzipien auch auf andere Organisationsbereiche, die nicht direkt Teil der Entwicklung sind, ausbreiten?

3) Welche Maßnahmen sind sinvoll, um eine Ausbreitung wahrscheinlicher zu machen?

Zu 1) Arbeit in mehreren agilen Entwicklungsteams

Agile Entwicklungsteams arbeiten entweder

• unabhängig von einander – zum Beispiel wenn sie verschiedene Produkte entwickeln, oder
• kooperativ – zum Beispiel wenn sie gemeinsam ein umfangreiches Produkt  entwickeln.

“Team” bedeutet idealerweise: eine kleine Gruppe von Personen, die an einem Ort zusammenarbeitet – das reduziert die Abstimmungsaufwände innerhalb der Gruppe. Warum?

Weil die Gruppe immer wieder

• ein gemeinsames Verständnis schaffen muss – zum Beispiel über geänderte Kundenanforderungen und deren Auswirkungen, und
• Entscheidungen treffen muss – zum Beispiel vereinbaren muss, was sie als nächstes umsetzt.

Und das geht in Kleingruppen, in der sich die Mitglieder kennen, schätzen und persönlich treffen, einfacher.

Wenn mehrere Teams zusammen an einem umfangreichen Produkt arbeiten, ist zusätzlich Kommunikation zwischen den Teams notwendig, um die Arbeit aufeinander abzustimmen.

Damit diese Abstimmungsaufwände zwischen den Teams nicht zu groß werden, werden in vielen Fällen sogenannte Featureteams gebildet – Teams, die eigenständig Kundenanforderungen umsetzen, und das durch alle Schichten des Produkts, zum Beispiel von der Benutzungsoberfläche bis zum Speichern in der Datenbank einer Software.

Die trotzdem notwendigen Abstimmungen zwischen Teams können zum Beispiel mittels Scrum of Scrums erfolgen, in dem Probleme, die mehrere Teams betreffen, angesprochen werden – wie beispielsweise Änderungen an einer gemeinsamen technischen Infrastruktur. Diese Aufwände können über ein geeignetes Produktdesign weiter reduziert werden, zum Beispiel durch ein Microservices-Architektur.

Zu 2) Warum sich agile Werte und Prinzipien über die Entwicklung hinaus ausbreiten sollten

Der Grund für die Ausbreitung über die Grenzen der Entwicklung hinaus ist vielleicht nicht sofort klar – warum sollten Bereiche, die nicht direkt Teil der Entwicklung sind, sich überhaupt um “Agilität” kümmern? Ist agiles Arbeiten nicht immer Sache von Entwicklungsteams?

Es gibt zahlreiche Ideen, die in diesem Kontext beachtenswert sind – teilweise stammen sie aus dem Bereich Lean Management, teilweise aus der Organisationsentwicklung. Gemeinsam ist ihnen folgendes: viele Organisationen heute sind nicht für das optimiert, was gefragt ist.

Und was ist heute oft gefragt?

Im ersten Teil dieser Blogserie habe ich meine Definition einer agilen Organisation gegeben: “eine Organisation, die kurzfristig auf unvorhergesehene Änderungen in der Organisationsumwelt (z.B. von Kundenbedürfnissen) oder in der Organisation selbst reagieren kann, indem sie  Produkte oder Dienstleistungen neu entwickelt oder bei mindestens gleichbleibender Qualität anpasst.”

Was passiert in vielen Organisationen, wenn sich Kundenbedürfnisse ändern?

Die Organisationsmaschinerie springt an. Verschiedenste Organisationsbereiche beginnen ihre Arbeit – je nach Situation zum Beispiel Change Management, Vertrieb,  Marketing, Portfoliomanagement, Einkauf, Projektmagement. Die Entwicklung beginnt. Die Entwicklung endet. Das Produkt wird ausgeliefert. Die Wartung / der Betrieb beginnt. Kunden melden Fehler oder Änderungwünsche, oder neue Kundenbedürfnisse werden ermittelt (z.B. über Marktforschung oder Feature Toggles). Es geht wieder von vorne los.

Nur…

Wie lange dauert es vom Ermitteln eines Kundenbedürfnisses bis der Kunde ein neues/geändertes Produkt gekauft hat und es an ihn ausgeliefert wurde? Kauft er überhaupt das Produkt, oder geht es an seinen Bedürfnissen vorbei? Sind die Mitarbeiter der Organisation leidenschaftlich damit beschäftigt, zu einem solchen Produkt beizutragen (das ja letztlich ihr Gehalt bezahlt), oder sind sie leidenschaftlich damit beschäftigt, davon unabhängige organisationsinterne oder eigene Interessen zu verfolgen?

Wie viel hilft es also, wenn agile Entwicklungsteams innerhalb von wenigen Wochen oder Monaten die Entwicklung abschließen können, wenn der Gesamtprozess der Auslieferung dann doch über ein Jahr oder sogar mehrere Jahre dauert, oder das Produkt gar nicht ausgeliefert, oder nicht gekauft wird?

Das erste Prinzip des agilen Manifests besagt:

“Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.”

Diese Art der Auslieferung zu ermöglichen ist oft eine herausfordernde Aufgabe für die gesamte Organisation. Agiles Entwickeln und Ansätze aus dem Lean Management und der Organisationsentwicklung schließen sich daher nicht gegenseitig aus, und sie sind auch nicht unabhängig voneinander. Sie ergänzen einander so, dass daraus ein für die Organisation sinnvolles Ganzes wird.

Deswegen verwende ich den Begriff “Agile Organisation”.

3) Sinnvolle Maßnahmen, um die Ausbreitung wahrscheinlicher zu machen

Ich sage hier bewusst “wahrscheinlicher zu machen”, nicht “folgen Sie diesen Maßnahmen, das funktioniert garantiert”. Eine Organisation ist ein komplexes Gebilde, und zu denken, dass man dieses Gebilde einfach steuern könnte, halte ich für eine Illusion.

Meiner Erfahrung nach werden Sie Kritiker weniger durch Diskussionen überzeugen, sondern durch Handlungen. Wagen Sie es, agil zu arbeiten, auch wenn es zuerst nur in einem Team ist, und erwarten Sie nicht, dass es von Anfang an gut läuft – es wird vermutlich Monate brauchen. Wenn es dann gut läuft, ist es gut möglich, dass sich andere ein Beispiel nehmen, und selber anfangen, agil zu arbeiten – damit erreichen Sie die Ausbreitung wie in 1) beschrieben.

Unterstützung durch das höhere Management ist sehr hilfreich und manchmal auch nötig, um überhaupt an diesen Punkt zu gelangen – denn es wird wahrscheinlich Kritik und Widerstände von denen geben, die an der bisherigen Art zu Arbeiten festhalten wollen. Agiles Arbeiten ist sehr gut geeignet, Missstände aufzudecken, und es ist oft einfacher, diese dem agilen Arbeiten zuzuschreiben, als die wahren Gründe aufzudecken.

Ein großes Problem sehe ich in lokalen Belohnungssystemen. Dazu ein Beispiel: ein Entwickler bekommt einen Bonus dafür, wenn er möglichst wenige Defects produziert. Was macht er nun, wenn er selber einen Defect findet? Wie wahrscheinlich ist es, dass er diesen Defect in ein Werkzeug einstellt? Lokale Belohnungssysteme, die nur einen Teil des Wertschöpfungsprozesses im Auge halten, erzeugen oft Interessenkonflikte. Solche Belohnungssysteme abzuschaffen ist Aufgabe des Managements einer Organisation, die ernsthaft agil werden will.

Eine Wertstromanalyse (Value Stream Mapping) kann sehr gut dabei helfen, Probleme bei der Wertschöpfung entlang des Prozesses von der Anforderung zum fertigen Produkt zu finden, beispielsweise vermeidbare Wartezeiten.

Die konsequenteste Maßnahme, die das Management ergreifen kann, ist eine Umstrukturierung der Organisation, d.h. ein Aufbrechen der etablierten Hierarchie und eine Neuorganisation, die Gruppen bildet, die autonom Kundenbedürfnisse erfüllen können. Weil diese Art der Neuorganisation mit der Aufgabe von Machtansprüchen einhergeht, ist sie die unwahrscheinlichste der genannten Maßnahmen. Unternehmen wie z.B. der dm Drogeriemarkt beweisen aber, dass es möglich und profitabel ist, eine solche Neustruktierung vorzunehmen.

Sind Sie selbst in einer Organisation, die agil werden will? Dann kontaktieren Sie uns.  Ob Lean Startup, Value Stream Mapping oder Einsatz von agilen Frameworks – wir unterstützen Sie gerne.

Series Navigation

<< Verinnerlichung