Der schwierige Weg zu mehr Agilität

Viele Teams starten mit der agilen Software-Entwicklung, weil sie gehört haben, dass es dadurch weniger Feuerwehrübungen für sie gibt. Gleichzeitig erhofft sich das Business eine kürzere Time-to-Market. Nach einer Weile merken die meisten Entwickler allerdings, dass sie auf Widerstand stoßen. Das Management versteht nicht, warum die Angestellten jetzt von „selbstorganisierend“ sprechen. Die Tester wollen nicht alle zwei Wochen etwas Unfertiges testen, und die Requirements-Engineers wollen zuerst einmal alles durchdenken und nicht dauernd von den Entwicklern etwas gefragt werden.

So kommt die agile Reise oft nach kurzer Zeit ins Stocken oder wird ganz abgebrochen. Egal ob die Arbeitsweise top-down, bottom-up oder inside-out eingeführt wird – es funktioniert nicht. Nur bei Teams und Organisationen, die es schaffen, alle ins Boot zu holen, klappt es am Ende.

Eines Morgens stürmt der Projektleiter ins Büro und ruft: „Ihr verplempert zu viel Zeit mit Meetings! In der Zeit würdet ihr besser arbeiten!“ Tatsächlich sitzt und steht das Team zu 13 Prozent der Arbeitszeit in Meetings, wenn man dem Scrum Guide folgt. Doch Software-Entwicklung erfordert viel Kommunikation – alle müssen genügend wissen, um gut arbeiten zu können. Daher ist der Zeitaufwand für die Verständigung gerechtfertigt. Wichtig dabei ist, für jedes Meeting ein klares Ziel und ein Zeitlimit festzulegen. Natürlich darf man auch früher fertig sein.

Einmal mehr hat das Team am Ende des Sprints keine lauf­fähige Version fertiggestellt. Also will es die Sprints verlängern, damit alle mehr Zeit haben – oder gleich von Scrum auf Kanban wechseln. Das sind aber keine Lösungen. Das Team muss lernen, kleinere Aufgaben pro Sprint zu übernehmen und gemeinsam zu arbeiten, damit kein Mini-Wasserfall innerhalb des Sprints abläuft. Ein Mini-Wasserfall im Sprint entsteht dann, wenn einzelne Teammitglieder ein sehr ausgeprägtes Rollenverständnis haben:

Wenn der Wurf nicht beim ersten Mal gelingt, geht der Ball zurück an den Anfang der Pipeline und das Pingpong-Spiel beginnt. Oft gefolgt von Diskussionen, wer denn jetzt schuld ist, dass der Job nicht fertig wurde. Das Problem besteht darin, dass das Team keine gemeinsame Verantwortung übernimmt, sondern sich jede Person nur in ihrer Rolle und nur für ihr Gebiet zuständig fühlt. Die Grundlage für ein gemeinsames Verantwortungsgefühl ist das Teilen von Informationen und Wissen, die vollständige Transparenz der Tätigkeiten und eine Kommunikation von Angesicht zu Angesicht.

Hat das Team erkannt, dass es gemeinsam für das gelieferte Ergebnis verantwortlich ist, beginnt es, den Status quo zu hinterfragen: „Ist diese Funktionalität wirklich notwendig?“ „Lässt sich dieses Problem nicht einfacher lösen?“ Hier braucht es unbedingt eine Vision, die die Marschrichtung vorgibt.

Sie hilft, die vielen Ideen und Fragen zu kanalisieren und sich nicht durch Widersprüche blockieren zu lassen. Das Team muss auch lernen, konsequent auf den Business-Wert zu fokussieren. Bei jeder Zeile Code und jedem Test muss das Kosten-Nutzen-Verhältnis klar sein. Wenn alle gelernt haben, so zu denken, geht die Performance durch die Decke. Das Team verschwendet keine Zeit mehr mit unnützen Frameworks oder zu riskanten Experimenten. Agil entwickeln bedeutet, jeden Tag mit Neuem konfrontiert zu sein. Die Teams müssen einen Weg finden, wie sie Lernprozesse in ihren Alltag einbeziehen. Möglichkeiten dafür sind Pair Programming, Coding Dojos und Daily Topic Workshops: Ein Teammitglied erklärt in einem Kurz-Workshop ein Thema, damit alle voneinander lernen können.

„Wann seid ihr fertig?“ ist eine beliebte Frage in der Software-Entwicklung. Und oft werden Schätzungen als Commitments ausgelegt. Das Management will wissen, bis wann das Team garantiert fertig ist. Das Team arbeitet aber mit Schätzungen: Eine 3 bedeutet, dass das tatsächliche Ergebnis mit 80-prozentiger Wahrscheinlichkeit zwischen 2 und 5 liegt (Einheit egal). Dies führt unweigerlich zu Missverständnissen und Problemen mit der Deadline.

Hier braucht es eine Annäherung von beiden Seiten. Das Management muss lernen, mit Unsicherheiten umzugehen, also Chancen und Risiken zu managen. Das Team muss lernen, Aufwandschätzungen auf eine Zeitlinie zu legen – unter Berücksichtigung von Risiken und Abwesenheiten.

Viele Teams tappen auf ihrer agilen Reise in eine Falle: Sie leben zwar einen wunderbar agilen Prozess, die Software lässt aber keine Agilität zu. Der Quellcode ist zu träge, um schnell geändert und erweitert werden zu können. Die Architektur, das Design und die Engineering Practices wurden vernachlässigt. Nur wenn der Prozess (Scrum, Entscheidungsfindung), die Praktiken (TDD, Continuous Integration und Delivery), die Werkzeuge (kollaborativ und nicht einschränkend) sowie Architektur und Design (flexibel und evolvierbar) zusammenpassen, ist Agilität langfristig möglich.

Irgendwann sind alle zufrieden: Neue Funktionalitäten werden zügig entwickelt, die Qualität stimmt, das Team harmoniert. Damit verschwindet auch der Leidensdruck für mehr Innovation. Erst jetzt beginnt der spannende Teil: Bis hierher war die Reise ein Pauschalangebot aus dem Katalog, das für die meisten Teams sehr ähnlich abläuft. Nun beginnt der Indi­vidualtourismus. Jedes Team muss für sich selbst herausfinden, wie es sich weiter verbessern kann.

Die agile Reise ist folglich nie am Ziel, denn kontinuier­liche Verbesserung ist immer möglich. Erfolgreiche agile Teams suchen wiederholt Antworten auf folgende Fragen:

Der Weg von den ersten agilen Gehversuchen bis zum erfolgreichen Team ist lang und steinig, die Mühe aber wert. Der Lohn dafür sind zufriedene Kunden und motivierte Teams.