Endlich agil! Agile Projekte in nicht-agilen Strukturen

Ein Cartoon der Seite "Geek & Poke", der auch Titelbild dieses Beitrags ist, zeigt zwei Personen vor dem komplexen Organigramm ihrer Firma. Ganz unten, im tief verzweigten Strukturgeäst ist eins der Organigramm-Elemente rot eingefärbt. "Das ist unser agiles Projekt", sagt die eine Person zur anderen. Und unter dem Cartoon heißt es: "Endlich sind wir agil!"

Agiles Arbeiten, hört man häufig als erstes von allen, die davon überzeugt sind, ist keine Methode, die man selektiv anwenden kann. Es ist eine Philosophie, ein "Framework", das alle Bereiche der Unternehmensführung und der Arbeit in Projekten berührt. Seine wichtigsten Elemente sind nicht Sprints oder Scrum-Master, "Planning Poker" oder Kanban-Boards, sondern Werte wie Offenheit und Vertrauen und die Bereitschaft, sich auf Ungewisses einzulassen.

Doch selbst wenn das stimmt, lässt sich keine Organisation, die bisher nicht agil gearbeitet hat, von heute auf morgen auf so ein völlig neues Arbeitskonzept umkrempeln. Irgendwo muss man anfangen. Das kann auch bedeuten, dass man die neue Philosophie zunächst an nur einer Stelle ausprobiert.

Aus der Digitalstrategie der Stiftung "Haus der kleinen Forscher" und dem dazugehörigen Advisory Board war relativ deutlich herausgefallen, dass "Digitalisierung" nicht nur weniger Papier bedeutet, sondern auch einen Kulturwandel mit sich bringen muss. Klassisches Projektmanagement, mit seiner präzisen Vorplanung aller Schritte und Ressourcen über einen langen Zeitraum – beliebt und gewünscht gerade bei öffentlichen Geldgebern, die ebenfalls so arbeiten – kann nicht mehr alle Anforderungen erfüllen, die zunehmend digitale Prozesse an heutige Arbeit stellen. Davon waren alle überzeugt. Das bedeutete aber noch lange nicht, dass es leicht ist, ein Projekt zu finden, an dem sich die neuen Ideen problemlos testen lassen.

Denn obwohl agile Befürworter schnell dabei sind, einem von den Vorzügen der neuen Arbeitsphilosophie vorzuschwärmen, fällt es ihnen nicht leicht, zu erklären, wo genau Organisationen anfangen und was genau die ersten Schritte sein sollten. Teil von Agilität ist nun einmal, dass es am Anfang keinen klaren Fahrplan gibt. Dennoch funktioniert agiles Arbeiten nach festen Regeln und bedeutet nicht, dass jeder macht, was er will. Dieses Paradoxon ist Managerinnen und Managern, die andere Strukturen gewohnt sind, schwer zu vermitteln. Die erste Lektion kann daher nur lauten: Nicht locker lassen. Nach einem langen Abwägungsprozess bewies die Stiftung Mut und entschied sich dazu, das Projekt "Neue Lernplattform" mit einem agilen Team aufzusetzen.

Um Experimente zu wagen sind in einer Stiftung selten üppige Ressourcen vorhanden. Sach- wie Personalmittel sind zu großen Teilen klar zweckgebunden und nicht beliebig verschiebbar. Mit genügend Kreativität klappte es trotzdem irgendwie. Unser agiles Team sollte an zwei Tagen die Woche nach der Methode Scrum gemeinsam mit der finnischen Firma Valamis, die ebenfalls agil arbeitet und die Ausschreibung gewonnen hatte, die neue Lernplattform aufsetzen. Inhaltlich stand sowohl die Teil-Automation des Akkreditierungs-Prozesses für Trainerinnen und Trainer der Stiftung auf dem Programm, als auch die erste Blended-Learning-Fortbildung, die ein Team im Haus im Auftrag des BMBF und des hessischen Kultusministeriums entwickelte.

