Was haben Sie bei der Einführung von SCRUM falsch gesehen?

20

Was war der einzige Fehlerpunkt, als Ihr Unternehmen beschloss, die aktuellen Prozesse durch SCRUM zu ersetzen?

Können Sie mir einige Beispiele nennen, die wirklich schief gelaufen sind, als ein Unternehmen versucht hat, SCRUM einzuführen? Ich würde gerne Ihre Anekdoten hören, etwas, das Sie selbst erlebt haben, das große Scheitern , das Sie kommen sahen, aber nicht verhindern konnten.

Ich höre große Besorgnis über fehlende Dokumentation zu Entscheidungen über die Implementierungsdetails sowie über die Größe der Storys und den Detaillierungsgrad der Storys.

kriechen
quelle

Antworten:

14

Das größte Problem ist das Missverständnis. Häufige Fehler sind:

  • Nur ein Team macht Scrum, aber der Rest des Unternehmens (einschließlich Vertrieb, Management, Personal) denkt immer noch auf die alte Art und Weise. Beispiele:

    Kontinuierliche Interaktion mit Kunden und Kundenbeteiligung ist sehr wichtig.

    HR muss verstehen, dass die Teamleistung wichtiger ist als die Leistung von Einzelpersonen. KPI muss sich ändern.

    Die Merkmalsdefinition ist ein kontinuierlicher Prozess. Die Projektdefinition wird sich während der Entwicklung durch Kundenfeedback entwickeln. Aufgrund dieses Projekttermins können sich das erforderliche Budget oder die erforderlichen Ergebnisfeatures ändern (nach Genehmigung durch den Stakeholder).

    Veränderung ist Teil des Prozesses.

    Die Schätzung ist ein kontinuierlicher Prozess, von dem Sie zu Beginn des Projekts nicht sagen können, dass Sie innerhalb von 5 Monaten alle Funktionen (von denen viele zu Beginn unbekannt waren) nutzen werden.

    Das Team kann Entscheidungen treffen. Das Team legt sich auf die Anzahl der Features fest, die während des nächsten Sprints bereitgestellt werden. Dies kann nicht verlangt oder befohlen werden.

    Sprint ist eine sichere Zone für das Team. Sobald sich das Team zu bestimmten User Stories verpflichtet hat, kann das Engagement nicht mehr außerhalb des Teams geändert werden.

    Ein Teil der alten Organisationsstruktur macht keinen Sinn, wenn Sie zu Scrum wechseln. Scrum definiert drei Rollen: Scrum-Master, Product Owner, Team. Es gibt andere Rollen, aber diese drei sind normalerweise ausreichend, um die Anwendung bereitzustellen. Der gesunde Menschenverstand besteht darin, Scrum-Master, Teamleiter, Produktbesitzer und einen oder mehrere Projektmanager zu haben. Projektmanager und Teamleiter sind redundante Rollen in Scrum.

  • Guy zugewiesen Scrum Master-Rolle ist nicht Scrum Master. Scrum Master löst Hindernisse. Alles, was das Team stört, ist ein Hindernis, das so schnell wie möglich gelöst werden muss. Der häufigste Fehler besteht darin, diese Rolle dem Entwickler ohne vorherige Erfahrung mit Scrum zuzuweisen. Diese Rolle ersetzt teilweise den üblichen Projektmanager, aber Scrum Master hat keinen Einfluss auf das Team und Scrum Master verlangt keine Implementierung von Funktionen. Scrum Master schützt das Team auch gegen Product Owner mit nicht realisierbaren Anforderungen.

  • Der Typ, dem die Rolle des Product Owners zugewiesen wurde, hat keine Product Owners-Funktion. Der Produktinhaber trägt die finanzielle Verantwortung für das Produkt. Es ist sehr spezifisch und eine Schlüsselrolle für den Erfolg. Die Rolle hat etwas mit Analytik, Projektmanager und Produktmanager gemeinsam. Der Product Owner sammelt und pflegt Anforderungen (normalerweise in Form von User Stories). Seine Aufgabe ist es, das Team mit Informationen zu versorgen und die Priorität von User Stories festzulegen. Er sollte mit dem Team vor Ort sein, da die Zusammenarbeit zwischen PO und dem Team kontinuierlich ist.
  • Ändern Sie den Prozessnamen in Scrum, aber lassen Sie den größten Teil des Prozesses unverändert. Das häufigste Szenario ist, dass Sie von Wasserfall zu Scrum wechseln. Die wichtigste Änderung ist, dass Sie keine Analyse und Dokumentation mehr durchführen und sagen, dass Sie Scrum sind.
  • Anforderungen / User Stories fehlen Definition von erledigt - sehr häufig. Wenn Sie keine Definition für "erledigt" (Akzeptanzkriterien) haben, können Sie während der Sprint-Planung keine Annahmen über die Komplexität der User Story treffen. Wenn Sie sie während des Sprints nicht haben, können Sie die User Story nicht als abgeschlossen markieren, da Sie sie nicht validieren können.
  • Qualität gilt als freiwillig. Qualität in Scrum ist ein erstklassiger Bürger. Wir können sagen, dass jedes Akzeptanzkriterium durch einen automatisierten End-to-End-Test abgedeckt werden sollte. Sobald Sie anfangen, die Qualität zu reduzieren und nicht getestete Funktionen hinzuzufügen, verlieren Sie die Kontrolle über das Produkt, da Funktionen, die als erledigt gelten, aufgrund von Regressionen jederzeit nicht mehr funktionieren können.
  • Das Ergebnis des Sprints sollte inkrementell (= funktionierend und getestet) zum Produkt versendbar sein.

