Die klassische Organisation von IT-Prozessen als wenig flexibel zu beschreiben, ist sicherlich keine Übertreibung. Ansätze wie das V- oder Wasserfallmodell sind in definierten Phasen strukturiert, orientieren sich an festgelegten Meilensteinen und die Testphase des Produktes findet erst am Ende des Projekts statt. Nicht vorgesehene Feedback- und Korrekturschleifen erschweren das Reagieren auf geänderte Anforderungen während der Entwicklung zusätzlich. Die IT-Branche benötigte mit steigender Komplexität der Anwendungen, dem Einsatz innovativer Technologien und neuen Anwendungsbereichen einen Gegenpart zu Wasserfall und Co, der eine flexiblere Arbeitsweise versprach und es den Entwicklern gestattete, schnellere Teilerfolge zu erzielen. Die auf dieser Grundlage entstandene agile Softwareentwicklung hat bis heute großen Einfluss auf die Art und Weise, wie Entwickler-Teams ihre Arbeit gestalten.

Ohne Frage sind agile Methoden eine Bereicherung, auch weit über die IT-Branche hinaus. Sie legen den Fokus auf eine schnelle Auslieferung von Produkten, beziehen Anforderungsänderungen in die Prozesse mit ein und legen besonderen Wert auf die kontinuierliche Kommunikation zwischen Entwicklern sowie der Fachseite. Neben all den Vorteilen, die eine so strukturierte Arbeitsweise mit sich bringt, ist eine Sache nicht zu vergessen: Auch in der Softwareentwicklung gibt es nicht nur schwarz und weiß – die Wahl der passenden Methoden und Planung ist stark abhängig von der Art des Projekts.

Schritt-für-Schritt und Sprint-für-Sprint

Es gibt Projekte, die sich praktisch für agile Methoden anbieten. Dazu gehören jene, deren letztendliches Ziel noch nicht vollkommen fest definiert ist oder bei denen Technologien zum Einsatz kommen, deren Effizienz noch nicht absolut einschätzbar ist. Auch langfristige Projekte zählen in diese Kategorie, kann sich mit laufender Dauer doch einiges an den Anforderungen und dem letztendlichen Ziel ändern. In diesen Fällen ist es von Vorteil, wenn der komplette Fahrplan noch nicht komplett vorgegeben ist und Entwickler Schritt-für-Schritt und in kleinen Etappen arbeiten können. Ein perfektes Szenario besteht daher in dem Wissen, wie die ersten Schritte aussehen sollen und was die Anwendung letztendlich leisten soll. Der Weg dorthin ist allerdings nicht vorgegeben und kann sich jederzeit ändern. Ein weiterer Vorteil: Unternehmen sparen bares Geld bei der Planung dieser Projekte, wenn sie auf umständliche und teure Analysen im Vorfeld verzichten.

Ein weiterer positiver Aspekt ist das schnelle Erreichen von ersten Ergebnissen. Anwendungen, die schneller in Produktion gehen, können ebenfalls schneller Einnahmen erzielen. Als klassisches Beispiel dient der Webshop, der stets auf dem aktuellsten Stand bleiben muss, aber auch komplexere Berechtigungssysteme veranschaulichen das Prinzip der agilen Arbeitsmethoden, bei denen sich die Entwickler Sprint-für-Sprint dem eigentlichen Ziel nähern müssen.

Agile Raketen und sichere Flugzeuge

Bei der Frage, wie viel Agilität agiles Arbeiten benötigt und wann Entwickler auf diesen Ansatz eher verzichten sollten, lohnt ein Blick in den Himmel. Luft- und Raumfahrt eignen sich besonders für das Veranschaulichen der möglichen Probleme, die beim Umsetzen von agilen Methoden im sicherheitskritischen Bereich auftreten können. Für Systeme, die etwa Raumfähren in das Weltall bringen sollen, sind herkömmliche, konservative Modelle sehr viel besser geeignet – denn auch die Astronauten werden an Bord ein sichereres Gefühl mit dem Wissen haben, dass die zu Grunde liegende Software ihres Transportmittels von A bis Z im Voraus geplant war und sich auf ein bekanntes Ziel konzentrierte. Gleiches gilt bei Technologien von beispielsweise Beatmungsmaschinen oder Flugzeugen, die strengen Zertifizierungsprozessen und bekannten Anforderungen unterliegen.

