“Agil gegen Widerstände” – vier mögliche Ansätze, Kunden von agilen Ansätzen zu überzeugen!
Selbst, voller Glauben an agile Vorgehensweisen in Softwareprojekten, kommen wir in Kundengesprächen schnell in die Rolle von Evangelisten der Agilen Idee. So versuchen wir nicht nur, den Kunden davon zu überzeugen, dass wir es als Team fachlich und technologisch drauf haben. Wir haben auch noch den Anspruch, ihm innerhalb von Minuten die Vorzüge agiler Prinzipien und die Nachteile klassischen Projektmanagements aufzuzeigen.
Die Erfahrung zeigt: Das klappt nicht. Nach Minuten des Monologs lauten die Antworten meines Gegenübers: „Alles klar. Wenn Sie so agil sind, dann können Sie ja morgen starten!“ oder „Ist ja schön und gut mit der Agilität – welchen Preis kann ich denn jetzt in meine Wettbewerbsvergleichsexceltabelle eintragen?“. Es braucht also einen Ansatz, wie man Kunden, die noch nicht „agil erleuchtet“ sind, zu erreichen. Ich möchte Euch kurz an meinen Erfahrungen teilhaben lassen:
Ansatz 1: Bottom up
Starten wir mit Ansprechpartnern, die wissen, von was wir reden. In einigen IT-Projekten sitzen auf der Auftraggeberseite Software-Experten, die von den Vorteilen von Scrum & co. wissen, sich aber gegenüber Management und Einkauf nicht nach vorne wagen. Wenn wir nicht nur das Vertrauen dieser Ansprechpartner gewinnen (was über fachliche Erfolge schnell gelingen sollte) – sondern wir zusätzlich noch Informationen, Schulungen, Tools bereitstellen, so sollten wir es doch schaffen, dass wir die Entscheider gemeinsam vom „richtigen“ Weg überzeugen.
Meiner Erfahrung nach kann das in mittelständischen Unternehmen, in denen Entscheider und Geschäftsführer offen für Veränderungen sind, gelingen. In größeren, hierarchisch aufgebauten Unternehmen stoßen wir jedoch oft auf eine für die vorgebrachten Ideen und Methoden undurchlässige Lehmschicht.
Ansatz 2: Eat Dust!
Es ist auch eine sehr überhebliche Herangehensweise, als Dienstleister besser wissen zu wollen, was gut für den Auftraggeber und sein Projekt ist. Außerdem katapultiert man sich in Ausschreibungen und Wettbewerbssituationen mit einer agilen Denke und ehrlichen Aussagen zum Budget ins Abseits. Also machen wir einfach das Spiel mit dem (Neu-)Kunden eine Runde lang wider besseren Wissens mit, versuchen sein Vertrauen zu gewinnen und orientieren uns nach dem ersten Projekt neu.
Will man den Kunden überzeugen, so heißt dies: Liefere rechtzeitig, in hoher Qualität und 110 Prozent vom Scope. Im Klartext: “Friss Staub, Dienstleister!” Die Kunst hier: Die eigenen Mitarbeiter dürfen nicht die Leidtragenden sein, sonst können wir das nächste (agile) Projekt mit neuem Personal planen. Außerdem stellt sich für den Kunden die offensichtliche Frage: Warum sollte ich mein nächstes Projekt anders angehen – es hat ja alles wunderbar funktioniert!
Ansatz 3: Learning by Burning
Die Option, dass ein Projekt scheitert, wird häufig nicht akzeptiert. Bei hohen Erwartungen des Managements und fehlenden Erfolgsvoraussetzungen im Projekt, kommen wir häufig trotz der Absicht mit Ansatz 2 (Eat Dust) das Ruder herumreißen zu wollen, in Situationen, wo das mögliche Scheitern allen Beteiligten bewusst wird und sich große Nervosität breitmacht.
So bekam ich Ende letzten Jahres ganz unverhofft zwei Tage vor Weihnachten die Möglichkeit, mal eben hunderte Kilometer quer durch Deutschland zu reisen, um für 20 Minuten die Geschäftsführung eines Großkonzerns zu beruhigen. Es war sicherlich für niemanden ein Wunschtermin. Alle Beteiligten hätten lieber Vorbereitungen für das Weihnachtsfest getroffen. Erstaunlicherweise zeigten die Herren sehr großes Interesse an alternativen, agilen Vorgehensweisen. Vermutlich auch, weil ihnen die Problematik der klassischen Vorgehensweise schon in anderen Projekten begegnet war.
Dieser Ansatz ist sicherlich nicht der goldene Weg und eine absichtlich herbeigeführte Notlage ist mit unseren Wertvorstellungen als vertrauenswürdiger Dienstleister nicht vereinbar. Trotzdem kann eine solche Situation ein guter Neuanfang für die weitere (agile) Zusammenarbeit sein.
Ansatz 4: Forget about it!
Warum eigentlich soll der Kunde agil ticken? Kann der Kunde überhaupt agiles Projektmanagement in einer klassisch aufgestellten Organisation, wie einem Großkonzern, einer Behörde oder Genossenschaft mit vielen Stakeholdern durchführen? Muss der Kunde wirklich einen ausgebildeten Product Owner bereitstellen oder können wir einen Proxy-PO stellen? Als gute Dienstleister müssen wir uns in einer solchen Situation in beiden Welten sicher bewegen können und als Scharnier zwischen klassisch und agil fungieren.
Meiner Meinung nach ist dieser Ansatz eine valide Möglichkeit, aber führt zu hohem Aufwand im CRM.
Fazit: Es kommt auf den Kontext an
Wie so oft im Leben – es gibt nicht die eine beste Lösung. Der Kunden- und Projektkontext gibt einem Hinweise auf valide Möglichkeiten. Manche Erfahrungen muss man (leider) gemeinsam sammeln und in offenen Gesprächen ausloten, wie die Zusammenarbeit am besten funktioniert. Ganz gleich, ob noch klassisch oder schon agil – viele Kunden erkennen mittlerweile, dass die Welt sich verändert und im Zuge der digitalen Transformation etwas passieren muss.
Wollen Sie Ihr Unternehmen auch agiler machen? Wir beraten Sie gern!