Immer wieder höre ich in Gesprächen mit Teilnehmern und Kunden Sätze, die dem Sinn nach lauten, dass Teams zwar gern nach agilen Vorgehensweisen arbeiten möchten, doch dass die Kunden dieser Teams das nicht zulassen. „Das macht mein Kunde nicht mit!“
Nun verstehe ich das Arbeiten nach agilien Prinzipien so, dass es in diesen Vorgehensweisen eben genau darum geht: höhere Kundenzufriedenheit, engere Zusammenarbeit, schnellere Releases, größeres Vertrauen, besser funktionierende Software, mehr Sicherheit, etc. Die ganze Liste eben. Das steht doch im klaren Wiederspruch zu der Aussage: „da machen wir nicht mit“.
Was ich nun gern wüsste ist, wie es zu solchen Aussagen kommt. Wieso „machen Kunden Agilität nicht mit“? Mit anderen Worten: was genau brauchen Ihre Kunden um „Agilität mitmachen“ zu können? Was sind also die größten Hindernisse, nach agilen Vorgehensweisen zu arbeiten?
Ich freue mich auf Ihre Antworten!
Hallo Frau Christel,
wir arbeiten derzeit nur intern in der Produktentwicklung agil. (Noch) nicht aktiv mit unseren Kunden. Daher kann ich natürlich nur mutmaßen und mich nicht auf echte Erfahrungswerte stützen. Aber manche Dinge habe ich evtl. unbewusst kennen gelernt, als wir diese Methodik intern eingeführt haben.
Auch wir haben uns am Anfang überlegen müssen, wie wir das Thema zum Leben erwecken können. Für mich klingt ein Satz wie “Das macht mein Kunde nicht mit!” eher nach weißer Flagge, bevor die Schlachte eigentlich angefangen hat.
Oder noch schlimmer: Man weiß selbst nicht was man eigentlich unter agiler Methodik zu verstehen hat und kann es demnach auch nicht verkaufen.
Zentrale Punkte sind also:
– Wie erwecke ich das Thema zum Leben?
– Wie kann ich meinem Kunden den Mehrwert / Nutzen verkaufen?
– Wie gewinne ich das Vertrauen meines Kunden und kann ihm Sicherheit geben?
Ich persönlich bin der festen Überzeugung, dass diese Arbeitsweise sehr viele Vorteile bringt – für beide Seiten.
Der Kunden ist extrem dicht am Entwicklungsprozess, sieht in kurzen Abständen Ergebnisse und kann sogar jederzeit steuernd eingreifen.
Das Team lernt direkt vom Kunden und bekommt so ein besseres Verständnis der Prozess und Anforderungen.
Beide Seiten können nur gewinnen. Man kann nicht vorher schon aufgaben. Gerade wenn man daran glaub, dass eine agile Vorgehensweise Vorteile bringt und auch dem Kunden hilft, muss man sich mit seinem Kunden intensiv auseinander setzen. Die Vorteile liegen ja auf der Hand.
Ich persönlich kann mir an dieser Stelle auch vorstellen, dass gerade in den höheren Managementebenen erst mal Skepsis herrscht, wenn es um agile Entwicklung geht.
Aber auch hier muss man Energie aufwenden und sein Anliegen vertreten und mit den Leuten in einen Dialog gehen.
Kurz zusammen gefasst denke ich sind es 2 Punkte:
– Zum einen wird einfach nicht energisch genug versucht einen agilen Ansatz einzubringen
– und zweitens wird es auf Kundenseite durch die oberflächliche Darstellung schnell abgeblockt. Es ist was unbekanntes, es ist nicht verstanden und somit verlässt man sich lieber auf altbekannte Weisheiten.
Würdest du beim Bau deines Eigenheims ein agiles Vorgehen schätzen? Du möchtest doch von vorn herein wissen, was du am Ende bekommst und was der Spaß kostet. Oder?
Olli
Hallo Olli,
wen sprichst du an?
Also gerade bei der agilen Arbeitsweise weiß ich ja vorher was ich bekomme und auch welcher Aufwand bzw. welche Kosten dahinter stecken.
Viele Grüße
Jan
Hallo Allerseits
Ja “Das macht mein Kunde nicht mit!” hört man ja öfter mal ;o)
Zusammenarbeit mit Kunden heisst aber eben nicht: „ich hab ne ganz tolle Idee, aber der Kunde ist zu doof dafür“. Sondern Umgang mit Kunden bedeutet doch gerade, in der Lage zu sein diesen „bei der Hand zu nehmen“.
Würde mal behaupten, dass es sehr häufig an dieser Kompetenz im Allgemeinen mangelt. Zum „Einsteigen“ gibt es da aber sicherlich erst einmal einfachere Themen als gleich komplette agile Vorgehensweisen.
Grüsse
markus kerz
Hi Oli,
also ich habe mein Haus iterativ gebaut! Die Iterationsdauer betrug einen Tag. Ich war jeden Tag auf der Baustelle und habe einen Akzeptanztest der aktuell entstandenen Iterationsergebnisse durchgeführt und ggf. auch das Backlog umpriorisiert bzw. neue User-Stories eingearbeitet.
Mein Nachbar hat allerdings nach Wasserfall gebaut: Pläne absegnen, 8 Monate später einziehen. Nach welchem Vorgehensmodell die daraufhin losgebrochene Prozesslawine gehandhabt wird, weiß ich leider nicht.
Also für mich klingt der Job des ProductOwners nach sch.. viel Arbeit. Und außerdem muss ich als Kunde auch noch die Budgetverantwortung übernehmen. Achja und noch den Job des Projektleiters (Priorisierung und das ganze Zeug). Und hinterher bin ich auch noch ergebnisverantwortlich. Och nö … da bleib ich doch lieber bei dem bewährten Verfahren:
Spezifikation: Mach mich glücklich.
Budget: Warum ist das schon wieder so teuer?
Ergebnisverantwortung: Die EDV hats mal wieder verbockt.
Warum sollte ein Kunde was anders machen?
@Guido: Natürlich ist das Arbeit. Aber die Arbeit entsteht sowieso. Nur in einem Beispiel wie Du es schilderst auf viel unangenehmere Art & Weise. Nämlich meistens dann, wenn es schon viel zu spät ist.
Gegen Ende der Entwicklung. Auf ein mal fallen Fehler auf, es fehlen Funktionen, alle sind unzufrieden und man versucht per Schnellschuss noch etwas zu retten.
Im agilen Ansatz liegt gerade in der Spezifikationsphase sehr viel Aufmerksamkeit. Und zwar für beide Seiten, weil es nämlich ein Zusammenspiel ist.
Am Ende will ich ja so viel Funktionen wie möglich, auf einem qualitativ sehr hochwertigen, zu einem möglichst günstigen Preis.
Und dies erreiche ich meiner Meinung nach nicht dadurch, dass sich jeder hinsetzt und Arme und Beine weit von sich streckt und sagt: Ich Verantwortung? Nein, danke. Die EDV ist schuld!
Die EDV wird sagen: Ja, wenn Ihr die Anforderungen so schlecht formuliert und nie Zeit habt, dann müsst Ihr Euch nicht wundern.
Daher das Zusammenspiel. Die Parteien sitzen in einem Tisch, können klar die Dinge der anderen Partei einfordern. Sind unheimlich nah beieinander und bewegen sich auf dem gleichen Level.
Treffen verbindliche Aussagen und commiten sich auch verbindlich auf ein Ergebnis / Ziel. Damit bleibt auf der Blick auf die Kosten / Aufwände immer verfügbar und meiner nach auch realistisch.
Jeder muss in die Verantwortung rein und diese auch wahrnehmen und leben. Sowohl das Team als auch ein Product Owner / Projektleiter oder auch ein Kunde.
Gerade dem Kunden wird was dran liegen am Ende ein begeisterndes Produkt zu bekommen. Nur: Von nix kommt nix. Da muss er mit ran.
Meine Erfahrung zeigt, dass – auch wenn eine solche Prozedur oft anstrengend ist – am Ende ein sehr glücklicher vorhanden ist. Weil er immer das Gefühl hat Herr der Lage zu sein. Er jederzeit steuernd eingreifen kann. Er jederzeit beraten wird, aber dennoch die Entscheidungshoheit besitzt. Und: er auch die „andere Seite“ besser kennen und verstehen lernt.
Wendet Ihr bei Euch agile Methoden an?
Hallo Jan-Erik,
ich bin selber CSP … daher kann ich mich gut in den Kunden reinversetzen ;)
Christels Frage war doch: „Wieso machen Kunden Agilität nicht mit?“ – und das war meine etwas überzeichnete Antwort.
Weniger überzeichnet: Scrum (et.al.) laden praktische alle Verantwortung beim ProductOwner ab. Budget, Termin, Inhalt, Risiko – alles darf (oder muss) der ProductOwner im Griff haben. Und das Team braucht nur noch Programmieren und den ScrumMaster bei Laune halten. Naja, ok, ein bisschen Commitment noch …
Natürlich bekommt der Kunde was dafür – aber früher war das Leben doch einfacher! Man gibt einen mehr oder weniger guten Wunschzettel ab und bekommt hinterher mehr oder weniger was man braucht – auf jedenfall ist man hinterher für evtl. Fehlschläge nicht verantwortlich.
Wenn man Agilität erstmal erfahren hat, dann sieht man die Sache sicher anders, aber die Einstiegshürde ist ganz schön hoch für den Kunden.
Hallo Guido,
also ich finde das ein wenig pauschal. Klar hat der PO viel Verantwortung & nimmt eine sehr zentrale Rolle ein.
Auf der anderen Seite ist es nach meiner Erfahrung so, dass es bei einem Kunden nicht diese eine Superinstanz gibt. Also eine Person, die wirklich über alles entscheidet.
Hinter einem PO bzw. Projektleiter beim Kunden steht ja noch das Management, die gerade beim Budget, etc. als Ansprechpartner und auch Entscheider agieren können / sollten.
Ich denke, dass macht auch Sinn, weil auch ein PO, Projektleiter braucht Partner in seinem Unternehmen mit denen er zusammen arbeiten kann.
Hallo,
ich bin als PM zeitgleich in 2 Projekte gekommen. Beide Projekte waren zerschossen. Meine Aufgabe ist, die beiden Projekte zu retten. Mein Vorgänger hat mit klassischem PM die Projekte in den Sand gesetzt. Ich denke das dabei Grundlegende Fehler im PM gemacht worden sind.
Keine eindeutige Spezifikation und nicht erkennen von Risiken.Ich kann zurzeit nur agil arbeiten. Der klassische Ansatz würde in diesem Stadium keinen Fortschritt bringen.In der Regel bevorzuge ich eine Kombination aus der klassischen Methode und der Agilen Vorgehensweise.
Ziele sollten sauber und klar definiert werden. Im Projekt können ruhig agile Ansätze angewendet werden.
Danke!
Das Thema hat mich nicht ruhen lassen. So habe ich eine kleine Geschichte geschrieben: „Weihnachten nach Scrum Manier“
Viel Spaß!