Entscheidender Faktor war, das lässt sich jetzt im Rückblick sagen, dass alle Mitglieder des Teams nicht nur nach Kenntnissen ausgewählt wurden, die möglichst das ganze Spektrum der Stiftung abdecken. Auch eine hohe Ausgangsmotivation wurde berücksichtigt. Die Teammitglieder waren bereit, sich auf die neuen Arbeitsphilosophien und -methoden einzulassen und dienen jetzt, ein knappes Jahr später, damit bereits als Erfahrungsträgerinnen und neue Überzeuger. Ohne ein motiviertes Team hätte das Experiment sicher schlechter funktioniert.

Für sich spricht, dass das Team in der Lage war, innerhalb eines halben Jahres eine funktionierende Lernplattform online zu bringen (die ich hier nicht verlinken kann, weil sie nach wie vor nur für einen kleinen Kreis von Nutzerinnen und Nutzern zugänglich ist). Diese Geschwindigkeit ist in einer Stiftung, in der die Produktentwicklung in der Regel 18 Monate dauert, ungewöhnlich. Agilität, im Sinne von "Wendigkeit", macht ihrem Namen also alle Ehre.

Allerdings ist einer der Grundsätze der gleichen Wendigkeit auch, dass ein Ziel immer zunächst ein "minimal lebensfähiges Produkt" ist, auf das dann sukzessive aufgebaut werden kann. So soll vermieden werden, in langwierigen Prozessen "fertige" Produkte zu entwickeln, die dann vielleicht an den Bedürfnissen der Nutzerinnen und Nutzer vorbeilaufen. Natürlich ist ein in sechs Monaten entwickeltes Produkt nicht so "fertig" wie eins, das über anderthalb Jahre diverse Kontrollschleifen durchlaufen hat. Sich hier von Perfektionismus zu verabschieden und auf ein "gut genug für jetzt" zu vertrauen, war für viele außerhalb der agilen Petrischale schwierig.

Das gilt auch für Kommunikation und Rollenverständnisse. Wer sich innerhalb eines agilen Projekts bewegt, dem sind die neuen Rollen wie Product Owner und Scrum-Master bald ein Begriff. Von außen aber scheint alles so viel weniger geordnet und nicht übertragbar auf gewohnte Strukturen. Wenn sich das Team selbst organisiert, wer ist dann Projektauftraggeber und damit letztendlich verantwortlich? Um diese Frage zu beantworten, wurde zunächst eine Projektauftraggeberin als Brückenelement eingeplant, die dann aber später aus eigener Überzeugung ihre Position abschaffte. Der Product Owner ist kein Vorgesetzter, warum sollte ich mit ihm über strategische Dinge sprechen? (Antwort: Weil das seine Aufgabe ist.)

Die gleiche Unsicherheit zeigte sich zum Teil im Berichtwesen. Scrum hat sehr detaillierte Vorgaben zu Dokumentation und Vorstellung der eigenen Arbeit. Rhythmen und Detailtiefe, in denen berichtet wird, richten sich aber nach den Sprints des Projekts. Wer als Außenstehender informiert sein will, muss selbstständig zu Review-Terminen erscheinen und das Risiko eingehen, dort nur einen vagen Eindruck vom Gesamtzustand des Produkts zu erhalten. Klassische regelmäßige Fortschrittsberichte ans Management gibt es bewusst nicht, da sie vom eigentlichen Ziel der Weiterentwicklung des Produkts ablenken. Gerade beim ersten agilen Projekt fehlte dies aber manchen, die von außen zusahen. Gerade dann, wenn die Unsicherheit durch fehlendes klassisches Berichtswesen zunimmt, ganz auf das Team zu vertrauen, ist nicht einfach.

Es ist möglich, ein einzelnes agiles Projekt innerhalb nicht-agiler Strukturen zu verankern, wenn Wille und motiviertes Team gefunden sind. Die Produktentwicklung selbst wird durch das klassische Drumherum nicht gebremst, sie muss aber stetig vermitteln, dass sie an anderen Maßstäben gemessen werden sollte. Ein Übergangsknirschen in Kommunikations- und Berichtsprozessen zwischen den zwei Welten ist normal, sollte aber nicht entmutigen. Würden wir anderen Stiftungen raten, es auf die gleiche Weise zu probieren? Als Antwort sei gesagt, dass für ein neues Digitalprojekt gerade das zweite agile Team seine Arbeit aufgenommen hat.

Mitarbeit am Text: Florian Fischer, Kecia Holtzendorff, Tim Kiese