Um Scrum zu implementieren, reicht es nicht einfach, die Entwicklung umzustellen: Die ganze Organisation und das Denken müssen sich ändern. Dies ist in der Praxis – besonders in Vertragsverhältnissen zwischen Lieferanten und Kunden – nicht immer voll möglich. Das Scrum-Reifegradmodell zeigt die unterschiedlichen Implementierungsmöglichkeiten im Hinblick auf die Vertragsgestaltung.

Jeder Kunde und jedes Projekt ist anders und bedarf eines anderen Vorgehens in der Vertragsgestaltung und der Implementierung des Prozesses und der Rollen. Der Kunde weiß in der Softwareentwicklung immer erst was er wirklich braucht, wenn er mit der Lösung arbeitet¹. Doch nicht jeder Kunde ist in der Lage seine Prozesse, seine Verträge und sein Denken an ein wirklich agiles Vorgehen anzupassen.

Das Scrum Reifegradmodell zeigt unterschiedliche Möglichkeiten, Scrum in einem Projekt zu implementieren.

Scrum light

Wenn ein Kunde nicht davon zu überzeugen ist, dass er am Anfang des Projektes noch nicht genau weiß, was die beste Lösung für ihn ist, dann kann man ihn nicht zwingen, agil vorzugehen. Dasselbe gilt für Ausschreibungen oder vermittelte Festpreisverträge. In diesem Fall bietet es sich an, Scrum als reine Entwicklungsmethode für die Umsetzung zu verwenden.

Die Rolle des Product Owners ist dann mit dem Projektleiter des Lieferanten/Auftragnehmers zu besetzen. Das Projekt wird mit allen Iterationen zu Beginn durchgeplant. Es sollte in jedem Fall mit dem Kunden vereinbart werden, dass nach jedem Sprint eine Teilabnahme der umgesetzten Funktionalitäten erfolgt.

Nutznießer bei dieser Implementierung ist vor allem der Lieferant. Er reduziert sein Risiko durch frühes und regelmäßiges Liefern und das Feedback und die Teilabnahmen des Kunden. Der Kunde wird sich bei den vermutlich auftretenden Änderungswünschen durch das frühe Feedback aber immer mit der Tatsache konfrontieren müssen, dass jede Änderung ein Change Request und damit kommerziell zu vergüten ist.

Scrum medium

Um den Problemen mit den Change Requests zu begegnen, kann mit dem Kunden ein fester Change-Prozess definiert werden. Eine Möglichkeit ist, ein festes Change-Kontingent zu vereinbaren, das im Bedarfsfall einfach in Anspruch genommen wird. Eine andere Möglichkeit ist das Exchange-For-Free-Prinzip. Dabei kann der Kunde neue Anforderungen hinzufügen, wenn er gleichzeitig andere gleicher Komplexität streicht oder komplexere um das entsprechende Maß reduziert. Eine Kombination beider Varianten ist ebenfalls möglich.

Das Modell eignet sich vor allem für Kunden, zu denen man schon ein gutes Verhältnis hat, die aber intern an starre Prozesse oder Vorgaben gebunden sind, die echtes Scrum verhindern. Die Rollenbesetzung sollte auf jeden Fall so gewählt werden, dass der Product Owner vom Lieferanten gestellt wird. Dieser kann aber die Abarbeitung der Anforderung in enger Abstimmung mit dem Projektleiter von Kundenseite wählen.

Bei diesem Vorgehen profitieren schon beide Seiten von der Agilität. Es besteht aber die Gefahr, dass es zu Streitigkeiten über die Komplexität von Inhalten kommt – besonders, wenn das Projekt doch den ursprünglich geplanten Rahmen übersteigt. Beide Projektleiter brauchen dabei ein gutes Verhältnis zueinander und müssen vertrauensvoll und kooperativ zusammenarbeiten.

Echtes Scrum

Bei echtem Scrum akzeptiert der Kunde, dass er die beste Lösung zu Beginn noch nicht kennt. Er bestellt also quasi komplette Sprints beim Lieferanten auf Basis einer ganz groben Kostenschätzung. Die Form der Zusammenarbeit kann natürlich nur über einen Dienstvertrag zustande kommen.

