Wie misst ein Scrum-Team seine Produktivität mit seiner Produktivität vor Scrum?

In unserem Unternehmen stellen wir einige Teams auf Scrum um. Vor Scrum scheinen wir nicht viel Einblick in die Produktivität der Teams zu haben, und wir haben nicht unbedingt eine Möglichkeit, die Qualität der von den Teams produzierten Ergebnisse zu messen.

Bei den Teams, die auf Scrum umgestiegen sind, erkennen die Geschäftsleitung und die Teams, die den Wechsel vollzogen haben, den Wert. Die Entwicklungsteams lieben die kollektive Verantwortung und den Schutz vor Unterbrechungen, und die Senior Manager lieben es, eine Plattform zu haben, auf der ihr Feedback in den Sprint-Review-Meetings gehört werden kann. Wir hatten auch „anekdotische Beweise“ in Form von Kunden, die Dinge sagten wie „Wow! Was ist mit euch allen passiert? als Reaktion auf die wahrgenommene schnellere Entwicklung.

Scrum fühlt sich also schneller an. Es fühlt sich schöner an. Aber leider wollen viele Menschen immer noch harte Daten sehen und mögen keine warmen Gefühle oder Beweise, die allein auf Beobachtungen beruhen.

Gibt es eine Möglichkeit, die Produktivität mit einem alten System zu vergleichen, in dem Sie zuvor wenig bis gar keine Daten hatten? Wie kann man andere Teams in der Organisation davon überzeugen, dass es Vorteile gibt, agile Methoden wie Scrum zu verwenden, wenn es keine harten Daten gibt?

Welche Metriken verwenden Sie, um die Produktivität im alten System zu messen?
Ich würde in diesem Fall keine harten Daten verwenden. Liefern andere Teams Software in der gewünschten Qualität und rechtzeitig? Wenn ja, warum ändern? Wenn nicht, wer zahlt dafür? Bob? Sagen Sie Bob einfach, er könnte etwas Geld sparen.
Scrum wird nicht gut funktionieren, wenn es kein Gefühl der Dringlichkeit für eine Änderung und deren Sponsoring gibt.

Antworten (6)

Ich habe mit einer Organisation zusammengearbeitet, die in einer ähnlichen Position war. Sie hatten mit der Einführung von Scrum begonnen, bevor sie die Effektivität der alten Arbeitsweise gemessen hatten.

Sie fanden ein paar Metriken zum Vergleich mit historischen Daten:

  • Sie sahen sich alte Projektdokumente/E-Mails an und maßen, wie lange es von der ersten Arbeitsanfrage bis zur Produktion gedauert hat, und verglichen dies dann mit den entsprechenden Zeiten bei Scrum-basierten Projekten.
  • Sie hatten einige alte Geschäftsanwenderumfragen, in denen Fragen gestellt wurden wie "Sind Sie mit der Zeit zufrieden, die zum Abschließen von Projekten benötigt wird?". Mit sehr ähnlichen Fragen haben sie dieselben Personen noch einmal befragt und damals mit heute verglichen.
  • Sie haben sich die historischen Zahlen von Produktionsfehlern für Projekte angesehen und sie mit den Zahlen verglichen, die bei jüngsten Scrum-Projekten aufgetreten sind.
Ich denke, es wäre auch gut, die Zeit zu sehen, um die Mängel zu beheben.
Punkt 1 finde ich sehr hilfreich. Obwohl wir Fehler nicht immer dokumentieren, wird es wahrscheinlich E-Mail-Threads geben, die theoretisch hilfreich sein könnten. Das Abrufen der Daten kann jedoch unglaublich zeitaufwändig sein.
So wie ich es gesehen habe, wurde nicht viel Zeit dafür aufgewendet. Mehrere Personen haben sich zusammengetan und auf einem Whiteboard die Projekte aufgelistet, an denen sie in den letzten Jahren (vor der Einführung von Agile) gearbeitet haben. Sie taten dann ihr Bestes, um sich daran zu erinnern, wann sie anfingen und wann sie mit der Produktion begannen. Wo die Leute sich nicht ganz sicher waren, gab es einige Überprüfungen von Projektdokumenten und E-Mails, aber es war nicht notwendig für viele hochkarätige Projekte, an die sich die Leute gut erinnerten.

Es überrascht Sie vielleicht nicht, dass es ohne Daten aus früheren Projekten schwierig ist, viele Vergleiche anzustellen. Sie können eine relative Schätzung früherer Projekte verwenden und zwei von ähnlicher Größe oder ähnlicher Funktionalität nehmen und sie vergleichen.