Mit diesen Beispielen vor Augen sei an dieser Stelle daran erinnert, dass auch in der Softwareentwicklung nicht nur schwarz und weiß existiert. So hat sich nicht selten ein friedliches Mit- und Nebeneinander verschiedener Modelle etabliert, indem sich agile Aspekte mit traditionellen Arbeitsweisen mischen. Besonders bei der internen Vernetzung haben sich Daily Meetings und andere Kommunikationsformen aus dem agilen Umfeld sehr bewährt. Es muss also nicht zwangsläufig zu einer strikten Trennung von verschiedenen Arbeitsweisen kommen, je nach Projekt und Anforderungen bietet sich durchaus ein Mix an.

Was ein Team im Innersten zusammenhält   

Unternehmen, die sich für agile Methoden in ihrer IT-Abteilung entscheiden, setzen damit gleichzeitig auf ein Modell, das auf selbstorganisierte Teams aufbaut. Bei der Auswahl und Zusammenstellung dieser Arbeitsgruppen sind einige Aspekte zu beachten: Nicht alle Mitarbeiter sind gleich. Einige wollen keine Führungsaufgaben übernehmen, andere wollen sich nicht in Teams organisieren oder sperren sich gegen neue Arbeitsmethoden. Wieder andere brauchen mehr Zeit, um sich an agile Arbeitsweisen zu gewöhnen. Es eignet sich daher nicht jeder Mitarbeiter gleich gut, um in einem agilen Projekt zu arbeiten. Unternehmen sollten außerdem beachten, dass die Umstellung auf neue Konzepte sowohl Zeit als auch Unterstützung benötigt.

Bei der Frage, in welcher Form diese Teams zu leiten sind, kann es schnell zu Verwirrung kommen. In der Theorie arbeiten agile Teams ohne einen Projektmanager, dieser Umstand sollte aber nicht darüber hinwegtäuschen, dass es innerhalb der Unternehmensstrukturen aber sehr wohl Stellen gibt, die beispielsweise über Fortschritte zu informieren sind, das Budget verwalten und in Kontakt mit dem Management des Kunden stehen. Gänzlich autonom und abgeschottet arbeiten Entwickler also nicht. Für die fachliche Komponente sorgt dabei auch der Product Owner, der in seiner Funktion Ideen in das Team hereinträgt und wichtige Entscheidungen trifft. Auf Seite er Selbstorganisation steht der Scrum Master, der sich nicht nur um die nötigen Rahmenbedingungen kümmert, sondern auch das Scharnier zur Führungsebene verkörpert und gegebenenfalls Probleme eskalieren kann.

Das Problem mit dem Budget

Projekte, die sowohl vom Umfang als auch vom zeitlichen Fahrplan sehr flexibel ausgelegt sind, erweisen sich im Punkt Finanzen naturgemäß als schwer einschätzbar. Mit sich ändernden Anforderungen und Funktionen einer Anwendung ist ein fester Kostenprozess nur schwer einzuhalten. Die Praxis hat aber auch hier bereits bewährte Lösungen hervorgebracht: Bei einem Time-and-Material-Ansatz stellt der Kunde das nötige Budget, bis das Projekt beendet ist. Dem gegenüber steht ein Festpreismodell. Beide Ansätze haben Vor- und Nachteile, die im speziellen Anwendungsfall zu bewerten sind.

Agilität bedeutet aber auch, ein Scheitern zu akzeptieren. Für den Fall, dass ein Projekt nicht mehr zielführend oder wirtschaftlich sinnvoll ist, können die Beteiligten es früh genug abbrechen. Bei der Aufarbeitung sollten Unternehmen analysieren, ob der agile Ansatz wirklich der richtige war oder ob ein anderes Konzept erfolgreicher gewesen wäre.

Auf die Mischung kommt es an

Ob agil oder klassisch – die Wahl der richtigen Methode will zu Beginn eines Projekts gut überlegt sein. Entwickler sind aber bei nicht darauf angewiesen, einer strengen Anleitung zu folgen, die verschiedene Modelle ausschließt. Ein Blick auf heutige Prozesse zeigt, dass Unternehmen agile Methoden so gut wie nie komplett umsetzen, sondern nur teilweise. Und dieser Umstand ist absolut akzeptabel. Auch das Mischen aus neueren und klassischen Ansätzen ist Alltag in IT-Abteilungen – hier kommt es auf das Ergebnis an. Ob die Teams dort nun eher konservative Ansätze mit agilen Komponenten vermischen oder umgekehrt, ist letztlich nicht der entscheidende Punkt. Ist das Ergebnis ein sicheres, getestetes und funktionierendes Produkt, haben die Mitarbeiter die richtige Wahl getroffen. Dazu können agile Methoden effektiv beitragen und einen echten Mehrwert darstellen. Und auch wenn einige Mitarbeiter sie nicht zu 100 Prozent annehmen, die wenigsten Entwickler wollen wohl zu reinen Wasserfall-Projekten zurückkehren.