Während Banken und Versicherungen über Jahrzehnte hinweg dieselben Projektmethoden verwendeten, erfordern immer kürzer werdende Produktlebenszyklen längst auch von ihnen ein Umdenken. So sind agile Methoden in der Produktentwicklung kaum mehr wegzudenken. Wieso der Schritt in die Agilität dennoch nicht ganz einfach ist und wie du als Projektleiter*in damit umgehen kannst, erfährst du in diesem Blogbeitrag.
Der Trend hin zu agilen Vorgehensmodellen ist auch in der Schweiz seit vielen Jahren klar festzustellen. Kein Wunder also, begeben sich jährlich zahlreiche Unternehmen auf die Reise hin zur (versuchten) Agilität. Doch während agile Methoden insbesondere in innovationsstarken Branchen (etwa in der Elektrotechnik, der Fahrzeugindustrie oder der IT) grossen Anklang finden, zeigen sich Banken und Versicherungen doch recht verhalten. So erkennt man zwar auch hier die Vorteile, welche agile Methoden mit sich bringen, ist jedoch noch nicht gänzlich gewillt, auf bewährte Methoden, etwa das Wasserfallmodell, zu verzichten. Gründe hierfür finden sich insbesondere in der Forderung nach fix vereinbarten Anforderungskatalogen sowie Ressourcen-, Zeit- und Kostenrahmen, an deren Einhaltung der/die verantwortliche Projektleiter*in schlussendlich gemessen wird. Entsprechend werden so lange Zusatzregeln gefordert (und vereinbart), bis die einst agile Methodik so zweckentfremdet ist, dass diese nicht wiederzuerkennen ist. Das Resultat ist sodann meist ein Mischwesen – halb Fisch, halb Vogel – welchem kaum Überlebenschancen zugesprochen werden können. Hier ist es Aufgabe des Projektleiters / der Projektleiterin, an die Regeln des gewählten Vorgehensmodells (etwa Scrum, SAFe, Extreme Programming (XP) oder Kanban) zu erinnern und diese durchzusetzen.
Besonderheiten agiler Vorgehensmodelle
Generell lassen sich nachfolgende Besonderheiten identifizieren, deren Akzeptanz du im Projektvertrag festhalten solltest:
Kosten- und Ergebnisoffenheit: Während es beim Wasserfallmodell bereits früh möglich ist, eine (erste) Aussage zur Projektkalkulation und -planung zu machen, ist dies bei Scrum und Co. nicht gegeben. Da sich die Priorisierung einzelner Anforderungen / Stories im Laufe des Projektes mit grösster Wahrscheinlichkeit ändern wird, ist eine Aussage zum finalen Lieferobjekt, zur Timeline sowie zu den Kosten, nicht möglich. Verzichte daher zwingend auf Fixpreisangebote.
Testzeitpunkt und -automatisierung:
Während das Testing bei klassischen Projekten erst am Ende erfolgt, ist bei agilen Projekten während jedem Sprint ein entsprechendes Testfenster einzuplanen. Erkannte Fehler werden im Product Backlog erfasst. Um den Testaufwand möglichst niedrig zu halten, solltest du eine Bibliothek automatisierter (Regressions-)Tests erstellen.
Qualität und Umfang erarbeiteter Lieferobjekte:
Wie bei Punkt 2 bereits erwähnt, werden Fehler, die während des aktuellen Sprints nicht mehr umgesetzt werden können, ins Product Backlog aufgenommen und stehen dort in Konkurrenz zu bereits erfassten Anforderungen. Ein Recht auf Nachbesserung (oder kostenlose Umsetzung der im Backlog erfassten Bugs), wie es beim Wasserfallmodell oft der Fall ist, besteht zwar auch bei agilen Methoden – insbesondere wenn die Umsetzung nicht den definierten Anforderungen entspricht – jedoch beeinflussen allfällig notwendige Nachbesserungen unmittelbar die Velocity kommender Sprints. Das Entwicklungsteam benötigt einen kontinuierlichen Verbesserungs- und Lernprozess, um Fehler möglichst frühzeitig zu erkennen (oder zu mitigieren), um so die Velocity verbessern zu können. Da notwendige Korrekturen somit jeweils in direkter Konkurrenz zu den restlichen Stories stehen, solltest du zwingend darauf verzichten, einen fixen Leistungsumfang zu vereinbaren.
Sofern du die Akzeptanz dieser Besonderheiten in verbindlicher Form im Projektvertrag abbilden kannst, so steht der Wahl einer agilen Methodik grundsätzlich nichts mehr im Weg. Andernfalls könnte es ratsam sein, dich mit deinem Auftraggeber auf ein klassisches Vorgehen zu einigen.
Weiterführende Links
https://agilemanifesto.org/iso/de/manifesto.html
https://www.scrum.org