Da der Kunde damit das volle Risiko trägt, sollte die Rolle des Product Owners auch durch diesen besetzt werden. Die Projektleitung des Lieferanten würde dann die Rolle des Scrum-Masters einnehmen.

Der Kunde steuert die Anforderungen und damit die Entwicklung über den Product Owner. Reichen die bestellten Sprints nicht aus, um das Projektziel (die Vision) zu erreichen, muss der Kunde weitere Sprints bestellen – er trägt das alleinige Risiko. Wird das Ziel in weniger Sprints erreicht, sollte dem Kunden vertraglich die Möglichkeit gegeben werden, das Projekt vorzeitig zu beenden. Dies ist bereits bei der Vertragsgestaltung zu berücksichtigen. Natürlich sollte der Ausstieg mit einer gewissen „Kündigungsfrist“ ausgestattet werden, um Stehzeiten und Mehrkosten beim Lieferanten zu vermeiden.

Da das komplette Risiko beim Kunden liegt, eignet sich diese Art der Zusammenarbeit ebenfalls nur, wenn bereits ein enges Vertrauensverhältnis zwischen Kunde und Lieferant besteht. Außerdem muss der Kunde in der Lage sein, die Agilität wirklich zu leben: Die Fachabteilungen benötigen ausreichend Ressourcen und müssen fest in den Prozess mit eingebunden werden.

Agiler Festpreis

Die steigende Agilität erkauft sich der Kunde durch ein steigendes Risiko (siehe Abbildung 1). Aus diesem Grunde schrecken viele Kunden davor zurück, eine solche Vertragsform einzugehen. Abhilfe kann ein Kooperationsvertrag wie der „Agile Festpreis“[iii] schaffen. Er regelt die Zusammenarbeit und balanciert die Interessen von Auftragnehmer und Auftraggeber aus.

Beim agilen Festpreis handelt es sich um einen indikativen Maximalpreis. Diesen errechnet der Lieferant auf Basis von geschätzten Anforderungen (in Story Points). Dabei wird ein Teil der Anforderung komplett geplant und der Aufwand anhand der Story Points auf den Rest des Projektes hochgerechnet. Auf das Ergebnis wird dann noch ein Sicherheitsaufschlag addiert, der mit dem Kunden abgestimmt ist. Durch dieses Vorgehen ist es möglich, den Scope wirklich variabel zu halten und nur auf einem hohen Abstraktionsniveau zu schätzen (Siehe Abbildung 2).

Um die Interessen beider Parteien auszugleichen, schlagen die Autoren noch einige Besonderheiten vor:

• Riskshare
• Checkpoint-Phase
• Ausstiegspunkte

Läuft das Projekt nicht wie geplant, dann teilen sich beide Parteien den Mehraufwand im Rahmen des Riskshares. Dabei wird der Mehraufwand vom Lieferanten zu einem reduzierten Tagessatz berechnet. Die Größe des Riskshares sollte in einem realistischen Rahmen (30 bis 70%) liegen, damit keine der beiden Parteien übervorteilt wird.

Zu Beginn des Projektes kann eine Checkpoint-Phase vereinbart werden, in der die gemeinsame Arbeit getestet wird. In dieser Phase wird i.d.R. ein für den Kunden sehr attraktiver Riskshare vereinbart. Als Umfang bietet sich eine Größe von zwei bis fünf Sprints an. Nach der Checkpoint-Phase haben beide Parteien die Möglichkeit, das Projekt zu beenden. Das Projekt wird dann entweder im Rahmen des Riskshares „rückabgewickelt“ oder zu 100% vergütet und die Software dem Kunden übergeben. Entschließen sich die Parteien für eine Weiterführung des Projektes, dann ist der Checkpoint auch der Meilenstein, an dem die Schätzungen nochmals justiert und die Erfahrungen aus den ersten Sprints in die Vereinbarungen integriert werden. Außerdem kann der indikative Maximalpreis hier in einen echten Festpreis umgewandelt werden.

