Warum agil? Werte und Vorgehen aus Sicht des Fachbereichs

Worum es geht

Die Seeland Versicherungsdienst AG in Biel hat vor zwei Jahren ein Kundenportal gebaut. Die Fachabteilung schrieb dafür ein Pflichtenheft mit 60 Seiten, die IT setzte es neun Monate lang um. Am Tag der Einführung meldeten sich die ersten Kundinnen: «Warum kann ich keine Fotos von meinem Schaden hochladen?» Daran hatte niemand gedacht. Jetzt soll eine Online-Schadenmeldung entstehen, und die Product Ownerin Sandra Moser sagt: «Diesmal schreiben wir kein dickes Pflichtenheft. Wir zeigen alle zwei Wochen etwas, das man ausprobieren kann.»

Für dich als Entwickler/in digitales Business ist das keine Nebensache. Du sitzt oft genau zwischen der Fachabteilung, die weiss, was die Kundschaft braucht, und dem IT-Team, das es baut. Wenn du verstehst, warum agile Teams so arbeiten, kannst du der Fachabteilung erklären, was von ihr erwartet wird, und du kannst begründet sagen, wann ein klassischer Plan doch besser passt.

Zwei Wege zum Ziel: planbasiert und iterativ

Stell dir zwei Arten vor, ein Fest zu organisieren.

• Die Hochzeit: Datum, Gästeliste, Menü und Ablauf werden Monate im Voraus festgelegt. Änderungen kurz vor dem Fest sind teuer. Hier ist ein genauer Plan richtig, weil fast alles bekannt ist.
• Das neue Restaurantmenü: Ein Koch weiss nicht genau, welche Gerichte bei den Gästen ankommen. Also setzt er jede Woche zwei neue Gerichte auf die Tageskarte, hört zu, was die Gäste sagen, und passt an. Nach einigen Wochen steht ein Menü, das wirklich gefällt.

Genau so unterscheiden sich die beiden Vorgehen in Projekten:

Zwei Fachbegriffe tauchen dabei immer wieder auf:

• Iterativ heisst: Man durchläuft denselben Zyklus mehrmals (planen, bauen, zeigen, lernen) und verbessert das Ergebnis jedes Mal.
• Inkrementell heisst: Das Produkt wächst Stück für Stück. Jedes Stück (Inkrement) ist für sich nutzbar.

Agile Teams arbeiten beides zugleich: Sie liefern in jedem Zyklus ein zusätzliches Stück und lernen aus dem Feedback für den nächsten Zyklus.

Die vier Werte des Agilen Manifests aus Business-Sicht

2001 trafen sich in den USA siebzehn erfahrene Softwareentwickler und hielten fest, was erfolgreiche Teams anders machen. Das Ergebnis heisst Agiles Manifest. Es besteht aus vier Werten und zwölf Prinzipien. Die Werte sind immer gleich gebaut: Das Linke ist wichtiger als das Rechte, aber das Rechte bleibt wertvoll.

Von den zwölf Prinzipien sind für dich als Bindeglied zum Fachbereich vier besonders wichtig (in eigenen Worten):

1. Früh und regelmässig Nutzen liefern. Die Kundschaft soll möglichst bald etwas Brauchbares bekommen.
2. Änderungen sind willkommen, auch spät. Sie sind oft ein Wettbewerbsvorteil.
3. Fachleute und Entwickler arbeiten täglich zusammen. Die Fachabteilung ist kein Auftraggeber, der am Schluss abnimmt, sondern Teil des Vorhabens.
4. Funktionierende Software ist das wichtigste Mass für Fortschritt. «80 Prozent der Analyse erledigt» sagt wenig. «Velodiebstahl kann online gemeldet werden» sagt viel.

Agil oder planbasiert: Kriterien für die Wahl

Agil ist nicht immer besser. Die Wahl hängt vom Vorhaben ab. Diese Fragen helfen dir, sauber zu entscheiden:

Bei den meisten Vorhaben zeigen die Antworten nicht alle in dieselbe Richtung. Dann ist ein hybrides Vorgehen sinnvoll: Fixe Teile wie gesetzliche Pflichtangaben, eine Schnittstelle zu einem Fremdsystem oder ein unverrückbarer Starttermin werden vorab festgelegt. Alles, was die Kundschaft direkt erlebt, wird in Sprints entwickelt und mit Feedback verbessert. Wie man so ein gemischtes Vorhaben plant, vertiefst du in Lektion 9.

Was ändert sich bei Terminen und Kosten?

Jedes Projekt hat drei Grössen, die zusammenhängen: Umfang, Zeit und Kosten. Man spricht vom magischen Dreieck.

• Planbasiert wird der Umfang fixiert (Pflichtenheft). Zeit und Kosten werden geschätzt. Stimmt die Schätzung nicht, verschieben sich Termin und Budget.
• Agil dreht man das Dreieck um: Zeit und Kosten sind fix, weil ein festes Team in Sprints mit fixer Länge arbeitet. Der Umfang ist variabel. Er wird nach Wert geordnet, und das Wichtigste kommt zuerst.

