01.12.2017
Die Evolution zum agilen Software-Development
1. Teil: „Der schwierige Weg zu mehr Agilität“
Der schwierige Weg zu mehr Agilität
Autor: Urs Enzler
bbv
Ein Team von Entwicklern ist nicht auf Knopfdruck agil. Es durchläuft verschiedene Phasen. Welche das sind, erklärt Urs Enzler, Agile Coach bei der bbv Software Services AG.
Dieser Artikel wurde von Urs Enzler verfasst, Agile Coach bei der bbv Software Services AG.
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.
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 ein Zeitlimit festzulegen. Natürlich darf man auch früher fertig sein.
Altes Rollenverständnis
Einmal mehr hat das Team am Ende des Sprints keine lauffä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:
- Der Requirements-Engineer definiert, was zu tun ist
- Die User-Experience-Designerin definiert die Abläufe
- Die Entwicklerin implementiert
- Der Tester überprüft, ob alles so ist, wie es sein soll
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.
2. Teil: „Ideen, Probleme, Praktiken und Weiterentwicklung“
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.
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 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.
Engineering-Praktiken
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.
Individuelle Weiterentwicklung
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 Individualtourismus. Jedes Team muss für sich selbst herausfinden, wie es sich weiter verbessern kann.
Die agile Reise ist folglich 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 sich ändernden Wünsche unserer Kunden und Benutzer einfacher adaptieren?
- Wie können wir besser darin werden, uns zu verbessern?
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.
Breitbandmarkt
Gigabit-fähige Anschlüsse werden zu selten gebucht
Die jährliche Studie zum deutschen Breitbandmarkt von VATM und Dialog Consult zeigt, dass die Zahl schneller Glasfaseranschlüsse steigt, doch vor allem bei der Telekom ist die Take-Up-Rate immer noch gering.
>>
Nutanix .NEXT 2024
Showtime auf der .NEXT für die hybriden Multiclouds von Nutanix
Kaum Wolken am Himmel, dennoch dreht sich in Barcelona alles um die Cloud. Wenigstens auf der .NEXT, dem Jahreskongress von Nutanix. Der Anlass bietet mehr als nur News und Networking. Hier können sich Kunden beraten und Partner direkt zertifizieren lassen.
>>
Für HP-Partner
Miete24 launcht HP Workplace-as-a-Service-Konzept
Die Grenke-Tochter Miete24 und HP arbeiten künftig enger zusammen. Mit der Kooperation erweitert Miete24 sein Angebot um einen speziellen Bereich, in dem HP-Partner in Zukunft Produkte rund um den Arbeitsplatz mieten können.
>>
Künstliche Intelligenz
Microsoft stellt umfassende Anleitung zur Nutzung des Semantic Kernel .NET vor
Wie kann man Künstliche Intelligenz in die eigene Anwendung integrieren? Ein Blogpost auf den DevBlogs von Microsoft gibt detailliert Auskunft.
>>