Ideen, Probleme, Praktiken und Weiterentwicklung

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.