Analyse

Agile Teams gibt es nicht auf Knopfdruck: Der Weg ist das Ziel

(Foto: Shutterstock)

Teams starten in die agile Softwareentwicklung, weil sie gehört haben, dass es für sie dann weniger Feuerwehrübungen gäbe. Gleichzeitig erhofft sich das Business eine schnellere Time-to-Market.

Und der Kunde freut sich, weil er dann genau das kriegt, was er braucht. Aber ein Team von Softwareentwicklern ist nicht auf Knopfdruck agil. Es durchläuft verschiedene Phasen während seiner Entwicklung, bis es wirklich agil arbeitet.

Alles oder nichts

Zu Beginn ist die Euphorie in einem neuen agilen Team groß. Schließlich verspricht die agile Vorgehensweise riesige Vorteile auf allen Ebenen. Doch einmal eingeführt, merken viele Entwickler nach einer Weile, dass sie auf Widerstand stoßen: Das Management versteht nicht, warum die da unten 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.

Agil betrifft alles, den gesamten Value-Stream.

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.

Meetings ja, aber im Rahmen

Eines Morgens stürmt der Projektleiter ins Büro und ruft: „13 Prozent 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 Prozent 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 zu 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.

Zusammenarbeit 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.

BU: Ping-Pong im agilen Team, das keine gemeinsame Verantwortung übernimmt.

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 nur für ihre 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, zu der 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.

Permanentes Lernen

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.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Ein Kommentar
Lutz Müller
Lutz Müller

Ein guter Artikel, der aufzeigt, dass das Einführen von agilen Arbeiten viele Problem aufzeigt. Das ist jedoch eine Chance, um Verbesserungen voranzutreiben, da diese Probleme überhaupt erst einmal sichtbar werden.
Aus meiner Sicht ist der erste Schritt das WARUM zu klären. Teams und Mitarbeiter müssen die Notwendigkeit und Dringlichkeit agilen Arbeitens in ihrem Unternehmen kennen.
Im zweiten Schritt kann man neue Teams aufstellen. Dazu empfehle ich einen Kick-Off, der essentielle Grundlagen legt, damit das Team direkt starten kann: https://www.lutz-mueller.com/projekt-kick-off-agile-teams/

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.