Die Arbeit in Industrieunternehmen ist geprägt von Prozessen, Rollen und Standards – zentral geplant, ausgearbeitet, dokumentiert, ausgerollt, geschult und in ihrer Anwendung und Einhaltung regelmäßig überprüft. Dafür gibt es dann ISO- und DIN-Stempel und alle sind glücklich. Jedenfalls auf dem Papier. Man kann und muss sich tatsächlich manchmal fragen, ob die eigentliche Arbeit wegen oder doch eher trotz der vielen Prozesse funktioniert. Davon soll aber nur am Rande die Rede sein. Vielmehr geht es um die Frage, ob agile Organisationen Prozesse und Standards brauchen. Und wenn ja, wie diese eigentlich entstehen und sich weiterentwickeln.
Ein Grundprinzip von agilen Organisationen ist die Dezentralisierung. Kleine und schlagkräftige Einheiten agieren möglichst komplett eigenverantwortlich gegenüber ihren Kunden. Buurtzorg macht das zum Beispiel mit den Pflegeteams so, FAVI mit den Mini-Fabriken und Spotify mit seinem Squads oder Amazon mit den Two-Pizza-Teams. Alles was die Entscheidungs- und Handlungsfreiheit dieser Teams in Form von zentral vorgegebener Prozesse und Standards einschränkt, schränkt die Agilität und damit den Kundennutzen ein.
Aber wo kämen wir denn da hin, wenn jedes Team anders arbeitete? Wird das nicht ganz schön unübersichtlich? Wie soll man denn so zusammenarbeiten? Ein paar Prozesse und Standards braucht es dann doch trotz aller Agilität. Kein vernünftiges Softwareunternehmen wird es zum Beispiel zulassen, dass Teams die an einem gemeinsamen Produkt arbeiten ihren Sourcecode in unterschiedlichen Repositories mit unterschiedlichen Branching-Strategien verwalten. Zu mühsam wäre es, das alles kontinuierlich in ein lauffähiges Produkt zu integrieren. Google geht sogar soweit, seinen gesamten Source-Code, der aus mehreren Milliarden Zeilen besteht, seit mehr als 16 Jahren in einem einzigen Repository zu speichern.
Auch auf Versprechen von Schnittstellen will man sich bei aller Agilität verlassen können und nicht täglich von einem komplett anderen Verhalten überrascht werden. Darum hat es sich in vielen agilen Softwareunternehmen als gute Praktik eingebürgert, Schnittstellen zu versionieren, zu dokumentieren und mit automatisieren Tests das versprochene Verhalten ständig zu verifizieren. Auf einmal veröffentlichte Schnittstellen muss man sich blind verlassen können und es muss einen Satz an automatisierten Testfällen geben, mit denen sich die Schnittstelle überprüfen lässt. Ganz schön viel Regeln und ganz schön starre Prozesse für die agilen Teams also.
Die Freiheit des Einzelnen endet dort, wo die Freiheit des Anderen beginnt.
Immanuel Kant
Diese Leitlinie hilft auch hier bei der Unterscheidung. Ob die einen Teams lieber Scrum nutzen und die anderen Kanban, oder ob die einen ein elektronisches Taskboard verwenden, während die anderen auf ihr physisches Board schwören, wie sie ihren Teamraum dekorieren oder mit welchen Werkzeugen sie am produktivsten arbeiten, das und vieles mehr berührt die Freiheit der anderen Teams eher nicht oder nur wenig. Den Source-Code nicht zentral abzulegen oder die Stabilität von veröffentlichten Schnittstellen zu verletzen, berührt die Freiheit der anderen sehr wohl, weil es dadurch unweigerlich zu Störungen im Prozess des kontinuierlichen Bauens und Integrierens des gemeinsamen Produkts kommt. Und das verlangsamt dann alle.
Agile Software-Teams wollen in erster Linie eines: Ihr neues Feature so schnell wie möglich ausliefern und ausprobieren. Dazu haben sie ihre hochgradig individuelle Arbeitsweise im Team und das ist auch gut so. Dazu verlassen sie sich aber auch auf Regeln der Zusammenarbeit, die sich für alle als hilfreich herausgestellt haben. Agilität und Prozesse und Standards schließen sich also keineswegs aus. Im Gegenteil, es braucht teilweise sogar recht starre Regeln, damit jedes Team seine Agilität bestmöglich im Verbund mit den anderen ausleben kann.
Es bleibt also auch agil alles beim Alten? Nicht ganz. Die Prozesse, Standards und Regeln der gemeinsamen Arbeit werden nämlich nicht mehr an einer zentralen Stelle erarbeitet, beschrieben und dann für alle verpflichtend ausgerollt, sie entstehen vielmehr aus der gemeinsamen Arbeit und werden von den Teams gemeinsam weiterentwickelt. Der Hauptunterschied sind also nicht neue Prozesse, Standards und Regeln zur Zusammenarbeit der agilen Teams, sondern viel mehr die Tatsache, dass diese aus der Zusammenarbeit entstehen und alle gemeinsam dafür Verantwortung tragen anstatt sie als zentrale Vorgabe aufgezwungen zu bekommen. Ein feiner, aber wesentlicher Unterschied.
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
2 Kommentare
„Ob die einen Teams lieber Scrum nutzen und die anderen Kanban, oder ob die einen ein elektronisches Taskboard verwenden, während die anderen auf ihr physisches Board schwören, wie sie ihren Teamraum dekorieren oder mit welchen Werkzeugen sie am produktivsten arbeiten, das und vieles mehr berührt die Freiheit der anderen Teams eher nicht oder nur wenig.“
Ich gebe dir Recht, bei diesem Satz, dass es die Teams nicht in der Freiheit nicht einschränkt, wohl aber das Unternehmen, welches vielleicht Features einstellt, neue Teams bildet, die sich dann an neue agile Methoden gewöhnen müssen oder diese ganz neu lernen müssen. Über die Beweglichkeit und die Wandlungsfähigkeit von Entwicklern hat Gunter Dueck gleich mehrere Bücher verfasst, inwieweit unterschiedliche agile Arbeitsmethoden sich bei notwendigen Team-Interaktionen reiben, dazu fehlt mir die Erfahrung.
Lieber Heiko, unterschiedliche Methoden führen zu Reibung. Der Punkt ist, dass die Teams selbst da dann gemeinsam eine Lösung finden müssen und werden. Das Prinzip der Selbstorganisation ist der Kern von Agilität.