Agile für alle?

Wann agile Softwareentwicklung sinnvoll ist und wann nicht
Kommentare

Agile ist eines der großen Buzzwords der Softwareentwicklung. Der Entwicklungsprozess muss schließlich fortlaufend optimiert werden! Die Vorteile sind dabei ja auch unbestreitbar. Agile Methoden und Frameworks können helfen, komplexe Prozesse zu strukturieren und die Produktivität von Entwicklerteams zu erhöhen, während gleichzeitig die Qualität der entwickelten Software steigt. Doch das gelingt bei weitem nicht immer, und am Ende ist die agile Softwareentwicklung auch nur ein Ansatz von vielen. Welcher methodische Ansatz sinnvoll ist, hängt von Team und Projekt ab – und es gibt sogar Fälle, in denen die beste Methodik nicht hilft.

Ein häufiger Fehler bei der Auswahl der richtigen Methodik für ein Entwicklerteam ist, einfach einem Trend zu folgen. Natürlich sind agile Methoden beliebt und das mit gutem Grund; im Zentrum der Methodenwahl muss aber doch die Frage nach Bedingungen und Bedürfnissen des einzelnen Entwicklerteams stehen. Auch bei der Auswahl einer Methodik gilt nämlich „never change a running system“ und ein Team, das zufrieden mit seiner bisherigen Arbeit ist, wird sich nicht auf agile Methoden einlassen wollen. Damit agile Ansätze nämlich irgendetwas besser machen können, sind große Veränderungen notwendig. Einfach nur ein paar Meetings mehr, das ist noch lange kein agiles Arbeiten.

Doch auch wenn das Team bereit ist, neue Strukturen umzusetzen, ist das keine Erfolgsgarantie. Passen die Projekte nicht zur gewählten Methode, passt das Framework nicht zu den Präferenzen des Teams, kann die Umstellung nicht gelingen. Eine geschickte Wahl des richtigen Ansatzes ist hier wichtig.

Agile – die Grundlagen

Die agile Arbeitsweise beruht auf zwölf Prinzipien, die sich im agilen Manifest nachlesen lassen. Zu den Grundlagen gehört dabei die interne Kommunikation des Teams sowie der ständige Kontakt mit dem Kunden – regelmäßige Meetings sind Pflicht! Auch die Unterteilung des Projekts in Iterations, also ein bis zwei Wochen dauernde Arbeitsphasen (Timeboxes) mit festgelegten Aufgaben und abschließenden Meetings, den Retrospektiven, ist unverzichtbar. Ebenfalls wichtig sind die Storycards, die die Produktgeschichte erzählen und zeigen sollen, warum ein Feature wichtig ist und wie der Nutzer damit interagieren wird. Das Product Backlog, die Liste der noch zu erledigenden Aufgaben, gehört zu den Kernaspekten eines agilen Projekts.

Daneben legt ein agiler Entwicklungsprozess großen Wert darauf, von Anfang an eine Definition of Done zu haben, die nicht verändert wird, weil die Zeit knapp wird. Veränderungen der Kundenwünsche sind im agilen Prozess allerdings jederzeit willkommen, werden aber nicht in eine laufende Iteration eingefügt, sondern erst zum nächsten Durchlauf integriert. Während einer Iteration soll das Team sich ganz auf die Arbeit konzentrieren, die vereinbart wurde.

Agile Praxis

Zur Einschätzung der benötigten Arbeitszeit für ein Projekt werden jedem gewünschten Feature Punkte zugewiesen. Dadurch, dass die Punktzahl sich nach dem Umfang des gewünschten Features richtet und ein Team immer eine ähnliche Anazhl an Punkten pro Durchlauf abarbeiten kann, lässt sich jederzeit ein relativer Wert für die noch benötigte Arbeitszeit benennen.

Durch all diese Schritte bekommt ein Projekt mehr Struktur, unklare Anforderungen fallen schnell auf. Das Produkt wird außerdem so früh wie möglich dem Kunden übergeben und darauf aufbauend weiter entwickelt, sodass Differenzen und Missverständnisse früh benannt werden können.

Agile Grenzen

Agile ist dabei jedoch kein Allheilmittel. Zwar intensiviert sich die Kommunikation im Team automatisch durch die täglichen Stand-Up-Meetings; ein Team mit großen internen Differenzen wird dadurch aber noch nicht zusammenwachsen. Auch unterschiedliche Vorstellungen von Geschäftsführung und Entwicklern können nicht einfach durch ein agiles Vorgehen gelöst werden. Legen die Entwickler in der zu Beginn festgelgten Definition of Done großen Wert auf Qualität, kann auch der im agilen Arbeiten enthaltene Anspruch an die Geschwindigkeit nichts daran ändern, dass dafür eine gewisse Zeit notwendig ist, die dem Management vielleicht nicht gelegen kommt.

