Sie starten ein agiles Projekt. Als Scrum Master sind Sie Facilitator und unterstützen den Product Owner sowohl bei der Erstellung als auch bei der Pflege des Backlogs. Sie koordinieren auch die externe Kundenkommunikation, um über den Fortschritt des Projekts zu berichten.
Ihr selbstorganisiertes Team ist bereit, die Sprints für das Projekt zu starten.
Alles ist eingerichtet, aber stellen Sie sich vor, dass Kunden, die an diesen agilen Ansatz nicht gewöhnt sind und sich der Iterationen in Test-Sprints nicht bewusst sind, nur auf das endgültige Ergebnis warten, um alles wie im klassischen Ansatz zu testen.
Wie schulen Sie bzw. gehen Sie mit Ihren Kunden um, die agiles Vorgehen noch nicht kennen?
BEARBEITEN:
Nehmen wir an, dass Sie, nachdem Sie Ihr Projekt bereits gestartet und Ihren anfänglichen Umfang/Ziele festgelegt haben, Ihre 2-wöchigen Sprints für alle zu erstellenden Funktionen mit Daten und dem, was getestet werden soll, erstellen und wie jede Funktion das Ziel erfüllt (Erwartung später als Eingabe für eine neue Iteration verwendet werden).
Aber wie gesagt, der Kunde hat keine "Ressourcen", um die Ergebnisse zu testen und viele Rückmeldungen zu den Ergebnissen zu geben, da er an den klassischen Ansatz gewöhnt ist, bei dem Sie erwarten, alle Informationen von der Konzeption an zu sammeln und die Daten bis zur Ausführung etwas zu verfeinern, dann später, was sie wollen Testaufwand später durchzuführen (Dies könnte fehlschlagen und zu Nacharbeiten führen) Erklären Sie als Scrum Master die Vorteile des Ansatzes, Sie erklären ihnen den gesamten Prozess, aber sie sind immer noch nicht überzeugt. 2 Risiken hier:
Da Ihr Team bereits agil ist, ist es selbstorganisiert und befähigt, seine Sprints mit dem Product Owner zu verwalten. Du hast als normaler PM nicht die "Kontrolle" . Verstehen Sie mich nicht falsch, ich finde den agilen Ansatz super, um motivierte Teams zu bilden und Kreativität zu verbreiten.
Welche Strategien haben Sie aus Erfahrung im Umgang mit Kunden ohne Erfahrung in agilen Vorgehensweisen?
Dies ist eine komplexe Frage, da sie von zwei Dingen ausgeht:
1) Sie haben erkannt, dass ein Teil des Problems bei den meisten Softwareentwicklungsbemühungen darin besteht, dass Sie zum Ende gelangen und feststellen können, dass Sie zwar genau das gebaut haben, wonach gefragt wurde, aber nicht das, was benötigt wurde, und daher zu Scrum übergegangen sind ; und
2) Ihr Kunde hat entschieden, dass er trotzdem bis zum Ende warten wird, um Ihnen zu sagen, ob es trotzdem richtig ist.
Für Ihr erstes Risiko weiß ich nicht, dass dies etwas mit Agilität zu tun hat. Das Problem bei Softwareprojekten mit Fixkosten bestand schon immer darin, dass sie außer Kontrolle geratene Kosten verursachen können. Selbst wenn es einen festen Umfang gibt, werden die meisten Unternehmen niemals sagen: „Sie haben den Umfang, nehmen Sie ihn oder lassen Sie ihn“ – es schadet ihrem Ruf zu sehr, was bedeutet, dass Sie nur die Kosten tragen. Ich kann die Anzahl der Unternehmen nicht zählen, die ich im Laufe der Jahre deswegen untergehen sah, unabhängig vom Projektmanagementansatz. Was Scrum zu diesem Gespräch beiträgt, macht es dem Kunden tatsächlich sicher, einem Zeit- und Materialvertrag zuzustimmen, da er einen stetigen Fortschritt sieht, ihn jederzeit abbrechen kann und den Fortschritt behalten kann bis dahin aufgeholt.
Für das zweite Risiko vermute ich, dass sie die Frage möglicherweise nicht verstehen. Sie müssen keine stundenlangen UAT-Tests durchführen. Sie müssen alle zwei Wochen zu einer zweistündigen Überprüfung erscheinen. Wenn jemand bereit ist, die Kosten Ihres Unternehmens für die Entwicklung von Software zu bezahlen, aber weder 2 Stunden seiner eigenen Zeit zur Verfügung stellt noch jemanden ernennt, der ihn vertritt, würde das einige wichtige rote Fahnen für mich aufwerfen. Auch dies ist jedoch nicht wirklich ein agiles Problem. Projekte sind aus diesem Grund jahrzehntelang abgestürzt und verbrannt. Viele der Agile- und Scrum-Praktiken wurden entwickelt, um dieses bestehende Problem zu entschärfen.
Das allererste, was aus meiner Sicht hier zu beachten ist:
Sind Ihre Projektanforderungen fixiert/eingefroren?
Wenn die Antwort auf die obige Frage ja lautet, ist das Risiko, dass die endgültigen Ergebnisse nicht den Erwartungen des Kunden entsprechen, möglicherweise gering. Ich gehe davon aus, dass das Projektteam den Umfang und die genauen Produktanforderungen verstanden hat und über die richtigen Fähigkeiten, Werkzeuge und ausreichend Zeitplan/Zeit verfügt, um die Qualitätserwartungen des Kunden zu erfüllen.
Hier ist der klassische Ansatz, dem Kunden eine endgültige Leistung für seine UAT zu erbringen, weniger riskant.
Ein agiler Ansatz wird natürlich empfohlen, wenn das Projekt ein hohes Maß an Änderungen erfährt. Wenn dies auf Ihr Projekt zutrifft, ist ein aktives Engagement und die Teilnahme mit Projektbeteiligten/Kunden ein Muss.
Wenn der Kunde nun über weniger Ressourcen/Bandbreite verfügt, können Entwicklungsteam und Kunde häufig Informationen und Projektstatusaktualisierungen in einem dynamischen und co-kreativen Prozess wie einer schnellen Demo von 20 Minuten austauschen. wobei der Kunde wichtige Module/Komponenten des Projekts präsentiert.
Diese Art regelmäßiger Interaktionen mit Kunden gibt ihnen ein Gefühl dafür, „wo wir im Projekt stehen“, baut Vertrauen auf und gibt einem Projektteam auch die Möglichkeit, Anpassungen (falls erforderlich) an Projektergebnissen vorzunehmen.
Erik
Venture2099
Maximus Decimus