Welche Methode ist die richtige Wahl?

Agile Wasserfälle mit Kanban
Kommentare

Agile oder Wasserfall? Für viele ist die Antwort klar: Wasserfall-Methodiken gelten als tot, heute arbeitet man agil. Das muss aber nicht immer sinnvoll sein – und selbst wenn, kommt es immer noch auf die Wahl der richtigen Methode an, um mit Agile tatsächlich Erfolg zu haben. Kanban, Scrum, XP und SAFe sind nämlich nur ein paar der verfügbaren agilen Methoden und unterscheiden sich in vielen Punkten stark von einander.

Egal, wie gut eine Methode ist, sie wird nie für jedes Unternehmen geeignet sein. Je nach Projekt und Team kann am Ende nämlich sogar eine gut funktionierende Wasserfall-Methode die beste Wahl sein. Das Geheimnis einer erfolgreichen agilen Arbeitsweise ist nämlich, dass dafür viele Veränderungen notwendig sind. Neue Strukturen müssen etabliert werden, neue Arbeitsweisen erlernt. Das Team muss dahinterstehen, ansonsten kann die Umstellung nicht gelingen. Dann wäre Wasserfall die bessere Wahl. Agile muss nämlich konsequent umgesetzt werden, wenn es denn das Mittel der Wahl ist. Ein paar Iterationen reichen dafür nicht. Große Ziele, kleine Schritte kann hier ein passendes Credo sein. Vor allen Dingen müssen aber die Voraussetzungen passen.

Richtige Voraussetzungen

Wichtig ist, dass agile Methoden immer eine starke Beteiligung des Kunden benötigen. Dieser muss dazu bereit sein, regelmäßig über das Produkt zu sprechen. Auch Continuous Delivery bringt wenig, wenn der Kunde eigentlich nur ein fertiges Produkt in den Händen halten möchte, sich aber nicht für benutzbare, noch unvollständige Vorstufen interessiert. Geht es nur um ein Ergebnis, das einer Definition of Done genügt, nicht um eine schnelle Marktreife, braucht das Team sich nicht um allzu häufige Auslieferungen zu bemühen. Wasserfall ist dann manchmal einfach genau das richtige für das Projekt.

Auch in diesem Fall sollte die Idee der klassischen Wasserfall-Methodik, dass der Kunde nur am Anfang und am Ende des Projekts etwas zu sagen hat, allerdings noch einmal überdacht werden. Zwischen diesem Vorgehen und dem Extrem des ständigen Kontakts im agilen Arbeiten gibt es nämlich durchaus einige Zwischenstufen, die auch in einer Wasserfall-Arbeitsweise umgesetzt werden können. Wer sich nämlich erst nach Abschluss der Arbeit am Projekt wieder mit dem Kunden zusammensetzt, verpasst die Chance, Änderungen dann vorzunehmen, wenn sie noch mit wenig Aufwand möglich sind. Dadurch entstehen schnell hohe Kosten und es geht viel Zeit verloren. Das überzeugt sicherlich auch kommunikationsfaule Kunden davon, ein wenig mehr Kontakt zu halten.

Agile Unsicherheiten

Zusätzliche Kosten können aber auch im agilen Projektmanagement entstehen. Zwar kann die Zahl der Sprints für ein Projekt im Voraus geplant werden; die ständige Bereitschaft zur Änderung an den Anforderungen kann aber auch dazu führen, dass die ursprüngliche Planung nicht mehr umsetzbar ist. Dafür bekommt der Kunde aber zu jedem Zeitpunkt das Produkt, das er sich wünscht. Die Einbindung von neu erdachten Features muss nicht warten, bis das Produkt eigentlich schon fertig ist.

Die Vorteile der intensivierten Kommunikation und schnellen Anpassungsfähigkeit an sich ändernde Anforderungen haben alle agilen Arbeitsweisen gemein. Sie stellen Kernaspekte der gesamten Methodik dar. Die verschiedenen agilen Methoden unterscheiden sich jedoch noch einmal stark von einander und sind nicht gleichermaßen für jedes Projekt geeignet.

Scrum

Die wohl bekannteste agile Methodik ist Scrum. Dieser Begriff wird oft synonym mit Agile verwendet. Nach Scrum zu arbeiten, ist allerdings nur ein Weg von vielen, um agil zu sein. Scrum ist bestens geeignet für Projekte, an denen Mitarbeiter verschiedener Fachrichtungen zusammenarbeiten. Die starke Fokussierung auf Kommunikation und Austausch ist an dieser Stelle sehr hilfreich. In Scrum ist auch der Sprint absolut unverzichtbar, also die Arbeitsphase, in der keine Änderungen am Projekt vorgenommen werden. Das widerspricht auf den ersten Blick der Grundidee des Flexibilität – auf den zweiten aber nicht mehr.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Wer nach Scrum arbeitet, plant immer nur den nächsten Sprint konkret und hält sich während des Sprints auch an die Planung. In dieser Zeit soll das Team sich ganz auf die anliegenden Aufgaben konzentrieren können, statt immer wieder zu besprechen, was denn nun anliegt. Alle neu hinzukommenden Anforderungen werden aber ins Backlog aufgenommen und zum nächsten Sprint sofort berücksichtigt. Da Sprints kurz sind, maximal zwei Wochen dauern sie, kann dadurch keine große Verzögerung eintreten. Der übernächste Sprint wird nämlich eh erst geplant, wenn der aktuelle sich dem Ende zuneigt. So können auch alle Erfahrungen aus dem jeweiligen Sprint direkt in die nächste Planung mit eingehen.

