Ein Team von Softwareentwicklern ist nicht auf Knopfdruck agil. Ein Team durchläuft verschiedene Phasen während seiner Entwicklung, bis es wirklich agil arbeitet. Ein fiktiver Ablauf.
Die agile Hoffnung
Viele Teams starten ihre Reise in die agile Softwareentwicklung, weil sie gehört haben, dass es für sie weniger Feuerwehrübungen gibt. Gleichzeitig erhofft sich das Business eine schnellere Time-to-Market.
All-in or nothing
Nach einer Weile merken die Entwickler jedoch, dass sie auf Widerstand stossen. Das Management versteht nicht, warum die da unten jetzt von «selbst-organisierend» sprechen. Die Tester wollen nicht alle 2 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. Denn weder eine top-down, bottom-up oder inside-out Einführung funktioniert. Nur die Teams und Organisationen, die es schaffen, alle ins agile Boot zu holen und über den gesamten Value Stream agil zu arbeiten, schaffen es weiter.
Meeting Overhead
Eines Morgens stürmt der Projektleiter ins Büro und ruf: «13% eurer Zeit verbringt ihr in Meetings! In der Zeit würdet ihr besser arbeiten!». Er hat recht: Wenn man dem Scrum Guide folgt, sitzt und steht das Team zu 13% seiner Zeit in Meetings.
Da Softwareentwicklung in erster Linie ein Kommunikationsproblem ist – alle müssen genügend Wissen haben, um gut arbeiten zu können – ist diese Meetingzeit auch gerechtfertigt. Wichtig dabei ist zu erkennen, dass jedes Meeting ein klares Ziel hat und eine definierte Time-box besitzt. Das bedeutet, man darf auch früher fertig sein.
Agil tut weh
Einmal mehr hat das Team am Ende des Sprints keine lauffähige Version fertig gestellt. Alle sind der Meinung: «Das mit den Sprints klappt einfach nicht.» Also wollen sie die Sprints verlängern, damit alle mehr Zeit haben. Oder sie überlegen, sogar gleich von Scrum auf Kanban wechseln.
Dies sind aber keine Lösungen. Das Team muss lernen, kleinere Aufgaben pro Sprint zu übernehmen und gemeinsam als Team zu arbeiten, damit kein Mini-Wasserfall innerhalb des Sprints abläuft. Entwickler und Tester arbeiten Hand in Hand und User Stories werden so klein wie nur möglich geschnitten.
Kollaboration im Team
Der Mini-Wasserfall innerhalb eines Sprints entsteht dadurch, dass die einzelnen Teammitglieder ein sehr ausgeprägtes Rollenverständnis haben.
- Der Requirements-Engineer schreibt auf, was gemacht werden muss.
- Die User-Experience Designerin definiert die Abläufe.
- Die Entwicklerin implementiert es.
- Der Tester überprüft ob alles so ist, wie es sein soll.
Da dies im ersten Wurf nicht gelingt, geht der Bug zurück nach vorne in der Pipeline und das Ping-Pong geht los. Oft gefolgt von Finger-Pointing, wer denn jetzt schuld ist, dass es nicht fertig wurde. Der Grund liegt darin, dass das Team keine gemeinsame Verantwortung übernimmt, sondern jede Person in ihrer Rolle und nur für ihr Gebiet.
Diese verteilte Verantwortlichkeit muss durch eine gemeinsame Verantwortlichkeit ersetzt werden – alle sind zusammen für den Erfolg verantwortlich. Das Team arbeitet zusammen, die Teammitglieder helfen sich gegenseitig aus. Grundlage dafür sind das Teilen von Informationen und Wissen, Transparenz der Tätigkeiten und Kommunikation von Angesicht zu Angesicht.
Alles wird hinterfragt
Wenn das Team erkannt hat, dass es gemeinsam verantwortlich ist für das gelieferte Ergebnis, beginnt es den Status-quo zu hinterfragen: «Ist diese Funktionalität wirklich notwendig?» «Ginge nicht eine einfachere Lösungsvariante?»
Damit sich ein Team in Diskussionen über den Status quo nicht verliert, braucht es dringend eine Vision. Die Vision gibt die Richtung vor, in welche alle hinarbeiten. Sie hilft die vielen Ideen und Fragen des Teams zu kanalisieren um gemeinsam in dieselbe Richtung zu marschieren und sich nicht mit Widersprüchen zu blockieren.
Das Team muss auch lernen, auf Business-Wert zu fokussieren – bei jeder Zeile Code, die geschrieben wird und bei jedem Test der erstellt wird. Was ist der Nutzen (verglichen mit den Kosten)?. Gibt es wertigere Alternativen? Viele Ingenieure tun sich hier schwer, der mögliche «Performance-Boost» ist aber riesig. Das Team verschwendet keine Zeit mehr mit unnützen Frameworks oder zu riskanten Experimenten.
Lernen wird Teil des Alltags
Agil zu werden bedeutet, jeden Tag mit Neuem konfrontiert zu sein. Die Teams müssen einen Weg finden, wie sie Lernen in ihren Alltag einbeziehen können. Denn ein Konferenzbesuch pro Jahr reicht bei weitem nicht aus, um sich all das benötigte Wissen anzueignen.
Lernen kann auf verschiedene Arten Teil des Alltags werden: durch Pair-Programming, Coding Dojos und Daily Topic Workshops, ein Teammitglied erklärt in einem Kurzworkshop ein Thema, um voneinander lernen zu können.
Leben mit Unsicherheit
«Wann seid ihr fertig?» ist eine beliebte Frage in der Softwareentwicklung. Und oft werden Schätzungen als Commitments missbraucht. Das Management möchte ein Commitment im Sinne von «bis wann das Team garantiert fertig ist» (die roten 95% im Bild – 100% Sicherheit gibt es nicht). 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 umgehen zu können – also Chancen und Risiken managen. Das Team muss lernen, dass Aufwandschätzungen alleine nicht reichen, diese müssen auch auf eine Zeitlinie gelegt werden unter Berücksichtigung von Risiken und Abwesenheiten.
Engineering Praktiken
Leider tappen viele Teams auf ihrer agilen Reise in die Falle, dass sie zwar einen wunderbar agilen Prozess leben, die geschriebene 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.
Agile-Happy-Bubble
Irgendwann erreicht das Team, wenn es die Reise bis jetzt nicht abgebrochen hat, die Agile-Happy-Bubble. Alles ist gut, alle sind glücklich. Neue Funktionalitäten werden zügig entwickelt, die Qualität stimmt, das Team ist glücklich.
Das ist der Punkt, an dem Innovation und Verbesserungen stoppen. Es gibt nicht genügend Leidensdruck, um sich weiter zu verbessern. Dabei beginnt hier erst der spannende Teil der Reise. Denn die Reise bis jetzt war wie eine Pauschalreise aus dem Katalog, die für die meisten Teams sehr ähnlich abläuft. Aber ab hier beginnt der Individualtourismus. Jedes Team muss für sich selbst herausfinden, wie es sich weiter verbessern kann.
Sind wir am Ziel?
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 besser zusammenarbeiten?
- 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 werden im uns 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.
