Wie überzeugt man Kunden von der agilen Zusammenarbeit?

Oder muss man das gar nicht?

Gerade in, aber nicht nur für Projektteams in der IT ist es das Nummer-1-Hindernis, wenn es um das Einführen von agilem Projektmanagement dreht: 

„Bevor wir wirklich agil arbeiten können, müssen wir die Kunden überzeugen, dabei mitzuziehen.“ 

Achtung Spoiler: Diese Aussage ist bei genauerer Betrachtung nur eine Nebelkerze, die von den wirklichen Problemen ablenkt. Doch eines nach dem anderen ... 
 

Das klassische Projektgeschäft orientiert sich am klassischen Projektmanagement und dessen Abrechnungsmodellen: Es wird ein Lasten- und Pflichtenheft erstellt (Analyse) und dies dient als Grundlage für einen Werkvertrag. Zu einem fixen Preis wird jetzt eine fixe Leistung geschuldet. Nach Lehrbuch folgen hintereinander weg das (Software-)Design, die Programmierung, die Implementierung, das Testen, die Abnahme und Auslieferung, sowie die Bezahlung. Ganz einfach und straight forward?

Mir ist in 26 Jahren Projektgeschäft nicht ein einziges Projekt begegnet, bei dem Kunden vor oder zu Beginn hinlänglich genau definieren konnten, was denn konkret gewünscht ist. So sind Lasten- und Pflichtenheft im Lichte der Realität eher bessere Absichtserklärungen und sicher keine geeignete Basis für einen Werkvertrag. Selbst wenn von Kundenseite eine solche, hinreichend genaue (und vollständige!) Anforderungsdefinition möglich wäre (was sie nicht ist), hätte man einzig eine Momentaufnahme. Wer sich nur ein wenig mit Requirements Engineering auseinandersetzt (was ich nur empfehlen kann), ist sich folgender Zusammenhänge bewusst.

Anforderungen an ein Werk leiten sich vom Systemkontext ab, in dem es zum Einsatz kommen soll. Dieser Kontext, also die Realität da draußen, verändert sich fortlaufend. Damit gilt immer (selbst im klassischen Projektmanagement):

Anforderungen sind grundsätzlich agil! Sie verändern sich ständig, und zwar bis zu ihrer Umsetzung.

Diese Binsenweisheit ignorieren wir gern. Ein guter Projektmanager oder Product Owner ist dann insbesondere die Person, die den folgenden Eiertanz zwischen Wunschdenken und Realität am besten absolviert. Zeit und Energie, sich um eine Wertmaximierung des Werkes zu kümmern, bleibt da nicht mehr viel. Damit leiden nicht nur der eigene Gewinn und die Kundenzufriedenheit, sondern auch die am Projekt beteiligten Menschen. Kein Wunder, dass man sich nach Alternativen umschaut: Wollen wir es nicht mal agil „versuchen“?

Die erste Überlegung im Rahmen dieser Versuche führt direkt zu der Schlussfolgerung, dass man sich von Lasten- und Pflichtenheft, sowie vom Werkvertragsrecht verabschieden müsse (ja, besser wäre es). Und weiter: “Ohne die Kunden überzeugt zu haben, auch den Werkvertrag aufzugeben, ist agiles Arbeiten bei uns gar nicht wirksam möglich.” Mit dieser K.O.-Annahme ist die beste Ausrede geschaffen, sich nicht weiter mit agilem, selbstorganisiertem Arbeiten wirklich, wirklich auseinanderzusetzen. Dazu fehlt Ihnen neben all dem Eiertanzen sowieso die Zeit, oder? ;-)

Doch stimmt das so? Müssen wir unsere Kunden erst überzeugen?

