Warum agil? Werte und die Wahl des Vorgehens

Worum es geht

Montag, 08.15 Uhr bei der Codewerk Hug AG in St. Gallen. Der Teamleiter legt eine Vorlage auf den Tisch: «Bevor wir eine Zeile programmieren, schreiben wir ein vollständiges Pflichtenheft. Dann wissen alle, was gebaut wird.» Klingt vernünftig. Nur: Die Sekretärin der Musikschule, für die das Team ein Anmeldeportal bauen soll, sagt am Telefon Sätze wie «Die Eltern sollen sich halt anmelden können» und «Das sehe ich dann, wenn ich es vor mir habe». In zehn Wochen beginnt das neue Semester, und dieser Termin lässt sich nicht verschieben.

Ein Pflichtenheft würde hier zwei Wochen kosten und wäre trotzdem bald falsch, weil die Musikschule ihre Wünsche erst beim Ausprobieren erkennt. Genau für solche Situationen sind agile Methoden entstanden. In dieser Lektion lernst du, was «agil» wirklich bedeutet, was im Agilen Manifest steht und wie du begründet entscheidest, ob ein Vorhaben agil, klassisch oder gemischt angegangen wird. Diese Begründung wird in Prüfungen fast immer verlangt.

Zwei Arten, Software zu bauen

Stell dir eine Velotour von St. Gallen nach Luzern vor. Variante 1: Du planst zu Hause jede Abzweigung und fährst die Route stur ab. Variante 2: Du kennst Ziel und Richtung, schaust aber an jeder grösseren Kreuzung auf die Karte und passt die Route an, wenn eine Strasse gesperrt ist. Auf einer Strecke, die du zehnmal gefahren bist, reicht Variante 1. Auf einer unbekannten Strecke mit Baustellen bist du mit Variante 2 schneller.

In der Softwareentwicklung heisst Variante 1 phasenorientiertes oder klassisches Vorgehen, oft «Wasserfall» genannt: Anforderungen, Entwurf, Umsetzung, Test und Einführung laufen nacheinander ab. Erst ganz am Schluss sieht die Kundin das fertige Produkt.

Variante 2 ist das agile Vorgehen. Das Team arbeitet in kurzen Zyklen von ein bis vier Wochen. Am Ende jedes Zyklus steht ein kleines, lauffähiges Stück Software, das die Kundin ausprobieren kann. Ihr Feedback fliesst in die Planung des nächsten Zyklus ein.

Zwei Begriffe musst du dabei sauber auseinanderhalten:

Agile Methoden arbeiten iterativ und inkrementell: Sie liefern laufend neue nutzbare Teile und verbessern gleichzeitig die bestehenden. Ein Projekt, das zwar in Etappen gebaut wird, aber erst am Schluss etwas Nutzbares zeigt, ist nur in Häppchen geplant, nicht agil.

Das Agile Manifest in eigenen Worten

Im Februar 2001 hielten 17 Softwareentwickler in den USA fest, was ihre leichtgewichtigen Methoden (darunter Scrum und Extreme Programming) gemeinsam haben. Das Ergebnis ist das Manifest für Agile Softwareentwicklung mit vier Werten und zwölf Prinzipien. Jeder Wert ist als Vergleich formuliert: Die linke Seite ist wichtiger, die rechte bleibt aber wichtig.

Aus den zwölf Prinzipien sind im Alltag vor allem diese wichtig (sinngemäss):

1. Früh und regelmässig nutzbare Software liefern, lieber alle zwei Wochen als alle zwei Monate.
2. Geänderte Anforderungen auch spät willkommen heissen, wenn sie der Kundschaft nützen.
3. Fachleute und Entwicklung arbeiten täglich zusammen.
4. Lauffähige Software ist das wichtigste Mass für Fortschritt.
5. Das Team überlegt regelmässig, wie es besser werden kann, und passt sich an.

Dahinter steckt ein Gedankenmodell: Klassisch ist der Umfang fix, Zeit und Kosten werden geschätzt (und oft überschritten). Agile Teams drehen das um: Zeit und Kosten sind fix (z.B. Semesterstart, vier Lernende), der Umfang ist flexibel. Deshalb kommt zuerst, was am meisten Nutzen bringt. Läuft die Zeit ab, fehlt höchstens das Unwichtigste.

Agil, klassisch oder hybrid: so entscheidest du

Agil ist nicht automatisch besser. Beim Austausch der Server-Hardware im Lehrbetrieb sind Umfang und Ablauf bekannt: bestellen, einbauen, migrieren, testen. Niemand braucht nach zwei Wochen «einen halben Server zum Ausprobieren». Hier passt ein klarer Phasenplan.

Diese Fragen helfen dir bei der Entscheidung:

Viele Vorhaben liegen dazwischen. Dann ist ein hybrides Vorgehen sinnvoll: Die Gesamtplanung mit Meilensteinen und Budget läuft klassisch, die Entwicklung selbst in Sprints. Die Schweizer Bundesverwaltung arbeitet mit HERMES, das genau so eine Kombination erlaubt: Phasen mit Entscheidungspunkten für die Steuerung, agile Entwicklung in der Realisierung.

