“Ihr macht SCRUM? Und wie macht Ihr das als Dienstleister?”
Wenn wir mit Bekannten und Kunden darüber sprechen, welches Vorgehen wir bei uns in der Softwareentwicklung einsetzen, dann hören wir häufig diese Frage. So verlockend SCRUM auch ist, es scheint sich auf dern ersten Blick nicht so sehr für den Einsatz als Dienstleister zu eignen. Es sprechen offensichtlich zwei Gründe dagegen:
- SCRUM ist ein iteratives Vorgehensmodell. Es ist quasi Teil der Philosophie, dass zu Beginn des Projektes nicht der gesamte Umfang des Projektes definiert ist und sich dieser Schritt für Schritt aus den Fortschritten des Projektes entwickelt.
- Der Kunde und seine Ansprechpartner kennen z.T. nicht die Notwendigkeiten eines Software-Projektes. Sie verstehen sich daher nicht als Teil des Projektes und sind kaum in der Lage, die Rolle des Product Owner richtig zu spielen. Und wer kann sonst der Produkt Owner sein, wenn nicht der Kunde?
Und um es gleich vorweg zu nehmen: wir haben auch noch keinen Königsweg gefunden. Anhand unserer Erfahrungen aus dem letzten Jahr können wir aber einige Ideen mitgeben:
Zu Punkt 1 muss man zunächst auf das deutsche Gesetz schauen, damit das Dilemma klar wird. Wenn man zu einem Festpreis einen sog. “Werkvertrag” mit dem Kunden abschließt, dann schuldet man dem Kunden für den Werklohn den “Erfolg”. Man muss also das “Werk” fertigstellen und zwar so, wie es mit dem Kunden vereinbart wurde. Wenn es keine Definitionen zum Werk gibt, dann schuldet der Auftragnehmer ein Ergebnis mit den “durchschnittlichen” Eigenschaften, die man so erwarten dürfte. Diese Rahmenbedingung zwingt den Dienstleister, Rahmen und Umfang der gewünschten Software zu definieren. Das ist völlig unabhängig von SCRUM. Und ebenso unabhängig von SCRUM stellt es den Dienstleister vor die Aufgabe, ein Angebot abzugeben, zu dem er am Ende stehen muss. Als Dienstleister muss ich also im Falle eines Werkvertrages den Gesamtumfang kennen und eine Schätzung des Umfanges haben, zu der ich stehen kann. Dies ist kein SCRUM Problem und wird auch mit SCRUM nicht gelöst (was man irrtümlich jedoch hofft).
Alternativ kann man auf eine vertrauensvolle Zusammenarbeit mit dem Kunden bauen und eine Entlohnung nach Aufwand vereinbaren. Das ist für den Dienstleister bequemer, verlagert das finanzielle Riskio jedoch auf den Auftraggeber, ohne auch die Entscheidungshoheit auf den Auftraggeber zu verlagern, sofern er Kunde keine Ahnung von Softwareprojekten hat. Insofern ist dieser Ansatz wohl nur etwas für Dienstleister-Kunden-Beziehungen, denen ein hohes Maß an Vertrauen zugrunde liegt.
Zu Punkt 2: Wenn der Kunde die Rolle des Product Owner nicht kennt, dann muss man ihm helfen. So einfach ist das – und so schwer umzusetzen. Wenn der Kunde nämlich jemand ist, der sich nicht selber bemüht, diese Rolle auszufüllen, dann muss der Dienstleister dem Kunden jemanden zur Seite stellen, der diese Arbeit in Vertretung des Kunden übernimmt. Im einfachsten Fall könnte das ein sehr bemühter SCRUM Master sein, der nie müde wird, den Kunden immer wieder anzusprechen, hinzuweisen und einzubinden. Aber auch ein Berater, der keine andere Aufgabe hat, als die Visionen des Kunden “anwaltlich” zu übernehmen wäre denkbar.
Beide Punkte zeigen mal wieder eines: SCRUM ist kein Heilmittel, dass problemloses Projektmanagement ohne Aufwand verspricht. Es ist ein Werkzeug, das richtig eingesetzt werden muss, damit es seine ganze Macht entfalten kann.