Sie erwähnen ausdrücklich die Tatsache, dass es sich schneller anfühlt und manchmal auch ist, aber das kann schwieriger sein, genaue Zahlen zu erhalten. Sie haben jedoch wahrscheinlich diese Zahlen: Vergleichen Sie die Wert-/Umsatzgenerierung eines Projekts in Scrum, das iterative Releases verwendet, mit einem Projekt, das am Ende ein großes Release hat. Wenn Sie es grafisch darstellen, sieht es wahrscheinlich so aus:

Geben Sie hier die Bildbeschreibung ein

Hier geht es nicht genau um Scrum – mehr um iterative Releases oder End-of-Project-Releases. Es könnte jedoch einige der harten Daten liefern, nach denen Sie suchen.

Darüber hinaus können Sie Ihre Daten auch genau dann baselinen, wenn Ihr Team Scrum einführt, und dann zeigen, dass sie sich im Laufe der Zeit verbessern und das Team in der Lage ist, sich kontinuierlich zu verbessern. Auch dies ist eher eine Werbung für die Feedback-Schleifen, die Sie in Scrum erhalten, als für Scrum selbst, aber das ist wahrscheinlich in Ordnung.

Warum ist das nicht Scrum? Sagt Scrum, tu es nicht? Sich auf den gelieferten Wert zu konzentrieren, klingt für mich sehr nach Scrummie ☺
Es passiert definitiv in Scrum, aber Sie können auch ohne Scrum inkrementell liefern.

KURZE ANTWORT

  1. Bewertung Ihrer bisherigen Prozesse Lieferzeiten und Termine (Lieferrhythmus)
  2. Denken Sie daran, dass der Hauptmaßstab für den Erfolg eine funktionierende Software ist – zeigen Sie Ihren Lieferrhythmus in Scrum und den Unterschied zwischen jetzt und in der Vergangenheit.

Zusätzliches Beispiel: Ich habe einmal an einem Projekt gearbeitet, bei dem 8 Tools für die Suche nach verschiedenen Arten von Inventar entwickelt wurden. Jeder Inventartyp (insgesamt etwa 50) hatte seine eigenen Anforderungen. Unter dem Wasserfall hat mein Kunde 8 Tools in ungefähr 8 Jahren geliefert bekommen (in einer veralteten Cold-Fusion-Umgebung). Wir haben eine Templating-Engine in Java entwickelt und die neuen Tools mit Scrum sowie DevOps erstellt und 45 Tools in weniger als 6 Monaten erstellt. Wir haben Standardisierungstechniken für den Datenzugriff wie Service-Layer-APIs verwendet, um vorhersagen zu können, wie Daten in Zukunft gespeichert werden, was es uns ermöglichte, im Wesentlichen kleine Konfigurationsdateien für jeden Inventartyp zu schreiben – die Templating-Engine erledigte den Rest.

Hmm, das ist vielleicht ein gutes Argument. Denn „funktionierende Software“ wurde sicher nicht immer rechtzeitig nach dem alten Muster freigegeben.

In Scrum wird die Produktivität in Bezug auf die tatsächliche Lieferung gemessen.

Wenn Scrum für die Softwareentwicklung verwendet wird, wird nach jedem Sprint Software geliefert, die für die Endbenutzer wertvoll ist. Eine genaue Prognose für das Sprint-Backlog, das Erreichen eines Sprint-Ziels und ein zufriedener Product Owner reichen aus, um die Produktivität zu messen.

Sie können objektive Software-Engineering-Messungen wie Funktionspunkte auf die Software anwenden, die mit einem anderen Ansatz entwickelt wurde, und sie mit Funktionspunkten vergleichen, die in derselben Zeit in Scrum geliefert wurden.

Ich bezweifle jedoch, dass diese Art von Ansatz Ihnen helfen würde, Entwickler davon zu überzeugen, Scrum zu verwenden.

Kurzer Kommentar hier - ich bin mir nicht sicher, ob Sie mit dem "strengen Scrum-Hut auf" geantwortet haben (verzeihen Sie mir, wenn Sie es wären!), Aber ich denke, die meisten Agilisten entfernen sich schnell von Geschwindigkeit und Qualität als Schlüsselmetriken und konzentrieren sich mehr auf tatsächliche, messbarer Wert geliefert. Das heißt, ein PO-abhängiges Team, das 100 fehlerfreie Story Points liefert, die von Kunden kaum genutzt werden, ist nicht so „produktiv“ oder effektiv wie ein Team, das nur 50 Story Points gut genutzter Funktionen mit geringfügigen Fehlern liefert, auf dem Weg zu selbst Domänenexperten werden.
@JeffLindsey Als ich antwortete, hatte ich einen Scrum-Hut auf :) Ich ermutige die Leute, Scrum zu verwenden, wenn sie wirklich Scrum meinen, das im Scrum-Leitfaden beschrieben wird. Dieser Satz: „Eine genaue Prognose für das Sprint-Backlog, das Erreichen eines Sprint-Ziels und ein zufriedener Product Owner reichen aus, um die Produktivität zu messen.“ bedeutet für mich genau das, was Sie in Ihrem Kommentar geschrieben haben, nämlich gut genutzte Funktionen von Endbenutzern.

