Wer bereits in grösseren Softwareprojekten mitgearbeitet hat, weiss: Nichts in einem Projekt ist so konstant wie die Veränderung. Agile Methoden wie Scrum bieten die notwendigen Tools, um flexibel auf diese Veränderungen einzugehen.
Doch wie lässt sich ein Auftraggeber, der sich nur mit klassischen Vorgehensweisen wie Hermes und co. auskennt, von einer agilen Vorgehensweise überzeugen? Diese Blogpost-Reihe teilt Erfahrungen, die wir bei Puzzle über die Jahre gesammelt haben und bietet eine Schritt-für-Schritt Anleitung, wie man diesem Problem begegnen kann.
IT-Projektmanagement im Spannungsfeld klassisch-agil
Einen potenziellen Kunden aus einem klassischen Umfeld von den Vorteilen agiler Methoden zu überzeugen, ist nicht immer einfach. Spätestens wenn es um das Vertragliche geht oder der CFO eine genaue Projektkalkulation verlangt, wird es schwierig. Häufig wird dann der Ansatz gewählt, nur während der Realisationsphase agil vorzugehen, die Anforderungen aber vorab in einem Pflichtenheft zu spezifizieren. Viele Vorteile der Agilität gehen dadurch verloren. Das muss nicht sein! Wenn gewisse Voraussetzungen gegeben sind, die wie Puzzlesteine ineinander spielen, lässt sich ein Projekt auch mit vorsichtigen Auftraggebern agil abwickeln.
Dies führt uns zu Schritt 1: Ressentiments in Begeisterung verwandeln.
Angst vor Kontrollverlust? Nicht nötig…
Wenn du dich mit deinem potenziellen Kunden zusammensetzt und ihm Scrum ans Herz legen möchtest, wird er dich vielleicht erst einmal folgendes fragen:
„Wieso sollte ich agil vorgehen wollen, wenn ich dadurch die Kontrolle über das Projekt und den Lieferanten verliere? Erfolgreiche Projekte sind erfolgreich dank klar definierten Prozessen, beispielhafter Führung und guter Kontrolle…“
Die grösste Angst dieses Projektleiters ist die Angst vor Kontrollverlust. Schliesslich dienen die klar definierten Prozesse, wie sie etwa im PMBoK oder Hermes beschrieben sind, in erster Linie dem Projektcontrolling. Nur, diese Kontrolle, die man in einem klassischen Projekt zu haben scheint, ist eine vermeintliche. Erst gegen Ende eines Projektes erkennt der Kunde, was er effektiv für sein Geld erhält. Erkläre ihm also, wie er mit Scrum stets die Kontrolle über sein Projekt behält: durch den laufenden Einbezug des Kunden, die kontinuierliche Lieferung von Produktinkrementen und einer offenen Kommunikation hat der Auftraggeber eine wesentlich höhere Kontrolle über den Projektfortschritt als in einem klassischen Projekt. Durch weniger Eigenständigkeit des Teams in einem klassischen Projekt werden nicht weniger Fehler gemacht, sie werden nur besser vertuscht – dies zieht aber wesentlich höhere Folgekosten nach sich.
Agilität = Chaos!? Von wegen…
Der Projektleiter in unserem Beispiel gesteht ein, dass man auch in einem Scrum Projekt eine gewisse Kontrolle haben kann, aber:
„Mit Scrum gibt es keine richtige Planung, das ist ein willkürliches und chaotisches Vorgehen!“
Wir entgegnen darauf, dass Agilität nicht mit Planlosigkeit und Chaos zu verwechseln ist. Ganz im Gegenteil: Scrum ist ein strukturiertes Vorgehen mit definierten Rollen und Meetings. Anstatt eine ausgiebige Planungsphase der Umsetzung vorauszusetzen, wird zu Beginn lediglich ein Grobkonzept erstellt. Erzähle ihm davon, wie du zu Beginn des Projekts mit ihm gemeinsam ein Zielbild, beispielsweise mit Mockups entwickeln willst, um die Anforderungen zu visualisieren und zu verfeinern. Daraus entsteht dann das Product Backlog, das laufend ergänzt und neu priorisiert werden kann. Dieses Vorgehen geschieht systematisch und ist alles andere als planlos. Im Gegensatz zu einem klassischen Projekt ist Planung nicht nur eine Aktivität zu Beginn des Projekts, sondern geschieht kontinuierlich und wird laufend der Realität angepasst – der wohl grösste Vorteil eines agilen Projekts. Sage dem Kunden also, dass er darüber bestimmt, was er am Ende für ein Produkt erhalten wird.
Keine Dokumentation? Weit gefehlt…
„Nun gut, vielleicht ist Scrum gar nicht so unstrukturiert, wie ich dachte. Aber ich werde zu meiner Software keine Dokumentation erhalten. Die brauche ich aber!“, wagt unser fiktive Kunde ein letztes Argument.
Er wird wohl vom agilen Manifest gehört haben, das funktionierende Software höher wertet als eine umfassende Dokumentation. Dass dadurch eine Dokumentation ausgeschlossen wird, ist allerdings ein Trugschluss. In einem klassischen Wasserfallmodell wird am Ende jeder Projektphase eine umfassende Dokumentation geschrieben. In agilen Projekten ist dieser Prozess viel zeitnaher und effizienter. Versichere ihm, dass eine Story erst abgeschlossen wird, wenn die Dokumentation nachgezogen wurde. Dokumentiert wird aber nur, wenn es der Umfang des Projekts verlangt und wenn es dem Kunden effektiv einen Nutzen bringt. Der Zweck einer Dokumentation muss dem Entwicklungsteam und dem Kunden jederzeit klar sein – sonst kann man sich die Zeit sparen.
Mit diesen Argumenten konnten einige hartnäckige Ressentiments gegenüber Scrum entschärft werden, ein guter Grundstein ist gelegt. In Schritt zwei gilt es nun, gegenseitiges Vertrauen aufzubauen. Dazu mehr im nächsten Blogpost.
Habt ihr ähnliche Erfahrungen gemacht? Wie geht ihr vor, um eure Kunden von agilen Methoden zu überzeugen? Wir freuen uns auf eure Kommentare!