Bearbeiten:

Ich füge einen wichtigen Hinweis hinzu. Bei einem agilen Ansatz geht es vor allem darum, dem Kunden so schnell wie möglich den größtmöglichen Geschäftswert zu liefern. Der Kunde (vertreten durch den Product Owner) beschreibt jedoch den Geschäftswert. Es ist also nicht generell wahr, dass Sie keine Analyse oder Dokumentation haben, wenn Sie Scrum verwenden. Wenn der Kunde eine Analyse oder Dokumentation anfordert und diese als geschäftlichen Wert kennzeichnet (z. B. aufgrund eines umfangreichen oder langfristigen Projekts, das in den nächsten Jahren verbessert werden soll), erstellen Sie diese ebenfalls. Der grundlegendste Ansatz beinhaltet die Analyse und Dokumentation der Akzeptanzkriterien für User Stories. Die Analyse in einem solchen Fall wird in standardisierter Weise durch die Kommunikation mit dem Produktbesitzer dokumentiert.

Ladislav Mrnka
quelle
Ich mag Ihren Fokus auf kontinuierliche Interaktion und Kommunikation . Einige der Bedenken, die ich höre, beziehen sich auf fehlende Details in Geschichten oder undokumentierte Entscheidungen (sogar auf technische Details), und die Leute möchten sich vor den Auswirkungen falscher Entscheidungen schützen (eine sehr defensive Sichtweise).
Cringe
1
Die Dokumentation und Analyse wird durch ständige Interaktion und Kommunikation ersetzt. Sie können eine nicht entfernen und die zweite nicht einführen - dies führt genau zu fehlenden Details und falschen Entscheidungen.
Ladislav Mrnka
The most basic approach is including analysis and documentation in acceptance criteria for user stories.Das ist auch meine erste Reaktion. Wenn die Geschichte Akzeptanzkriterien hat, ist dies die beste Dokumentation, die Sie haben können. Wenn das Team jedoch beschließt, zusätzliche Dokumentationen zu erstellen (denken Sie an READMEs im Kofferraum oder ein Wiki mit nützlichen Informationen), sehe ich kein Problem. Ich denke, die Leute befürchten, dass SCRUM = nichts jemals aufgeschrieben wird.
Cringe
10

Das größte Problem, das mir in über 10 Jahren mit XP und Scrum aufgefallen ist, besteht darin, dass Teams, die noch nicht ganz "agil" sind, sich dazu entschließen, "flexibel in Bezug auf Agilität" zu sein und mit der Anpassung zu beginnen, bestimmte Teile usw. wegzulassen, ohne ein klares Verständnis dafür, was jeder Teil tut und warum er da ist.

Ich habe gesehen, dass Teams mit Scrum erfolgreicher sind, wenn sie Dinge zuerst nach dem Buch tun, als die Teams, die ändern, was sie noch nicht "bekommen".

Das ist, wenn Sie Dinge wie "Erster Sprint, wir werden alle Anforderungen erledigen. Zweiter Sprint, das gesamte Design, etc, etc, letzter Sprint, alle Tests". Auch als Wasserfall bekannt. Oder auch einfache Dinge wie "Lass uns trotzdem sitzen, was ist mit diesem Stand-up-Geschäft?".