Wenn Sie damit fortfahren, denken Sie daran, dass Sie normalerweise "bekommen, was Sie messen". Geschwindigkeit und Qualität sind gut, aber nicht auf Kosten anderer Bereiche – Glück, Eigenverantwortung, Autonomie, Fachkompetenz/T-Form, Dezentralisierung von Fähigkeiten und Wissen, Nachhaltigkeit und so weiter.

Meiner Erfahrung nach haben diese oft einen viel größeren Einfluss auf den tatsächlich gelieferten Wert, sind viel schwieriger zu messen und werden nicht in Geschwindigkeits- oder Fehlerzahldaten dargestellt.

Ich mag Barnabys Antwort sehr, bin mir jedoch nicht sicher, ob Sie den richtigen Vergleich anstellen können, der Skeptiker und Daten-Nerds überzeugen kann. Das Problem bei diesem speziellen Setup ist, dass es nicht möglich ist zu wissen, warum die späteren Projekte besser (oder schlechter) abschneiden.

Meiner Meinung nach wirken hier zwei Faktoren: Der alte Weg hat gute Grundlagen gelegt, der neue Weg spielt einfach mit und baut darauf auf, oder der neue Weg hat es tatsächlich geschafft, sich zu reformieren. Ich glaube, es gibt keine Möglichkeit, den zweiten Faktor zu beweisen, bis man den ersten nicht falsifizieren kann.

Es ist ein häufiges Problem im Sport. Es gibt Athleten, die in ihrer Karriere als junger Athlet nichts Relevantes gewonnen haben, aber wenn sie an den Erwachsenenwettbewerben teilnehmen, fangen sie an zu gewinnen. Trainer neigen dazu zu sagen, dass die Veränderung den Trick bewirkt hat, aber in einigen Fällen haben die Trainer, die mit ihnen gearbeitet haben, als sie jünger waren, alle Grundlagen (meistens physisch) gelegt, die der Schlüssel waren, um zu gewinnen.

Wenn Sie hier wirklich etwas beweisen wollen, gehen Sie für ein paar Sprints / Iterationen zum alten Weg zurück . Sie haben Daten aus Ihrem Scrum, und Sie können Daten aus Ihrer alten Art der Geschäftstätigkeit sammeln, denn jetzt wissen Sie, wonach Sie suchen. Ihr Fall muss reversibel sein ; Wenn Ihr Test zeigt, dass der alte Weg schlechter ist als Scrum, haben Sie Ihre Ergebnisse. Wenn die Ergebnisse jedoch nicht endgültig sind, können Sie nur sagen, dass sich der neue Weg besser anfühlt, was gut ist, aber niemals ausreichen wird.

Ich mag diesen Ansatz, und wenn wir einfach als "Test" zum alten Modell zurückkehren könnten, würde ich es tun. Der Wechsel zu Scrum hat viel Mühe und Zeit gekostet, und wir mussten etwas langsamer werden, bevor sich die Dinge scheinbar schneller beschleunigten. Trotzdem, wenn Veränderungen auftreten, tun dies manchmal auch Menschen. Als der CEO bei Zappos das Team in eine flache Organisationsstruktur verlegte, verließen 20 % oder eine bestimmte Anzahl von Mitarbeitern das Unternehmen. Leider ist es uns nicht möglich, umzukehren, ohne der Organisation zu schaden. Trotzdem finde ich Ihre Erklärung der Ursache des Problems hilfreich und werde darüber nachdenken.
Ich mag diese Idee nicht, sie ist schlecht. Zum einen „wissen“ die Leute, dass sie einen Test durchführen, daher besteht die Gefahr einer potenziell starken Voreingenommenheit. Dies ist ein häufiger Fehler bei der statistischen Analyse von Studien/Experimenten. Wenn Sie wissen, dass Sie testen oder experimentieren, führen Sie Ihre Funktionen und Aktionen anders aus als in einer normalen Umgebung. Die Ergebnisse wären nicht wissenschaftlich.
Wie misst ein Scrum-Team seine Produktivität mit seiner Produktivität vor Scrum?
AntwortenHierDatenschutz-Bestimmungen1y, 0v