Durch das agile Vorgehen kann das Ziel des Projektes auch schon lange vor dem geplanten Ende erreicht werden. Für diesen Fall sollten im Vertrag Ausstiegsmöglichkeiten vorgesehen werden und im Falle eines frühen erfolgreichen Endes die Ersparnis über ein „Bonus“ zwischen Kunde und Lieferant geteilt werden. Dies stellt sicher, dass keiner der Parteien daran interessiert ist, das Projekt so lange wie möglich zu verzögern. Die Ausstiegspunkte sollten natürlich auch mit einem entsprechenden Vorlauf angekündigt werden, damit dem Lieferanten kein Mehraufwand entsteht.

Damit der Kunde den Lieferanten bei dieser Vertragsart nicht übervorteilen kann und der Maximalpreis nicht überschritten wird, ist es besonders wichtig, den Umgang mit den Anforderungen (Scope-Governance) genau und detailliert zu regeln. Neue oder sich ändernde Anforderungen können gegen gleichwertige getauscht (Exchange-For-Free) oder durch Komplexitätsreduktion einer anderen Anforderung kompensiert werden. Dasselbe gilt, wenn der Umfang einer User Story außerhalb des Rahmenvertrages liegt. Auch dann versuchen beide Parteien gemeinsam die Komplexität zu reduzieren, um wieder in den Rahmen zu gelangen. Geht das nicht, so kann auch die Komplexität von anderen User Stories reduziert werden, damit der Mehraufwand kompensiert wird. Der Kundennutzen sollte natürlich bei diesem Prozess immer erhalten bleiben. Gelingt dies nicht, startet der Scope-Eskalationsprozess. Dieser könnte z.B. in der ersten Instanz an das Steering-Board übergeben werden. Führt dies zu keiner Einigung, dann kann als nächste Instanz ein unabhängiger Sachverständiger dienen, der zu Beginn von beiden Parteien gemeinsam bestimmt wird.

Fazit

Das Reifegradmodell kann zu Projektbeginn helfen, ein Projekt und einen Kunden einzustufen und den maximalen Vorteil für den Kunden und für den Lieferanten zu ermöglichen.

Das Mehr an Agilität bedeutet aber für den Kunden auch immer ein Mehr an Risiko. Bei einer guten, kooperativen Beziehung zwischen Lieferant und Kunde ist dieses Risiko aber überschaubar. In diesem Fall ist es für den Kunden die beste Methode, einfach ganze Sprints auf einer Time & Material Basis zu bestellen und die Steuerung selbst zu übernehmen. Dies geht natürlich nur, wenn der Kunde von den Prozessen und vom Denken her bereit ist, sich auf echtes Scrum einzulassen. Wenn nicht, dann versucht man den Reifegrad immer zu reduzieren, bis man die richtige Stufe erreicht hat.

Sind Kunden generell in der Lage und willens echtes Scrum zu implementieren, scheuen aber das Risiko durch einen neuen Lieferanten, so kann hier ein agiler Kooperationsvertrag nach Vorlage des „Agilen Festpreises“ Abhilfe schaffen. Dieser komplexe Vertrag hat natürlich einen starken Overhead, der letztendlich vom Kunden mitfinanziert werden muss. Er balanciert aber sehr gut die Interessen von Kunde und Lieferant aus und kann zu einer guten und kooperativen Zusammenarbeit führen, die später dann auch in eine einfachere Vertragsform überführt werden kann.

Für den Anbieter gilt generell: je mehr Scrum desto besser. Er reduziert dadurch sein Risiko und hat die Chance, sich als guter Partner zu erweisen. Allerdings kann man Kunden nicht zu Scrum zwingen. Ist der Kunde nicht bereit, sich am Projektrisiko zu beteiligen, dann ist es vielleicht besser, nach „Scrum light“ intern zu entwickeln, die Anforderungen aber klassisch im Vorhinein zu planen.

---

¹Ken Schwaber, Agile Project Management With Scrum, Microsoft Press

²Andreas Opelt / Boris Gloger / Wolfgang Pfarl / Ralf Mittermayer, Der Agile Festpreis, Hanser 2012