Kanban

Kanban ist noch eines der großen Frameworks der agilen Arbeitsweise. Es verbindet agile Methodiken mit dem Lean Management und ist vor allem dann gut geeignet, wenn es darum geht, komplexe Projekte zu überblicken und die gleichzeitig laufende Arbeit im Blick zu behalten. Je komplexer ein Projekt wird, desto wahrscheinlicher ist es nämlich, dass sich das Team in unzähligen kleinen Aufgaben verliert, ohne wirklich Fortschritte verzeichnen zu können.

In Kanban steht das Board im Zentrum der Arbeitsweise des Teams. Hier werden (bevorzugt physisch) alle laufenden, erledigten und noch zu erledigenden Aufgaben gesammelt. Sind zu viele Aufgaben auf einmal in Arbeit, wird ihre Zahl reduziert und die Anstrengung des Teams auf den aktuellen Schwerpunkt konzentriert. Über das Board werden außerdem Flaschenhälse sichtbar: Wenn die Arbeit sich an einer Stelle staut, kann hier gezielt angesetzt und das Problem schnell gelöst werden.

Kanban ist daneben ein leichtes Framework ohne fixe Restriktionen. Natürlich sind Veränderungen notwendig, um Kanban einzuführen; während Scrum jedoch eine klare Linie vorgibt, ermöglicht Kanban mehr Freiheiten und Anpassungen an die individuellen Gegebenheiten.

Extreme Programming

Die Idee des Extreme Programming (XP) ist älter als das agile Manifest. Die Grundidee hier ist, einen möglichst guten Code ins Zentrum der Entwicklung zu stellen. Dabei wird Code in Form des Pair Programming geschrieben, also jedem Entwickler einen Partner zur Seite gestellt. So soll die Zahl der Fehler im Code reduziert werden; auch die Verständlichkeit des Codes steigt durch die enge Zusammenarbeit. Jeder Entwickler weiß jederzeit, was seine Kollegen machen und kann deren Code bearbeiten. Auch der Gedanke der Einfachheit wird im Extreme Programming verfolgt. Code wird für die heutigen Anforderungen geschrieben, nicht für mögliche weitergehende Entwicklungsstufen. Die einfachste Lösung ist dabei immer zu bevorzugen.

Eine weitere Grundidee des Extreme Programming ist das Test Driven Development. Dabei werden Testfälle entwickelt, bevor der zu testende Code geschrieben wird – und nur wenn dieser danach den Test besteht, wird er verwendet. Keine Komponente wird ungetestet ins Produkt integriert; so wird die Zahl später zu lösender Bugs klein gehalten. Insofern ist Extreme Programming wohl der richtige Ansatz, wenn der Anspruch an die Produktqualität besonders hoch ist.

SAFe

Das Scaled Agile Framework, SAFe, ist eine agile Arbeitsweise, die die Methodik auf einen größeren Maßstab anpasst. Scrum, Kanban und Co sind vor allem auf kleine, einzelne Teams ausgelegt und tun sich schwer damit, viele hundert oder sogar tausend Mitarbeiter zu vereinen. Die agilen Prinzipien des ständigen Kontakts untereinander oder des einen, gemeinsamen physischen Boards lassen sich hier nur schwer umsetzen.

Natürlich können die nun nötigen Anpassungen individuell vorgenommen werden. Nicht jedes Unternehmen ist aber bereits sicher genug im agilen Arbeiten, um das selbst zu tun. Wenn trotzdem die gesamte Unternehmensstruktur auf agiles Arbeiten umgestellt werden soll, bietet sich ein Framework wie SAFe an.

Viel Auswahl

Natürlich ist das nur eine Auswahl der verfügbaren agilen Methodiken. Die Auswahl ist riesig – groß genug, um den Überblick zu verlieren, Wichtig ist dabei, dass es kein einzelnes „optimales“ Framework gibt und agil nicht deshalb eingeführt werden sollte, weil es halt alle machen. Auch geht es nicht immer um ein entweder – oder. So ist Kanban zwar die häufigste Wahl, um ein möglichst nahtloses Continuous Delivery zu gewährleisten; das ist aber durchaus auch in Scrum möglich. Und die hohe Softwarequalität des Extreme Programming kann durchaus auch in Kanban erreicht werden, indem die entsprechenden Techniken adaptiert werden. Gute Software gab es jedoch auch schon vor der Einführung agiler Methoden.

Am Ende kommt es immer auf die Mitarbeiter und das Projekt an, wenn es um die Auswahl der richtigen Arbeitsweise geht. Passt das Projekt nicht zur Arbeitsweise, wird es schwer, ein gutes Ergebnis zu erzielen. Darum ist die erste Frage vor der Umstellung auf eine agile Arbeitsweise wohl, welche Probleme damit gelöst werden sollen. Erst, wenn diese Frage beantwortet ist, kann das richtige Framework gewählt werden. Mit „ein bisschen Agile“ ist nämlich noch nichts gewonnen.

Aufmacherbild: Handwritten Inspirational Quote – Explore Your Options via Shutterstock / Urheberrecht: Tashatuvango

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -