Big-4-Scrum-Berater gibt schlechte Ratschläge – richtig oder durchfallen lassen?

Ein agiler Coach wurde berufen, um Agilität in einer großen Bank zu fördern. In einem seiner Teams besteht die Hälfte des Teams aus externen Beratern, die seit 3-4 Jahren dabei sind. Sie implementieren derzeit Sales Force.

In den Worten des zertifizierten Scrum Masters des Teams ist ihr Softwareentwicklungslebenszyklus:

  1. Führen Sie etwa 1,5 Monate lang eine High-Level-Analyse durch. In dieser Phase erstellt jeder Benutzergeschichten, da der Product Owner (PO) zu beschäftigt ist, um alle Benutzergeschichten zu schreiben, die aus all den Workshops stammen, die derzeit stattfinden, um die Systemspezifikationen zu sperren . Sie behaupteten, dass diese 1,5 Monate der Entdeckung und des Designs notwendig seien, da es eine massive Verbindung zwischen den Teilen in Sales Force gebe und dass sie im Voraus entscheiden müssten, was sie implementieren könnten und was nicht (basierend auf externen Abhängigkeiten).
  2. Erstellen Sie ein Backlog mit allen User Stories, die während der Sprints vom PO priorisiert werden, und führen Sie Sprint-Planungssitzungen durch. Liefern Sie in einem „Sprint“ – iterativ für 3 Monate
  3. Letzte 3 Monate, Backend-/Integrationstests mit den restlichen bestehenden Systemen.

Der Berater erwähnte sogar, dass eine umfassende Dokumentation erforderlich ist, falls etwas schief geht, und dass sie auf die Schuld zurückgreifen müssen, damit die Beratung klar ist.

Sie machen derzeit Stand-ups (?), um zu berichten, was sie gestern getan haben und was sie heute tun werden, aber kein Planungstreffen oder Retrospektive, da sie sich in der "Entwurfsphase" befinden.

Der agile Coach hat dies mit ein paar anderen Managern angesprochen und sie sagten mit einem Augenrollen: "Ja, diese (Name des Beraters hier) machen es auf ihre eigene Weise und haben ihre eigene Agenda."

Die PO ist eindeutig voreingenommen, dem Ansatz der Beraterin zu folgen, da sie eine Weile zusammengearbeitet haben und sie eine Zeit lang Programmmanagerin war und dann zu einer PO konvertierte.

Haben Sie ähnliche Erfahrungen mit externen Beratern gemacht, die behaupten, es herausgefunden zu haben, aber alles falsch verstanden haben, aber innerhalb eines Unternehmens stark positioniert sind?

Sollte der agile Coach eine Praxis durchsetzen und behaupten, dass alles, was sie tun, agil ist, oder sollte er sie scheitern lassen und den Schmerz spüren, bevor er eingreift?

Versuchen Sie, nicht so viele Akronyme zu verwenden. Ich habe die entfernt, die ich konnte, aber ich bin mir nicht sicher, was Sie mit "SF" gemeint haben. Und warum die (?) nach Stand-Ups?
SF = Verkaufspersonal. Habe es korrigiert. Weil sie versuchen, einen Stil durchzusetzen, den ich persönlich für nutzlos halte. Da die Arbeit festgelegt und endlich ist, finde ich die morgendliche Besprechung wenig sinnvoll. Nichts ist falsch daran, ich denke nur, dass es nur ein Overhead ist, so wie es aussieht. "Ok, du hattest dein Meeting, jetzt geh zurück, um deine eigentliche Arbeit zu erledigen."

Antworten (3)

Ich war in einer ähnlichen Situation (in einer Privatkundenbank) mit Beratern, die das anboten, was sie „Enterprise Agile“ nennen. Das Ergebnis war ein Wasserfall und höchst problematisch.

Die Beratungsunternehmen sind in der Regel sehr gut darin, Lobbyarbeit zu leisten (insbesondere bei der Exekutive). Es kann also eine Herausforderung sein, sie anzurufen.

Ich würde Ihrem Agile-Coach empfehlen, Folgendes zu tun:

  • Vereinbaren Sie zunächst, welche Kennzahlen Sie mit Agile verbessern möchten (z. B. Time-to-Market)
  • Schlagen Sie vor, einige Projekte/Teams mit einem echten agilen Ansatz und einige mit dem von den Beratern vorgeschlagenen Ansatz zu leiten
  • Timebox die Auswertung
  • Sehen Sie am Ende des Zeitfensters, welcher Ansatz die positivsten Auswirkungen auf die Metriken hatte, die Sie verbessern möchten
