Agile Programmierung
Was Agile eigentlich bedeutet
Agile Softwareentwicklung ist kein Werkzeug und keine Zertifizierung, sondern eine Haltung zur Planung: Man geht davon aus, dass man am Anfang eines Projekts noch nicht genug weiß, und richtet die Arbeit so ein, dass Lernen billig bleibt. Statt einer Spezifikation, die zwölf Monate hält, gibt es alle paar Wochen etwas Lauffähiges und eine Gelegenheit, die Richtung zu korrigieren.
Der Begriff stammt aus dem Februar 2001, als sich siebzehn Entwickler in Utah trafen und das Agile Manifest schrieben. Vier Sätze, zwölf Prinzipien, eine Seite. Alles Weitere, von Scrum über SAFe bis zum agilen Coaching, ist später darauf aufgebaut worden.
Die Prinzipien dahinter
Das Manifest stellt vier Paare gegenüber und sagt, dass die linke Seite schwerer wiegt:
- Individuen und Interaktionen vor Prozessen und Werkzeugen
- Funktionierende Software vor umfassender Dokumentation
- Zusammenarbeit mit dem Kunden vor Vertragsverhandlung
- Reagieren auf Veränderung vor dem Befolgen eines Plans
Wichtig ist der Nachsatz, der gern überlesen wird: Die rechte Seite hat Wert, sie hat nur weniger. Verträge, Dokumentation und Pläne verschwinden nicht, sie bekommen einen anderen Stellenwert.
Warum das für Firmen hier relevant ist
Bonn hat eine ungewöhnliche Mischung: Konzerne, Bundesbehörden, Forschungseinrichtungen, dazu Agenturen und eine überschaubare, aber aktive Startup-Szene. Genau in dieser Mischung wird es interessant, weil agile Teams hier oft in einem Umfeld arbeiten, das in Haushaltsjahren und Vergabeverfahren denkt. Wie man beides zusammenbringt, ist eine der Fragen, über die sich gut diskutieren lässt.
Die bekanntesten Methoden
- Scrum: feste Sprints, drei Verantwortlichkeiten, fünf Termine. Das am weitesten verbreitete Framework und meist der erste Kontakt mit Agile.
- Kanban: kein Sprintrhythmus, dafür ein sichtbares Board und ein Limit für parallele Arbeit. Kommt aus der Fertigung, funktioniert gut bei laufendem Betrieb und Support.
- Extreme Programming: die technische Seite. Pair Programming, testgetriebene Entwicklung, ständige Integration, kleine Releases. Weniger populär als Scrum, aber die Praktiken stecken heute in fast jedem gut funktionierenden Team.
Was es bringt
Der praktische Effekt ist selten spektakulär, aber messbar. Probleme fallen früher auf, weil regelmäßig etwas Fertiges entsteht. Prioritäten werden diskutierbar, weil eine gemeinsame Liste existiert. Und der Aufwand, eine Fehlentscheidung zu korrigieren, sinkt, je kürzer der Weg zwischen Idee und Rückmeldung ist.
Ein Beispiel aus der Praxis
Eine Agentur baut einen Relaunch. Klassisch würde ein halbes Jahr lang konzipiert, gestaltet, umgesetzt und am Ende alles auf einmal live geschaltet, inklusive der Überraschungen. Agil geht nach drei Wochen eine erste Version mit den wichtigsten Seiten online, oft nur intern. Die Redaktion arbeitet damit, meldet zurück, dass die Bildergalerie im Alltag hakt und die Suche wichtiger ist als gedacht. Diese Erkenntnis kostet in Woche drei fast nichts. In Woche zwanzig kostet sie den Zeitplan.
Wo Agile-Projekte scheitern
Fast nie an der Methode. Die üblichen Muster:
- Agil im Team, Wasserfall drumherum. Fester Umfang, festes Budget, fester Termin, und dazu die Bitte, flexibel zu sein.
- Das Daily wird zur Statusrunde für die Führungskraft statt zur Abstimmung im Team.
- Rollen werden vergeben, Befugnisse nicht. Ein Product Owner, der nichts entscheiden darf, ist ein Ticketverwalter.
- Retrospektiven finden statt, Konsequenzen nicht. Nach dem dritten Mal glaubt niemand mehr daran.
Was bleibt
Agile ist mittlerweile über zwanzig Jahre alt und hat das übliche Schicksal erfolgreicher Ideen erlebt: erst Bewegung, dann Industrie, dann Backlash. Was davon trägt, sind die technischen Praktiken und die Gewohnheit, Annahmen früh zu überprüfen. Der Rest ist Verhandlungssache, und genau darüber reden wir bei den Treffen.