Für die Fachabteilung ist das eine gute Nachricht: Wenn das Budget aufgebraucht ist, fehlen höchstens die am wenigsten wichtigen Funktionen. Bei einem verspäteten Wasserfallprojekt fehlt dagegen oft das ganze Produkt, weil der Test erst am Schluss kommt.

Schritt für Schritt: Noah vergleicht zwei Projekte

Sandra Moser bittet Noah, für die Geschäftsleitung kurz zu begründen, warum die Schadenmeldung agil umgesetzt wird. So geht Noah vor:

Schritt 1: Beide Vorhaben beschreiben.

Schritt 2: Die Kriterien für die Schadenmeldung beantworten.

• Anforderungen: unklar. Welche Angaben braucht es für einen Velodiebstahl, welche für einen Wasserschaden? Das weiss die Schadenabteilung erst, wenn sie Beispiele durchspielt. → agil
• Änderungen: wahrscheinlich, weil Kundinnen das Formular am Handy nutzen und Feedback geben werden. → agil
• Fachbereich verfügbar: ja, Sandra Moser ist zu 50 Prozent als Product Ownerin freigestellt. → agil
• Früher Nutzen: ja, schon eine einfache Meldung für Velodiebstahl entlastet das Telefon. → agil
• Fixe Vorgaben: Pflichtangaben (Policennummer, Schadendatum, Schadenort), Datenschutz und die bestehende Schnittstelle zum Schadensystem. → planbasiert für diese Teile

Schritt 3: Fixe Teile herauslösen. Die Pflichtangaben und die Anforderungen an den Datenschutz klärt Sandra Moser vor dem ersten Sprint mit dem Rechtsdienst. Die Schnittstelle zum Schadensystem ist vorgegeben und wird früh angebunden, damit Überraschungen nicht erst am Schluss auftauchen.

Schritt 4: Termine und Kosten abschätzen. Das Team umfasst sechs Personen und arbeitet in zweiwöchigen Sprints. Die Geschäftsleitung gibt sechs Sprints frei, also zwölf Wochen. Angenommen, ein Sprint kostet intern rund CHF 36'000, dann ist das Budget mit CHF 216'000 fix. Was in diesen sechs Sprints nicht Platz hat, kommt in eine spätere Ausbaustufe.

Schritt 5: Empfehlung formulieren. Noah schreibt:

«Wir empfehlen Scrum mit zweiwöchigen Sprints. Die Anforderungen an die Schadenmeldung sind noch unscharf, und die Kundschaft wird erst beim Ausprobieren merken, was fehlt. Nach zwei Wochen kann eine erste Version für Velodiebstähle getestet werden, und die Schadenabteilung gibt im Review direkt Rückmeldung. Pflichtangaben, Datenschutz und die Schnittstelle zum Schadensystem legen wir vor dem ersten Sprint fest. Zeit und Budget sind mit sechs Sprints fix, der Umfang wird nach Nutzen geordnet, sodass das Wichtigste sicher kommt.»

Schritt 6: Prüfen, ob die Begründung trägt. Noah liest die Empfehlung mit den Augen der Geschäftsleitung: Sind die Gründe konkret? Ist klar, was fix und was flexibel ist? Sind Termin und Kosten genannt? Alle drei Fragen kann er mit Ja beantworten.

Typische Fehler

• Agil als Ausrede für fehlende Planung. «Wir sind agil, also brauchen wir kein Ziel.» Falsch: Agile Teams brauchen ein klares Produktziel und planen in jedem Sprint.
• «Statt» lesen, wo «mehr als» steht. Wer das Manifest so versteht, dass Dokumentation verboten sei, lässt Betrieb und Kundendienst im Stich.
• Agil wählen, obwohl der Fachbereich keine Zeit hat. Ohne regelmässige Rückmeldung fehlt der wichtigste Vorteil. Dann ist entweder mehr Zeit des Fachbereichs nötig oder ein anderes Vorgehen.
• Alles oder nichts denken. Viele Vorhaben haben fixe Teile (Gesetz, Schnittstelle, Termin) und offene Teile. Ein hybrides Vorgehen ist dann keine Schwäche, sondern sauber begründet.
• Termine und Kosten vergessen. Wer agil empfiehlt, muss sagen, dass Zeit und Budget fix sind und der Umfang variiert.

Zusammenfassung

• Planbasiert fixiert den Umfang am Anfang, Feedback kommt spät. Agil liefert in kurzen Zyklen und holt früh Feedback.
• Iterativ = Zyklus wiederholen und verbessern, inkrementell = Produkt wächst in nutzbaren Stücken.
• Das Agile Manifest hat vier Werte. Das Linke zählt mehr, das Rechte bleibt wertvoll.
• Die Wahl begründest du mit Kriterien: Klarheit der Anforderungen, Änderungen, Verfügbarkeit des Fachbereichs, früher Nutzen, fixe Vorgaben.
• Bei gemischten Vorhaben werden fixe Teile vorab geplant, der Rest agil entwickelt (hybrid).
• Agil fixiert Zeit und Kosten, der Umfang ist variabel und nach Wert geordnet.