Ein Team von Software-Entwicklern ist nicht auf Knopfdruck agil. Es durchläuft verschiedene Phasen, bis es wirklich agil arbeitet. Dieser Beitrag zeigt die häufigsten Hürden und wie man sie überwindet.
Viele Teams starten mit der agilen Software-Entwicklung, weil sie gehört haben, dass es für sie dadurch weniger Feuerwehrübungen gibt. Gleichzeitig erhofft sich das Business eine kürzere Time-to-Market. Nach einer Weile merken die Entwickler jedoch, dass sie auf Widerstand stossen. Das Management versteht nicht, warum die Angestellten jetzt von «selbst-organisierend» sprechen. Die Tester wollen nicht alle zwei Wochen etwas Unfertiges testen. Und die Requirements-Engineers wollen zuerst mal alles durchdenken und nicht dauernd von den Entwicklern etwas gefragt werden.
So kommt die agile Reise bei vielen Teams schon nach kurzer Zeit ins Stocken oder sie wird sogar 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.
Zeitaufwendige Meetings
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 eine Zeitlimite festzulegen. Natürlich darf man auch früher fertig sein. Auf der nächsten Seite: Warum aus Sprints Langstreckenläufe werden und wie man das verhindert
Altes Rollenverständnis
Einmal mehr hat das Team am Ende des Sprints keine lauffähige Version fertig gestellt. Also will das Team die Sprints verlängern, damit alle mehr Zeit haben. Oder sogar 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. Der Mini-Wasserfall innerhalb eines Sprints entsteht dadurch, dass die einzelnen Teammitglieder ein sehr ausgeprägtes Rollenverständnis haben. 1. Der Requirements-Engineer schreibt auf, was gemacht werden muss. 2. Die User-Experience-Designerin definiert die Abläufe. 3. Die Entwicklerin implementiert es. 4. Der Tester überprüft, ob alles so ist, wie es sein soll.
Wenn dies im ersten Wurf nicht gelingt, geht der Ball zurück nach vorne in der Pipeline und das Ping-Pong geht los. Oft gefolgt von Diskussionen, wer denn jetzt schuld ist, dass der Job nicht fertig wurde. Das Problem liegt darin, dass das Team keine gemeinsame Verantwortung übernimmt, sondern jede Person in ihrer Rolle und nur für ihr Gebiet. Grundlage für ein gemeinsames Verantwortungsgefühl sind das Teilen von Informationen und Wissen, Transparenz der Tätigkeiten und Kommunikation von Angesicht zu Angesicht. Auf der nächsten Seite: Ideen kanalisieren und Probleme mit Deadlines vermeiden
Ideen kanalisieren
Hat das Team erkannt, dass es gemeinsam verantwortlich ist für das gelieferte Ergebnis, beginnt es, den Status quo zu hinterfragen: «Ist diese Funktionalität wirklich notwendig?» Oder: «Lässt sich dieses Problem nicht einfacher lösen?» Hier braucht es unbedingt eine Vision, welche die Marschrichtung vorgibt. Sie hilft, die vielen Ideen und Fragen des Teams 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 Kurzworkshop ein Thema, um voneinander lernen zu können.
Probleme mit Deadlines
«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 es mit 80% 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 managen. Das Team muss lernen, Aufwandschätzungen auf eine Zeitlinie zu legen werden unter Berücksichtigung von Risiken und Abwesenheiten. Auf der nächsten Seite: Enineering-Praktiken und Weiterentwicklung trotz Zufriedenheit
Engineering-Praktiken
Leider tappen viele Teams auf ihrer agilen Reise in die Falle, dass sie zwar einen wunderbar agilen Prozess leben, die Software aber keine Agilität zulässt. 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) und die Architektur und Design (flexibel und evolvierbar) zusammenpassen, ist Agilität langfristig möglich.
Individuelle Weiterentwicklung
Irgendwann sind alle zufrieden: Neue Funktionalitäten werden zügig entwickelt, die Qualität stimmt, das Team harmoniert. Damit verschwindet aber auch der Leidensdruck für mehr Innovation und Weiterentwicklung. Erst jetzt beginnt der spannende Teil: Bis hierher war die Reise eine Pauschalangebot aus dem Katalog, die für die meisten Teams sehr ähnlich abläuft. Nun beginnt der Individualtourismus. Jedes Team muss für sich selbst herausfinden, wie es sich weiter verbessern kann. Die agile Reise ist nie am Ziel, denn kontinuierliche Verbesserung ist immer möglich. Erfolgreiche agile Teams suchen wiederholt Antworten auf folgende Fragen:
Wie können wir schneller liefern?
Wie können wir die Qualität erhöhen?
Wie können wir uns an die ändernden Wünsche unseren Kunden und Benutzern einfacher adaptieren?
Wie können wir besser darin werden, uns zu verbessern?
Der Weg von den ersten agilen Gehversuchen bis zum erfolgreichen agilen Team ist lang und steinig, die Mühe aber wert. Denn der Lohn dafür sind zufriedene Kunden und motivierte Teams.
