Hier ist die Sache: Bei Agilität hat der Kunde eine sehr wichtige Rolle zu erfüllen - wenn er nicht beteiligt ist, verliert Agilität viel von seinem Wert.
Wie überzeugt man Kunden davon, die Art und Weise, wie sie Projekte durchführen, zu ändern, insbesondere bei großen Unternehmen und zumindest mittelgroßen Projekten?
Ich schätze, sie glauben nicht einfach dem Verkäufer, der sagt: "Das ist besser." Und wenn sie nicht viel Erfahrung mit agilem Arbeiten haben, werden Kunden wahrscheinlich zurückhaltend sein. Wie bringen Sie sie also dazu, ihre Meinung zu ändern?
Schrittweise
Wenn Sie versuchen, Ihren Kunden (oder Chef, Management, Kollegen usw.) davon zu überzeugen, etwas völlig anders zu machen, als er es gewohnt ist, dann werden sie auf eine der typischen Arten als Reaktion auf Veränderungen reagieren : Akzeptanz , Panik, Ablehnung usw. Ich empfehle daher eine schrittweise Einführung agiler Methoden, bis Sie dort sind, zum Beispiel:
Beginnen Sie mit wöchentlichen Meetings mit dem Kunden, um die „priorisierten Anforderungen“ ( Feature Backlog ) zu besprechen. Stellen Sie sicher, dass die Prioritäten vom Kunden festgelegt werden und in Story Points - Einheiten (unter Anleitung von Ihnen) angegeben sind.
Wenn Sie Artikel zur Liste hinzufügen, schreiben Sie sie in der Sprache der „ User Story “, die jedoch vertraut genug ist, um den Kunden nicht zu verwirren/zu verärgern. Wenn Sie bereits eine Art von Spezifikation oder Anwendungsfällen haben, passen Sie sie an, aber geraten Sie nicht in Versuchung, sie komplett neu zu schreiben – der Kunde wird wahrscheinlich nicht in der Lage sein, den Sprung zu machen.
Liefern Sie regelmäßig Ergebnisse , damit der Kunde den Fortschritt und die Vorteile der neuen Arbeitsweise sehen kann. Stellen Sie sicher, dass sie wissen, was sie gerade erhalten haben, wie sie darauf zugreifen können (URL, Download-Site usw.) und sich vergewissern, dass sie es ausprobiert haben.
Holen Sie beim nächsten wöchentlichen Meeting Feedback zu diesen Ergebnissen ein, damit der Kunde das Feature Backlog entsprechend seiner Wünsche verfeinern kann. Nehmen Sie sich die Zeit, diesen Mechanismus „Top User Stories auswählen, implementieren, bereitstellen, überprüfen“ zu skizzieren, um das Konzept einer „ Iteration “ oder eines Sprints vorzustellen .
Weisen Sie jeder User Story Kostenschätzungen zu, damit der Kunde den Aufwand verstehen kann, der zum Erreichen jeder User Story erforderlich ist, und erfahren kann, wie viel in einer Iteration erreicht werden könnte. Seien Sie offen mit dem Kunden über das Planungsspiel , das verwendet wurde, um die Schätzungen zu erstellen.
Stellen Sie sicher, dass der Kunde sehen kann, wie viele User Stories bisher erreicht wurden (Budget verwendet) und ein klares Verständnis dafür bekommt, wie viele der verbleibenden Stories in der verbleibenden Zeit/im verbleibenden Budget abgeschlossen werden könnten.
Ich habe dies bei mehreren Kunden erfolgreich gemacht und festgestellt, dass sie uns, nachdem sie einige Wochen lang ihre Versprechen eingehalten hatten, von da an voll und ganz vertrauten und sich mehr darauf konzentrierten, welche Funktionen sie am dringendsten wollten, als darauf, ob wir liefern würden oder nicht. Wir haben sie nicht unbedingt mit der gesamten Terminologie konfrontiert, aber sie „bekommen“ die regelmäßigen Updates und die offene und ehrliche Diskussion darüber, welche Funktionen als nächstes implementiert werden.
An iterativen Projektmethoden (wie Agile, XP oder Scrum) ist nichts Beängstigendes, Falsches oder Seltsames , es ist einfach nicht die „traditionelle“ Wasserfallmethode. Eine nette menschliche Erklärung zu haben hilft:
Beim traditionellen Bauen können Sie die Fundamente nicht ändern, ohne zuerst ein Haus/Bürogebäude/eine Brücke niederzureißen. Dies ist einer der Gründe, warum Sie zuerst die Fundamente in Ordnung bringen müssen, bevor Sie mit den Wänden und dem Dach fortfahren.
In anderen Branchen können Sie jeden Teil des Systems ändern, ohne von vorne beginnen zu müssen. In der Formel 1 können Sie zum Beispiel das Auto zum Radwechsel aufbocken – Sie müssen nicht das ganze Auto zerlegen.
Daher eignen sich einige Projekte sehr gut für einen iterativen/zyklischen Ansatz, bei dem die anfängliche Lösung viele Male verfeinert wird, bis sie genau richtig ist.
Ich habe die Agile-Terminologie absichtlich vage verwendet, um die Botschaft einfacher zu vermitteln, und ich hatte einen langen Tag, also bin ich vielleicht etwas durcheinander gekommen.
Eine der guten Antworten ist „Du tust es einfach nicht“.
Es ist durchaus möglich, ein agiles Projekt durchzuführen, ohne dem Kunden genau zu zeigen, wie das Team arbeitet. Darüber hinaus wird der Kunde sehr oft nicht daran interessiert sein. Der Trick ist, dass sie nicht daran interessiert sein werden, auch Teil des Teams zu sein. Sie werden am Ende der Iteration nicht aktiv an der Priorisierung oder Produktdemo teilnehmen. In der Regel ist es hier die beste Methode, den Kunden innerhalb eines Projektteams nachzuahmen. Sehr oft ist die beste Person dafür ein Projektmanager, der den Kunden und die Vorzüge des Projekts gut kennt.
Eine andere Antwort lautet: Machen Sie es zu einer Win-Win-Situation
Eine Zeit lang dachte ich, es sei sehr, sehr schwer, eine Art agilen Vertrag zu erstellen, der für beide Seiten eine Win-Win-Situation darstellt und die Risiken auf beiden Seiten begrenzt: auf der Seite des Kunden und des Anbieters. Diese Präsentation von Paul Klipp (Folien sind hier ) ist die beste Herangehensweise an das Thema, die ich bisher gesehen habe. Es gibt beiden Seiten Anreize, schneller fertig zu werden, und teilt den Schmerz, mit dem durch Umfangsänderungen verursachten Ausrutscher fertig zu werden.
Sie können auch versuchen, sie zu zeigen
Dieser ist knifflig, da davon ausgegangen wird, dass Sie den Kunden davon überzeugen können, es zu versuchen. Ein ziemlich gutes Argument, das ich gehört habe und das die Meinung des Kunden ändern kann, ist jedoch, den Kunden das Projekt nach den ersten zwei oder drei Iterationen kostenlos aufgeben zu lassen. Dann haben Sie etwas Zeit, um den Wert Ihres Ansatzes aufzuzeigen und möglicherweise zu präsentieren, wie das Engagement des Kunden dazu beigetragen hat, das Ergebnis dieser ersten Iterationen zu verbessern.
Beide bereits gegebenen Antworten sind ausgezeichnet und ich unterstütze sie. Ich wollte nur eine modifizierende Fabrik hinzufügen. Bei einem kürzlichen Agile-Panel machte einer der Redner eine sehr gute Beobachtung. „Wenn die Dinge funktionieren und gut laufen, wird es sehr schwierig sein, jemanden dazu zu bringen, auf ein völlig neues System umzusteigen. Eine Umstellung auf Agile wird besser ankommen, wenn die Dinge bereits kaputt sind.“
Dann müssen Sie Ihre agile Antwort darauf zuschneiden, was tatsächlich kaputt ist. Sie stürzen sich nicht einfach hinein und „Go Agile“, Sie müssen sehen, was passiert ist, und davon migrieren.
Mark, als Berater/Coach können Sie sich nicht mehr verändern wollen als Ihr Kunde. Sie müssen sich ändern wollen und das kann bedeuten, dass Sie danebenstehen und sie scheitern lassen müssen. Vielleicht scheitern sie bereits, können es aber einfach nicht sehen. Sie können versuchen, darauf hinzuweisen, aber dies ist ein kniffliger Abhang, der oft zur Fragmentierung der Beziehung führt. Es ist besser, einen Schritt zurückzutreten und später wieder eingeladen zu werden, wenn sie bereit sind, sich zu ändern.
davidepiazza
amphibisch