Wenn man sich in der Scrum-Community heute so umhört, dann stellt man schnell fest, dass die meisten Personen aus der Ecke der Softwareentwicklung kommen. Also eher die Auftragnehmerseite. Die Auftraggeberseite ist jedoch zumeist so gut wie gar nicht vertreten. Doch warum ist das so? Sind agile Methoden für die Auftraggeber nicht attraktiv genug? Oder liegt es vielleicht eher daran, dass die betroffenen Entscheidungsträger noch nichts darüber gehört haben?
Unsere bisherige Erfahrung sagt uns, dass eher Letzteres der Fall ist, denn Scrum bietet dem Auftraggeber sehr wohl eine Reihe von Vorteilen (sie auch der letzte Artikel über „Scrum und Festpreisverträge“). Für alle, die keine Lust haben, diesen Artikel nachzulesen, seien die wichtigsten Punkte an dieser Stelle nochmal wiederholt:
- Dem Auftraggeber ist es erlaubt, bisher unbearbeitete Anforderungen durch Neue auszutauschen. Dadurch erspart man sich teure Change Requests (betrifft v.a. Festpreisverträge)
- Da Software bei Scrum iterativ entwickelt wird, ist es möglich, am Ende jeder Iteration steuernd auf das Projekt einzuwirken (üblich sind hier 4 Wochen). So kann man zu jeder Zeit die Kontrolle darüber behalten, wie sich das Produkt weiterentwickelt.
- Ein iterativ entwickeltes System kann natürlich auch leicht schrittweise ausgerollt werden. Ein Big-Bang ist nicht notwendig. Das verringert das damit verbundene Risiko erheblich, hat aber auch andere Vorteile, z.B. geringere Kosten für Mitarbeiterschulungen.
- Es ist möglich, ein Projekt vorzeitig abzubrechen und dennoch ein lauffähiges System zu bekommen. Dies kann z.B. bei Budgetkürzungen der Fall sein, aber auch, wenn der erreichte Entwicklungsstand gut genug ist. So kann man sogar erreichen, das gewünschte Produkt für weniger Geld als vorgesehen zu bekommen – wann gab es das schon mal?
Darüber hinaus fallen mir aber auch noch eine Reihe weiterer Vorteile ein:
- Man erhält sehr schnell lauffähige Software, auch wenn diese noch nicht den gesamten Funktionsumfang aufweist. Dieser wird jedoch Schritt für Schritt mit jeder Iteration steigen.
- Die Abnahme (und damit auch Bezahlung) kann somit immer anhand ausgelieferter Funktionalität erfolgen. Aufwendige Abnahmetests sind nicht mehr nötig.
- Es müssen bei Projektstart noch nicht alle Anforderungen an das Produkt bekannt sein. Stattdessen kann man sich Schritt für Schritt vorarbeiten und muss sich erst dann festlegen, wenn die Entwicklung an diesem Punkt angelangt ist.
Diese Liste erhebt natürlich keinen Anspruch auf Vollständigkeit und kann sicherlich noch erweitert werden (Vorschläge hierzu am besten einfach per Kommentar). Wenn also so viele Gründe dafür sprechen, warum fordern Auftraggeber heute dann Agilität nicht noch viel vehementer ein als bisher? Auch hierfür fällt mir einiges ein:
- Die bei Agilität übliche konstante Mitarbeit des Auftraggebers stellt an diesen höhere Anforderungen als bisher. Neben dem damit verbundenen höheren (Zeit-) Aufwand denke ich hier v.a. an Entscheidungskompetenzen, da vom Auftraggeber verlangt wird, verbindliche Entscheidungen in relativ kurzer Zeit zu treffen. Nicht jede Organisation kann das jedoch leisten.
- Die Entscheider haben keine IT-Kultur. Sie begreifen das Problem der Software-Entwicklung nicht. Gerade bei fachfremden Entscheidern scheint sich bis heute hartnäckig der Eindruck zu halten, dass Software einfach zu spezifizieren und trivial zu programmieren wäre, ohne größeres Risiko. Dass gerade bei Individualsoftware (um die es hier ja geht), in der überwiegenden Mehrheit der Fälle jedoch eher das genaue Gegenteil der Fall ist, scheint sich dagegen bisher noch nicht sehr weit rumgesprochen zu halten.
- Gerade bei größeren Unternehmen treten oft auch organisatorische Zwänge auf. Verträge mit auf Agilität ausgelegten Klauseln (wie im Artikel „Scrum und Festpreisverträge“ vorgeschlagen) sind oft einfach nicht vorgesehen. Sie zu installieren, wäre jedoch für ein einzelnes Projekt ein zu aufwendiger Prozess, der ewig dauert, und dessen Ausgang ungewiss ist. Also lässt man es lieber.
Und schließlich natürlich noch der trivialste, aber meiner Meinung nach zugleich auch der wichtigste Grund:
- Scrum ist in vielen Unternehmen einfach noch unbekannt. Es sollte daher unsere Aufgabe sein, dies zu ändern und das Wort hinaus in die Welt zu tragen. Vielleicht schaffen wir es, dass Scrum mal in der Tagesschau kommt :-).
Andererseits: Vielleicht sind hier auch wir als Auftragnehmer mehr gefordert unseren Kunden „ein Angebot zu machen, das sie nicht ablehnen können“. Hier greife ich gerne die Idee meines Kollegen Olivier Guillet auf, der vorschlägt, Angebote auf zwei verschiedene Weisen zu kalkulieren und dem Kunden selbst die Entscheidung zu überlassen:
- Agil, mit kürzerer Laufzeit, mit Flexibilität bei den Anforderungen, konstanter Mitarbeit des Kunden und einem auf Stundensätzen basierenden Vertrag, der aber im Normalfall zu einem geringeren Preis als bei Festpreisverträgen führt (auch wenn dieser Preis hier natürlich nicht garantiert werden kann)
- Standard-Festpreis-Modell: Längere Laufzeit, geringere Involvierung des Kunden („Über-den-Zaun“-kompatibel), dafür mit einem garantierten Festpreis, aber teurer als Variante 1.
Und selbst wenn ein Kunde dann immer noch einen Standard-Festpreis-Vertrag verlangt, so kann man ihm die angesprochenen Modifikationen vorschlagen, um etwas Agilität in den Vertrag zu bringen. Die Chancen hierfür stehen nicht schlecht: Uns sind bereits erste Beispiele für Unternehmen bekannt, die speziell an Scrum angepasste Verträge eingeführt haben, und dies sogar aktiv von ihren Auftragnehmern einfordern. Da der erreichte Effizienzgewinn für sich spricht, ist es wohl nur noch eine Frage der Zeit, bis Agilität zum Standard wird.
Mir wäre es jedenfalls recht…
BFE
Wird geladen ...