Etwas, das mit Shuhari zu tun hat ( http://c2.com/cgi/wiki?ShuHaRi ).

Julio
quelle
9

Das größte Problem ist immer das Buy-In. Wenn sich ein Team oder eine Schlüsselperson nicht eingekauft hat (Projektmanagement, Qualitätssicherung, Entwicklung usw.), ist das Scheitern fast sicher.

Ein weiteres damit verbundenes Problem besteht darin, allen Beteiligten bewusst zu machen, was Scrum ist und was nicht.

Ich habe Umgebungen gesehen, in denen das Projektmanagement dies tatsächlich als Ticket genommen hat, um direkt zu Entwicklern mit Änderungen zu gelangen und zu erwarten, dass dies morgen erledigt wird, da wir den großartigen neuen Prozess verwenden. Jeder, der in dieser Situation oder in anderen gescheiterten Versuchen war, Scrum zu implementieren, hat einen bitteren Geschmack im Mund. Diese Leute werden manchmal auch versuchen, das Projekt vom Netz zu nehmen.

Ein weiteres Problem, das ich gesehen habe, ist Stand-up-Meetings. Sie werden immer den Typen finden, der sich während einer Standbesprechung hinsetzen möchte ... "Ich habe einen schlechten Rücken" oder was auch immer. Es scheint immer derselbe Typ zu sein, der keine Ahnung hat, was das Ziel hinter dem Aufstand ist, und der weder über die Politik noch über das, was er an diesem Wochenende getan hat, den Mund hält. Stand-up-Meetings sind meiner Meinung nach der Schlüssel zu einer effektiven Kommunikation. Es ist wichtig, dass niemand diese Treffen vergiftet.

aceinthehole
quelle
1
Sagen Sie Bad Back Boy einfach, dass er beim Sprechen stehen soll. Wenn er sich immer noch beschwert, machen Sie eine Ankündigung, dass Donuts in der Küche sind.
JeffO
management has actually taken this as a ticket to come directly to developersDas ist ein gutes Beispiel für eine Situation, in der der SCRUM-Prozess nicht verstanden wird, oder? Dass das Team mitten im Sprint keine neuen Geschichten akzeptieren kann.
Cringe
@ Cringe, ja ... genau
Aceinthehole
2
Ist es wirklich wichtig, dass jemand sitzt anstatt steht? Ernst? Deshalb funktionieren agile Methoden nicht - die Leute halten sich an mehr Regeln als bei den alten prozesslastigen Methoden!
gbjbaanb
1
@ gbjbaanb Letztendlich spielt es keine Rolle. Wissen Sie, was das Stehen verhindert? Und wenn ja, wie versuchen Sie das zu verhindern? Und funktioniert es für Sie?
Julio
6

Wir haben versucht, die gesamte Analyse für den Code durchzuführen, den wir im selben Sprint entwickelt haben, in dem wir ihn tatsächlich codiert haben.

Kevin D
quelle
Und Sie brauchten eine Analyse, weil die Geschichte keine Details enthielt? Oder weil der Code nicht klar genug und / oder nicht mit Tests dokumentiert ist?
Cringe
1
Tatsächlich waren die Geschichten unglaublich hoch, bis zu dem Punkt, an dem der Produktbesitzer (meine Terminologie versagt mir hier) nicht einmal wusste, was er wollte.
Kevin D
Wir hatten dieses auch. Seitdem haben wir die meisten Analyseteile vor dem Start des Sprints durchgeführt.
Carra
4

Wir sind vor einiger Zeit zu Scrum übergegangen, und ehrlich gesagt behandelte das Management, das es betreibt, jedes Scrum als einen zweiwöchigen Wasserfallprozess. Das Festhalten an den Scrum-Regeln war ein Prozess für sich!

Dies ist das Problem, das ich sehe. Bei allen agilen Methoden sollte es um Flexibilität gehen, um effektiv so zu arbeiten, wie es für Sie funktioniert. Nicht so, wie es die Prozesse vorschreiben. Zum Beispiel hatten wir zweiwöchige Scrums und ein Team gab an, dass zwei Wochen nicht ausreichten, um gute Arbeit zu leisten Woche. Schockhorror! Das Management lehnte ab, weil es sich für 2 Wochen pro Scrum als ideal erwiesen hatte und dies nun in den Qualitätsverfahren dokumentiert wurde.

Scrum ist die am wenigsten agile der agilen Methoden, weshalb es vielleicht so beliebt war - es ist einfacher, es an die alte Garde zu verkaufen. du sollst Sachen entfernen, die du nicht magst, aber ich glaube nicht, dass das passiert. Mein Rat ist, flexibler und weniger regelbasiert vorzugehen und stattdessen Regeln hinzuzufügen, die Sie benötigen. Ich bevorzuge Crystal aus diesem Grund.

Denken Sie am Ende nur an das halbherzige, agile Manifest .

gbjbaanb
quelle
1
+1 für "Gedränge als zweiwöchiger Wasserfallprozess". Leider scheint das wirklich üblich zu sein
DPD
4

Das größte Problem ist, dass auch Ihr Kunde den SCRUM-Prozess akzeptieren und agil werden muss. Die meisten Kunden möchten dies zu Beginn des Projekts hören:

  • Wie viel wird es kosten
  • Wie es aussehen wird
  • Wann es fertig sein wird

Es klingt vernünftig, ist aber absolut nicht kompatibel mit Agile. Sie müssen Ihrem Kunden erklären, warum agil gut für ihn ist, anstatt Wasserfall.

Ondřej Mirtes
quelle
1
Dies ist mit keiner Entwicklungsmethode vereinbar. Das kann man am Anfang nie sagen. Sie müssen eine Analyse + einen Teil des Designs durchführen, um dies genau spezifizieren zu können, aber Analyse + Design kann die Hälfte der Projektzeit / des Projektbudgets in Anspruch nehmen, und selbst danach können Sie fehlschlagen, da der Kunde die Analyse nicht vollständig versteht.
Ladislav Mrnka
Aber es ist eines der großen Probleme, wenn Sie auch zu SCRUM wechseln. Die Menschen sind so an diese Fragen und Antworten gewöhnt, dass die meisten von ihnen nicht mehr erkennen, dass die Antworten die meiste Zeit am Ende falsch sind. Wenn der Kunde eine grobe Vorstellung vom Produkt hat, fragt er how much will it cost?und erwartet sofort eine detaillierte Antwort. Meine Antwort auf dieses Anliegen lautet immer: "Wenn Sie am Ende genau wissen, was Sie wollen, brauchen Sie kein Agile. Codieren Sie es einfach herunter." Aber wir alle wissen, dass das nicht passieren wird. ;-)
erschaudere
2