Sehr gute Vorschläge. Welche Metriken würden Sie vorschlagen/verwendet haben?
Time-to-Market (von der ersten Erwähnung bis zur Produktionsfreigabe), Geschäftszufriedenheit (normalerweise durch Product Owner), Vertrauen in das Bereitstellungsteam (wieder von den Geschäftsbenutzern), Häufigkeit von Veröffentlichungen, Anzahl kritischer oder schwerwiegender Fehler in der Produktion, gelieferter Geschäftswert. Es gibt normalerweise auch einige domänenspezifische.
@dqm Beachten Sie, dass solche Experimente im Allgemeinen nicht schlüssig oder irreführend sind, da es in einem so komplexen System (Menschen, die kognitive Arbeit leisten) zu viele Variablen gibt, um wertvolle und gültige Beweise zu erstellen. Wenn es sich um Fließbandarbeit handeln würde, wären die hochbezahlten und hochqualifizierten Technologen nicht erforderlich.

Agil ist in der Vorgehensweise des Beraters nichts und schon gar nicht die Nutzung des Scrum - Frameworks. Das ist ein Wasserfall, bei dem einige moderne Softwareentwicklungsbegriffe missbraucht werden.

Einem internen Team zu erlauben, durch kontrolliertes Experimentieren zu lernen, ist eine gute Mentalität; Es ist lächerlich, einem Berater zu erlauben, Geld für längere Zeit zu verschwenden.

Würden Sie dies Managern mitteilen, die bereits Fristen für das Projekt einhalten? Wie hoch wären die Chancen, dass sie es akzeptieren würden? Ich stimme dem kontrollierten Experimentierteil zu.
"Würdest du?" Das mache ich die ganze Zeit. Jedes Szenario hat seinen eigenen Kontext und damit sein eigenes Ergebnis.

Versuchen Sie, den größten Schmerzpunkt zu identifizieren, und artikulieren Sie die agilen Praktiken, die diesen abschwächen

Sieht so aus, als wären Sie davon überzeugt, dass der bestehende Ansatz sicherlich scheitern wird:

... oder sollte er sie scheitern lassen und den Schmerz spüren, bevor er eingreift?

Sie haben jedoch nicht gesagt, welcher Aspekt ihrer derzeitigen Praxis Ihrer Meinung nach wahrscheinlich Probleme verursachen wird, außer einem allgemeinen:

...kein Planungstreffen oder Retrospektive

Sie scheinen eine höhere Managementunterstützung zu haben, weil sie Sie eingestellt haben und für Ihre Dienste bezahlen. Ihr erster Versuch sollte jedoch sein, dem Team zu erklären, was die Hauptschwäche in ihrem aktuellen Prozess ist und wie Scrum/Agile diese überwinden wird.

Wenn Sie beispielsweise bis zur letzten Phase des Projekts warten, um Backend-/Integrationstests durchzuführen, könnten Sie dies als großes Risiko einstufen.

Sprechen Sie mit dem PO und auch mit den Beratern. Zumindest können Sie den PO überzeugen. Selbst dann, wenn Sie auf Widerstand gegen Veränderungen stoßen, können Sie mit der Geschäftsleitung sprechen und versuchen, das „Alles sollte agil sein“-Mandat durchzusetzen.

Die PO kommt aus einem Wasserfall-Hintergrund und ist mit dem Status quo zufrieden; Wenn überhaupt, unterstützt er das. Das Team denkt, dass sie agil arbeiten / es in der vorherigen (gleichen) Implementierung getan haben, dh "wir machen im Voraus Spezifikationen, um die Systemanforderungen zu sehen, und dann fangen wir an zu sprinten". Zusammenfassend denken das Teammitglied und der PO, dass sie nur finden, und dies ist der einzig gangbare Ansatz. Der agile Coach hat „aber was wäre wenn“-Ansätze ausprobiert und wurde jedes Mal abgeschossen, wenn „nein, das wird nicht passieren“.
Big-4-Scrum-Berater gibt schlechte Ratschläge – richtig oder durchfallen lassen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v