Schritt für Schritt: Ilaria begründet ihr Vorgehen

Ilaria soll dem Teamleiter bis Mittwoch eine kurze Begründung schicken. Sie geht systematisch vor.

Schritt 1: Merkmale des Vorhabens sammeln. Aus den Gesprächen notiert sie: Wünsche vage, Sekretärin will «es sehen», Termin Semesterstart fix (10 Wochen), Team fix (4 Lernende), Musikschule ist alle zwei Wochen für einen Termin bereit, eine einfache Anmeldung für ein Instrument wäre schon nützlich.

Schritt 2: Fragen der Entscheidungstabelle beantworten.

Schritt 3: Gegenargumente prüfen. Gibt es etwas, das klar für klassisch spricht? Der fixe Termin. Ilaria erkennt aber: Ein fixer Termin spricht nicht gegen agil, sondern für einen flexiblen Umfang. Agil liefert das Wichtigste zuerst, also steht beim Semesterstart sicher eine funktionierende Anmeldung bereit.

Schritt 4: Entscheid und Rahmen festlegen. Scrum mit Sprints von zwei Wochen, also fünf Sprints bis zum Semesterstart. Fixer Termin, flexibler Umfang. Ein grobes Backlog statt eines Pflichtenhefts.

Schritt 5: Begründung formulieren. Ilarias Mail an den Teamleiter:

Betreff: Vorgehen Anmeldeportal Musikschule

Ich schlage Scrum mit Sprints von zwei Wochen vor. Die Musikschule kann ihre
Anforderungen noch nicht beschreiben und will Lösungen sehen, bevor sie
entscheidet. Der Semesterstart ist fix: Wir halten den Termin und passen den
Umfang an. Zuerst bauen wir die zwingend nötige Anmeldung. Die Sekretärin
sieht alle zwei Wochen den Stand und entscheidet mit, was als Nächstes kommt.

Der Teamleiter ist einverstanden. Er verlangt nur nach jedem Sprint einen kurzen Stand für die Geschäftsleitung, ein kleines hybrides Element, und das ist in Ordnung.

Jetzt du: Bring die Entscheidungstabelle in Code. Sind alle Tests grün, hast du die Kriterien so verstanden, dass du sie einer Maschine erklären kannst.

Agil ist eine Haltung, kein Kalender

Viele Teams halten sich für agil, weil sie Dailies und ein Board haben. Entscheidend ist, ob die Werte gelebt werden. Drei Warnsignale:

• Das Daily ist ein Rapport an den Chef statt einer Abstimmung im Team (Wert: Menschen und Zusammenspiel).
• Im Review zeigt das Team Folien, aber niemand von der Kundschaft ist da (Wert: Zusammenarbeit mit der Kundschaft).
• Die Retro findet statt, aber Massnahmen werden nie umgesetzt (Prinzip: regelmässig verbessern).

Wer solche Muster erkennt, argumentiert mit den Werten: «Das Review soll uns Feedback bringen. Ohne die Sekretärin präsentieren wir uns selbst.»

Typische Fehler

• Agil heisst ohne Plan. Falsch. Agile Teams planen sogar häufiger: grob für das Vorhaben, genau für den Sprint, täglich im Daily. Der Plan ist nur nicht unveränderlich.
• Agil heisst ohne Dokumentation. Das Manifest sagt «mehr als», nicht «statt». README, API-Beschreibung und Betriebshandbuch werden geschrieben, wenn sie gebraucht werden.
• Iterativ und inkrementell verwechseln. Iterativ heisst verbessern, inkrementell heisst wachsen. Agil braucht beides.
• Ein fixer Termin bedeutet klassisch. Gerade bei fixem Termin hilft agil, weil das Wichtigste zuerst fertig wird.
• Rituale mit Agilität verwechseln. Ein Daily ohne Abstimmung oder eine Retro ohne Folgen ist «Scrum nur dem Namen nach».

Zusammenfassung

• Klassisch arbeitet Phasen nacheinander ab, der Umfang ist fix, das Ergebnis kommt am Schluss.
• Agil liefert in kurzen Zyklen nutzbare Teile (iterativ und inkrementell), Zeit und Kosten sind fix, der Umfang ist flexibel.
• Das Agile Manifest (2001) hat vier Werte: Menschen, funktionierende Software, Zusammenarbeit mit der Kundschaft und Reagieren auf Veränderung zählen mehr als Prozesse, Dokumentation, Verträge und Pläne.
• Agil passt bei unklaren, sich ändernden Anforderungen, erreichbarer Kundschaft und nutzbaren Teillieferungen. Klassisch passt bei klarem, stabilem Umfang.
• Hybride Vorgehen kombinieren eine klassische Gesamtsteuerung mit agiler Entwicklung.
• Begründe die Wahl immer mit konkreten Merkmalen des Vorhabens.
• Agil ist eine Haltung: Rituale ohne gelebte Werte bringen nichts.