Es ist nicht am Kunden, sich zu Beginn des Projektes festlegen zu wollen oder nur zu können! Jeder Kunde ist sich dessen klar. Und wenn nicht, dann fragen Sie ihn doch mal nach Details seiner Wünsche und Anforderungen.
Hier eine Alternative anzubieten, die der Natur der Sache entgegenkommt, stellt nur ein Problem dar, wenn man selbst unklar mit diesem alternativen Vorgehen ist. Ist man klar, greifen Kunden entsprechende Vorschläge dankbar auf! Ich habe selten Kunden erlebt, weder KMU, Konzern und nicht einmal Kunden aus dem öffentlichen Sektor, die nicht mitgezogen hätten. 

Der Head of Global Marketing eines weltweiten Konzerns fragte mich “Ja ist denn heut’ schon Weihnachten? Und wo ist der Haken?” (Antwort: Regelmäßige, aktive Zusammenarbeit mit dem Dienstleister, was die Freude auf Seiten des Kunden nicht schmälerte.) Und eine Projektleiterin einer großen politischen Stiftung meinte: “Ja, logisch. Wenn das ganze Lasten-Pflichten-Brimborium wegfällt, kann ich endlich so mit dem Dienstleister arbeiten, wie ich es natürlicherweise tun würde.” – Ihre Kunden sind in der Regel längst bereit und müssen nicht überzeugt werden.

Es kommt den Kunden entgegen, wenn sie das Projekt während des Entstehens begleiten, es dann in der guten Zusammenarbeit und Kommunikation mit dem ganzen Projektteam gestalten und es auf diese Weise mit Sinn und Wert füllen können und dürfen. Beschäftigen Sie sich am besten intensiver mit agilem Projektmanagement und Requirements Engineering, um hier die notwendige Klarheit für sich selbst und im eigenen Hause zu schaffen.

Der zweite Punkt ist die Sache mit dem Werkvertrag. Das Werkvertragsrecht ist zwar ungünstig für die agile Projektumsetzung, was allerdings nicht an agilem Projektmanagement liegt, sondern daran, dass das Werkvertragsrecht in der komplexen Projektrealität grundsätzlich unpassend ist. Es wird immer Probleme bereiten. Wenn man einem Projekt unter Werkvertragsrecht mit klassischem Projektmanagement begegnet, sogar wesentlich mehr, als würde man intern konsequent und ernsthaft auf agile Arbeitsweisen umschwenken. Tatsächlich ergeben sich bei der Abkehr vom Werkvertragsrecht erhebliche Kostenvorteile und ein vermindertes Risiko – für beide Seiten. So lohnt sich die Überlegung, von Beginn der Kundengespräche an gar nicht mehr anders anzubieten.

Sind diese beiden Punkte geklärt, kommen wir zum letzten Punkt. Agiles Arbeiten ist im Kern insbesondere Eines: die Veränderung von Entscheidungsstrukturen im Team und der Organisation. Agiles Arbeiten ist ein der komplexen Projektnatur angepasstes Arbeiten. Mit einem nicht-komplexen, prozessorientierten Vorgehen nach Regelwerken und in bisherigen, vorgabegeprägten Entscheidungsstrukturen kommt man nicht weiter. Der Eiertanz bleibt. Agilität ist ein Fokuswechsel auf Selbstorganisation. Dafür müssen wir weiterdenken als nur bis zum agilen Manifest und zum Scrum Guide.

Wenn Sie also den Eindruck haben, Ihre Kunden wollen nicht agil zusammenarbeiten und deshalb wird es mit dem agilen Arbeiten bei Ihnen nichts, dann ist das irreführend. Es werden eben nur interne Probleme und Missverständnisse zum Thema agiles Arbeiten, Selbstorganisation und Requirements Engineering auf die Kunden projiziert. 

Ihre Kunden sind also nicht das Problem. Sie spiegeln Ihnen nur Ihre internen Probleme. Aber ‘ne geile Ausrede, um weiter mit Lasten- und Pflichtenheft zu jonglieren und den Eiertanz tanzen zu dürfen, ist’s halt schon ;-).