Agile Methoden sollten zunächst in einem kleinen und geschützten Rahmen erprobt und dann nach und nach ausgeweitet und auf komplexere Projekte und Produkte angewendet werden. Wer allerdings zu klein startet, bleibt auch wenig wirksam. Dann werden einfach bestehende Abteilungen, Teams, Arbeitsgruppen, Gremien, usw. „agilisiert“. Die Organisation als solche steht nicht zur Disposition und auch nicht die etablierten Arbeitsabläufe. Diese „Silo-Agilität“ wirkt sich nur marginal auf die Wertschöpfung oder die Geschwindigkeit aus. Das Sportlenkrad allein sieht zwar schick und dynamisch aus, ist aber nur agiles Blendwerk.
Ein guter Startpunkt ist ein kleines Projekt oder Produkt, wo ein oder maximal zwei Teams Wirkung entfalten können, d. h. in kurzen Abständen echten Wert liefern können. Also nicht nur irgendein Spezialistenteam für Konzeption oder Test und auch nicht nur das Entwicklungsteam, sondern ein echtes interdisziplinäres Team, das Sprint für Sprint sein Produkt ein wenig besser macht. Dieser Aspekt von Teamwork und Ownership ist viel wichtiger als das kunstvoll zelebrierte Abarbeiten von Arbeitspaketen in Sprints.
Agilität ist wie Fahrradfahren – geübt wird anfangs in möglichst einfacher Umgebung, auf ebener, wenig befahrener Straße ohne Schotter und ähnlichen Störfaktoren. Idealerweise beginnt die Erprobung von Agilität also während sich das Projekt oder das Produkt noch in ruhigem Gewässer befindet.
Die Realität sieht leider anders aus. Ohne Druck ändert sich gar nichts und ohne große Not wird selten wirklich ernsthaft etwas Neues ausprobiert. Never touch a running system. Wieso ein Risiko eingehen? Zur Agilität, zu Scrum, SAFe und LeSS und vielem anderen wird erst gegriffen, wenn das Projekt auf hoher See schon bedrohlich Schlagseite hat. Und das ist tendenziell der Fall bei den großen und komplexen Projekten und Produkten. Die Agilität soll dann im laufenden Betrieb und ohne vorheriges Training in einer geschützten Umgebung retten, was anderweitig nicht mehr zu retten ist. Das ist in etwa so Erfolg versprechend wie der Versuch, Kindern das Fahrradfahren auf einem Downhill-Track im Gebirge bei aufziehendem Gewitter beizubringen.
Adding manpower to a late software project makes it later.
Brook’s Law
Früher war das Allheilmittel zur Rettung von Projekten mehr Ressourcen, neuerdings scheint es der Schwenk zu Scrum und Co. zu sein. Genauso wie zusätzliche Ressourcen ein verspätetes Projekt nur noch mehr verspäten (Brooks, F. P. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley Pub. Co.) verhält es sich oft auch mit der Einführung der Agilität in einer solchen Notlage. Dieser Schwenk ist in einer akuten Krisensituation fast immer fehlgeleitet durch einen einseitigen Fokus auf die Beschleunigung der Abarbeitung. Scrum wird dann als Patentrezept verkauft und eingesetzt, um in kürzerer Zeit mit höherem Druck mehr Arbeitspakete durch das Rohr zu pumpen. Schließlich hat Jeff Sutherland mit Scrum doch eine Verdopplung der Arbeitsleistung bei Halbierung der benötigten Zeit versprochen (Sutherland, J. (2019). Scrum: The art of doing twice the work in half the time. rh Random House Business.).
Break down barriers between departments. People in research, design, sales, and production must work as a team.
W. Edwards Deming
So mechanistisch betrachtet, also einfach alles in Sprints abarbeiten und ein paar Daily Meetings zelebrieren, endet der Rettungsversuch zwangsläufig in einer formschönen Cargo-Kult-Orgie. Das Versprechen von Jeff Sutherland kann erst eingelöst werden nach einer Lernphase in geschütztem Rahmen und mit einem klaren Fokus auf Teamwork und Ownership. Der Dreh- und Angelpunkt ist die interdisziplinäre Zusammenarbeit in einem Team das sich voll und ganz diesem Projekt oder Produkt widmen kann. Dadurch fallen die Koordination von Schnittstellen und Übergaben weg und genau durch diese Reduktion von Verschwendung im Ablauf ergibt sich die Geschwindigkeit. Wenn das Konzeptteam, das Entwicklungsteam und das Testteam, die jeweils eine Ansammlung von Splitterkapazitäten sind, einfach nacheinander in Sprints ihre Pakete abarbeiten, ändert sich wenig und verbrennt das Konzept der Agilität nur unnötig.
Titelbild von Henry & Co. auf Unsplash