Die Basis von agilen Projekten - Die Auftragsvergabe
In Teil 1 unserer Reihe zu agilen Projekten erfahren Sie alles ĂĽber die Auftragsvergabe
Als das Scrum-Framework vor ca. 20 Jahren erstmals vorgestellt wurde, lag der Fokus auf der internen Software-Entwicklung. Auch heute sind der Scrum-Guide oder auch andere agile Frameworks darauf ausgerichtet, dass sämtliche Tätigkeiten in der gleichen Unternehmung abgewickelt werden. Für Projekte zwischen Auftraggebern und Dienstleistern bieten agile Frameworks häufig keine fertigen Lösungen, Best Practices und Antworten, wie agile Projekte durchzuführen sind. Und somit ergeben sich in agilen Projekten in diesem Setup einige zusätzliche Herausforderungen, welche zu berücksichtigen sind. In dieser Blogpost-Serie möchte ich drei Bereiche vorstellen, welche eben solche Herausforderungen und Spannungen verursachen können. Welche Herausforderungen sind in Namics Projekten aufgetreten? Wie konnte diesen begegnet werden? Basis für die drei Blogposts ist meine Präsentation am Agile Breakfast von swissICT am 29. November 2016.
Potenzielle Herausforderungen
Namics stellt fest, dass Auftraggeber vermehrt agile Projekte planen und ausschreiben. In Ausschreibungen dieser Art wird oft ein bestimmter Scope mit Angabe eines Fertigstellungsdatums erwähnt, zudem oftmals mit der Bitte um eine Investitionsempfehlung auf Basis eines kalkulierten Preises. Dies steht natürlich in Widerspruch zur agilen Projektmethodik, welche sich dem „klassischen Projektdreieck“ nicht wirklich vereinbaren lässt. Eine grosse Herausforderung ist es also, wie man als Dienstleister mit solchen Anforderungen in der Ausschreibungsphase umgeht und es schafft ein überzeugendes Angebot zu formulieren. Im Kern geht es um die Aufteilung von finanziellen, terminlichen und qualitativen Risiken zwischen den beiden Parteien.
Sowohl der Auftraggeber als auch wir als Dienstleister möchten die möglichen Risiken verständlicherweise reduzieren.
Eine weiteres herausforderndes Szenario ergibt sich, wenn der Auftraggeber kein agiles Projekt erwartet und ausschreibt, wir als Dienstleister & agiler Berater jedoch denken, dass sich das Projekt sehr gut für eine Durchführung nach einem agilen Framework eignen würde. Wie können wir den Kunden davon überzeugen, das Projekt agil durchzuführen?
Mögliche Lösungsvorschläge
Den mehrdimensionalen Anforderungen bezüglich Scope, Zeit und Preis ist mit einem agilen Projekt aus unserer Erfahrung nur sehr schwierig zu begegnen. Was in erster Linie hilft, ist das Schaffen von Vertrauen. Dem Aufbau einer gegenseitigen Vertrauensbasis sollte in einer jungen oder noch nicht existenten Geschäftsbeziehung höchste Aufmerksamkeit geschenkt werden. Dies kann bereits in der Angebots-Phase starten, indem man in sogenannten Chemistry Workshops eine „Kostprobe“ der zukünftigen Zusammenarbeit gibt.
Für die konkrete Zusammenarbeit gibt es verschiedene Möglichkeiten, wie man agil vorgehen kann:
- Time & Material: Der Kunde bezahlt das Team für eine gewisse Zeit und dieses arbeitet am Product Backlog. Auch wenn es meiner Meinung nach ein sehr effizientes Vorgehen ist (man hat keine grossen Overhead-Kosten, keine Diskussionen bzgl. verändertem Scope, usw.) und in kurzer Zeit ohne künstlichen Hürden die erwähnte Vertrauensbeziehung beweisen kann, sind viele Auftraggeber nicht bereit, in diesem Modus zu arbeiten, da sie, ihrer Ansicht nach, zu wenig Kontrolle über Preis und Scope haben. Dies ist aus unserer Sicht allerdings ein Trugschluss. Aus unserer Sicht ist dieses Vorgehensmodell auch für den Auftraggeber der Idealfall. So kann möglichst prozessoptimiert einem Ziel entgegengearbeitet werden. Controlling wird durch Transparenz und Vertrauen ersetzt. Der Kunde hat volle Kontrolle und Verantwortung über das Backlog und somit über den Scope und dessen Kosten.
- Minimal Viable Product (MVP): Der Auftraggeber beauftragt den Dienstleister für eine fixe Anzahl Sprints zu einem fixen Preis. Dabei wird vereinbart, dass spätestens bis Ende dieser Zeit ein Minimal Viable Product fertiggestellt ist. Hierbei ist es wichtig, dass das MVP nicht zu einer detaillierten Spezifikation wird. Viel eher soll es dem Kunden aufzeigen, dass er mit diesem Vorgehen nach x Sprints ein lauffähiges Produkt erhält und nicht ein Konzept, das sich dann noch mehrmals ändert. Bei mangelndem Vertrauen kann ein definiertes MVP auch ein Risiko sein, dann Diskussionen zum vereinbarten Inhalt des MVP entstehen können.
- Agiler Festpreis: Der Kunde beauftragt einen bestimmten Scope-Umfang, der in relativer Grösse geschätzt wird. Der Scope-Umfang bleibt konstant, allerdings können sich die einzelnen Anforderungen innerhalb dieses Scopes verändern. Backlog Items können somit ausgetauscht und verschoben werden, solange der Umfang gleich bleibt.
Ein Modus, mit welchem wir gute Erfahrungen gemacht haben, ist eine Mischung zwischen den oben erläuterten Modellen.
- Zu Beginn wurde eine Kalibrierungs-Phase nach Time & Material durchgefĂĽhrt. FĂĽr x Sprints wurden nach T&M verrechnet. Danach hat man analysiert, wie viele Story Points in dieser Zeit umgesetzt wurden und wie viel ein Story Point im Durchschnitt gekostet hat.
- Danach wurden Teilprojekte stets mit Story Points offeriert: Der Scope-Umfang eines Teilprojektes wurde relativ zu vergangenen Anforderungen geschätzt. Durch die Menge der geschätzten Story Points konnte danach der Gesamtumfang des Teilprojekts offeriert werden.
- Während der Umsetzung konnten – wie beim agilen Festpreis – einzelne Items ausgetauscht werden, solange die Anzahl Story Points innerhalb des Teilprojekts gleich blieb.
- Doch auch dieses Modell hat seine Schwächen. So liegt der grössere Teil des Risikos bei uns als Dienstleister und Story Points werden zu einer Art Währung. Zudem kann diese Abrechnungsart eine beeinflussende Wirkung auf die Schätzungen des Scrum-Teams haben.
Wichtige Grundlagen für dieses Vorgehen sind Transparenz und Vertrauen. Nur wenn das Vertrauen zwischen Dienstleister und Auftraggeber vorhanden ist, ist ein solches Vorgehen möglich.