Sehr kleine oder vollkommen vertraute Projekte, für die schon perfekt einübte Arbeitsabläufe existieren, eignen sich außerdem weniger gut für agiles Arbeiten. Es ist hier einfach nicht sinnvoll, den Aufwand einer agilen Veränderung von Arbeitsabläufen zu betreiben. Veränderungen im Team hebeln außerdem schnell jede zeitliche Planbarkeit aus, da diese aufgrund abstrakter Punktzahlen erfolgt und die individuelle Leistungsfähigkeit der Mitarbeiter außen vor lässt. Verlässt nun ein sehr leistungsfähiger Mitarbeiter das Team, wird ein agiler Ansatz Schwierigkeiten damit haben, den Effekt auf das Projekt vorherzusagen.

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

Meetings, Meetings, Meetings?

Ein agiler Prozess ohne regelmäßige Meetings ist kein agiler Prozess. Die direkte Kommunikation, am besten „face to face“, ist sogar im agilen Manifest verankert, insofern also ein zentraler Bestandteil der Methode. Und die Retrospektive als Mittel zur Reflexion über die geleistete Arbeit und Optimierung der weiteren Arbeitsschritte ist unverzichtbar. Allerdings ist es eine Kunst, ein gutes Meeting zu gestalten. Teambuilding-Maßnahmen oder kreative Ideen zur Auflockerung können sinnvoll sein, um nicht das große Schweigen im täglichen Meeting zu erleben. Immerhin ist es ja doch so, dass Programmierer doch lieber Code schreiben als darüber zu reden. Trotzdem ist so aber jeder Mitarbeiter jederzeit über den Projektstand informiert und kann dazu beitragen, Fehler früh zu erkennen.

Ein agiles Framework: Scrum

Scrum ist wohl das bekannteste agile Framework. Wenn ein Team auf agile Prozesse umsteigen möchte, ist dieser Ansatz oft die erste Wahl. In Scrum werden Iterationen Sprints genannt, die gut geplant sein müssen; jedes Team bekommt für jeden Sprint ein Board, auf dem festgehalten wird, was zu tun ist, was schon getan wurde und was noch zu klären ist. Die gleichzeitig in Arbeit befindlichen Features werden in Scrum nur über die Punktzahl pro Feature und pro Sprint begrenzt. Liegen viele kleine Aufgaben an, können sie mit Scrum parallel bearbeitet werden.

Lean?

Häufig ist in diesem Kontext auch der Begriff Lean Development zu hören. Lean ist ein Ansatz, der ursprünglich aus der Produktion physischer Güter stammt und in die Softwareentwicklung übernommen wurde. Im Zentrum des Lean Development stehen sieben Prinzipien:

  1. Eliminate waste
  2. Amplify learning
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build quality in
  7. See the whole

„Waste“ ist dabei im Lean Software Development alles Unnötige, ohne Ausnahme. Lean bemüht sich darum, den Entwicklungsprozess schlanker zu gestalten; überflüssige Meetings können dabei genau so eliminiert werden wie sich wiederholende Aufgaben. Ständiger Kontakt zum Kunden wie im agilen Development muss dabei nicht gegeben sein, wenn dieser eher als störend empfunden wird, der Schwerpunkt liegt stärker auf der Geschwindigkeit und Effizienz des Prozesses als in einer agilen Methodik. Insofern ist Lean kein Synonym für Agile.

Kanban

Kanban ist eine flexiblere Methode der Software-Entwicklung, die sich an den Grundsätzen des Lean Development orientiert und weniger enge Grenzen setzt, als dies oft im agilen Kontext der Fall ist. Im Gegensatz zu Scrum schreibt Kanban beispielsweise nicht zwingend vor, dass die Arbeit in Sprints unterteilt werden muss. Auch in anderen Punkten zeigt sich Kanban flexibler. Boards können beispielsweise von mehreren Teams gleichzeitig genutzt werden, Änderungen von Anforderungen können jederzeit in die Arbeit integriert werden, nicht erst nach Ende eines Arbeitsabschnitts.

Best of Both Worlds

Kanban und Scrum, Lean und Agile sind allerdings keine Gegensätze, sondern können sich sehr gut ergänzen, um eine optimale Arbeitsumgebung für ein Team zu schaffen. Nicht jedes Team möchte sich wirklich jeden Tag treffen, wie es das agile Arbeiten verlangt; nicht jedes Team will jeden einzelnen, bisher funktionierenden, Arbeitsschritt auf seine Effizienz überprüfen, um ihn unter Umständen aufzugeben. Hier kann ein Best of Both Worlds-Ansatz helfen, Frust vorzubeugen. Denn auch, wenn das Team zu Veränderungen bereit ist, müssen es eben doch die richtigen Ansätze sein. Der eine, in jedem Kontext richtige Ansatz existiert nämlich nicht.  Am Ende geht es vor allem darum, dass das Team hinter dem Ansatz stehen muss, ansonsten ist jeder Versuch zum Scheitern verurteilt.

„[…] trying to get developers to do anything which they don’t perceive as helping them do their work is going to be a failure” – Alan Keefer

Aufmacherbild: cases on board von Shutterstock.com / Urheberrecht: Bartosz Budrewicz

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -