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 Missverständnis dieser eigentlichen Absicht des Manifests für agile Softwareentwicklung schlägt sich in vielen Scrum-Adaptionen im Rollenverständnis des Product-Owners nieder. Wo dieser sich im besten Sinne als Product-Manager oder wie der CEO des Produkts verstehen sollte, nimmt er oftmals nur Anforderungen entgegen und spezifiziert sie für das Development-Team aus, damit sich die Entwickler auf das Entwickeln konzentrieren können. Kann man agil nennen, ist es aber nicht im Sinne der Autoren des Manifests.
Because members of the project team stay in close touch with outside sources of information, they can respond quickly to changing market conditions. Team members engage in a continual process of trial and error to narrow down the number of alternatives that they must consider. They also acquire broad knowledge and diverse skills, which help them create a versatile team capable of solving an array of problems fast.
Hirotaka Takeuchi und Ikujiro Nonaka in The New New Product Development Game
Der Artikel von Takeuchi und Nonaka aus dem Jahr 1986 gilt als der Ursprung von Scrum. Wie das Zitat zeigt, erkannten sie aus ihren Untersuchungen schon damals, also 15 Jahre vor dem Manifest für agile Softwareentwicklung, dass es eine konstante und intensive Verbindung zwischen Team und Außenwelt braucht, um in einem kontinuierlichen Prozess des Ausprobierens und Lernens gemeinsam neue Erkenntnisse zu gewinnen. Dieses gemeinsame Erkunden der Problemdomäne ist eine Facette von dem was Tackeuchi und Nonaka „multilearning“ nannten. Die andere Facette davon ist eine Lernkultur in der alle ständig darum bemüht sind, Wissen weiterzugegen, ihre Fertigkeiten zu verbreitern und Experten in mehreren unterschiedlichen Disziplinen zu werden. Genau das macht interdisziplinäre Teams schnell und effektiv.
A bad system will beat a good person every time.
W. Edwards Deming
Neben einem Product-Owner als CEO des Produkt und Softwareentwicklern mit Fertigkeiten in unterschiedlichen Disziplinen braucht es aber noch einen dritte Gruppe. Es braucht Menschen, die die Dynamik komplexer Organisationen analysieren und aus systemischer Sicht ganzheitlich optimieren können und auch die Macht dazu haben. Dieses Systemdenken ist also oberste Aufgabe der Führung. Es gehört aber auch zur Ausbildung jedes einzelnen Scrum-Masters, der also – und das ist das zweite große Missverständnis in vielen Scrum-Adaptionen – nicht nur Moderator und Protokollant der Scrum-Events ist, sondern die Produktivität des Teams in seiner Einbettung in die Organisation aus systemischer Sicht analysiert und verbessert.
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.
6 Kommentare
Dem ist inhaltlich nichts hinzuzufügen, verweist es doch auf den fundamentalen Unterschied des agilen Management-Modells zum tyloristischen: Im Mittelpunkt der Organisation steht das produktive Team und nicht die Organisation. Neben der Teamdienlichkeit muss das Organisationsziel seine eigene Reduktion sein – immer wieder.
Sehr richtig. Die Frage ist nicht, was man um die Teams herum aufbauen muss oder soll, sondern eher was man noch weglassen kann. Descale your ourganization!
Ich kann dem bei Software im engeren Sinne noch zustimmen, aber spätestens wenn Systeme entwickelt werden, welche aus ganz unterschiedlichen Teilen bestehen wie Verfahrenstechnik, Mechanik, Leitsystem, eingebetteten Steuerungen, usw. kann das Team (welches überhaupt der beteiligten) das so nicht leisten. In diesem Falle ist eines angesagt: Dekomposition. Und damit haben wir wieder Schnittstellen zwischen den Gewerken. Das Prinzip muss dann hierarchisch auf verschieden Ebenen angewendet werden. Mal ganz abgesehn von Dingen wie Konformität mit den EU Richtlinien und Funktionale Sicherheit.
Das sehe ich anders. Die Teams die die Hirotaka Takeuchi und Ikujiro Nonaka, The New New Product Development Game, beschrieben sind waren genau durch eine massive Interdisziplinarität gekennzeichnet. Ich würde Dekomposition immer soweit wie möglich vermeiden, das führt zu Übergaben und Zwischenergebnissen und damit per Definition zu Verschwendung.
Lieber Marcus,
damit hast Du wieder einmal einen Nagel auf den Kopf getroffen.
Viele Grüße
Stefan
Vielen Dank, lieber Stefan.