Bei meinem ersten Besuch bei SCRUM hatten wir zwei große Probleme:

1) Wir hatten nicht wirklich einen Produktbesitzer. Unser Chef musste die Rolle spielen, weil niemand, der Produktbesitzer hätte sein sollen, dem zustimmen würde. Diese Art der Kräuselung der Dinge, weil er die Antworten nicht immer wirklich kannte.

2) Wir waren schlecht darin, externe Komponenten zu berücksichtigen. Unsere ersten Sprints umfassten die Inbetriebnahme vollautomatischer Tests und wir hatten wiederholt Probleme, die von uns verwendeten Simulatoren zu automatisieren. Irgendwie konnten wir nie besser erkennen, dass dies passieren würde.

Michael Kohne
quelle
+1 für "keinen Product Owner haben". Wir sind auf dasselbe Problem gestoßen - manchmal ist es unvermeidlich, aber Sie sollten es anerkennen und entsprechend planen.
sleske
2

Das Hauptproblem bei meinem Projekt ist, dass die Anforderungserfassung erfolgt, nachdem wir für den nächsten Sprint geschätzt haben. Wir schätzen anhand der Akzeptanzkriterien. Während der Anforderungserfassung stellen wir fest, dass der fein abgestimmte Wechselstrom viel größer ist, sodass die anfänglich geschätzte Arbeitszeit von 8 Stunden nun wirklich 24 Stunden beträgt! Kann ich also meinen Sprint-Rückstand ändern und die Schätzungen überarbeiten und meine Storys reduzieren? Nein Sir! Agile Anforderungen, an denen Sie das Sprint-Backlog nicht ändern können! Das sagt meine TL. Also sollte ich nicht auch nach den ursprünglichen Akzeptanzkriterien codieren, für die ich die Zeit auf 8 Stunden geschätzt hatte! Gott! Nein! Das kannst du nicht! Das wäre doch nicht Agil, oder?

DPD
quelle
Wie haben Sie das behoben? Oder war es der Grund, warum die gesamte Einführung von SCRUM gescheitert ist? Ich dachte, wenn das Team mehr Erfahrung hat, werden die fehlenden Anforderungen frühzeitig bei der Sprintplanung und Schätzung des Pokers deutlich und die Schätzungen werden immer besser.
Cringe
wir haben es noch nicht behoben. Und wir benutzen immer noch SCRUM. Der einzige Unterschied ist, dass wir die Geschichte beiseite lassen können, wenn wir sagen, dass die zusätzliche Arbeit zu viel ist und der TL zustimmt. Wir müssen am Ende mehr Stunden einplanen.
DPD