Die Evolution zum agilen Software-Development

Der schwierige Weg zu mehr Agilität

von - 01.12.2017
Foto: 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.
Urs Enzler
Agile Coach bei der bbv ­Software Services AG
„Bei jeder Zeile Code und jedem Test muss das Kosten-Nutzen-Verhältnis klar sein.“
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 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:
  • 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.
Verwandte Themen