Das Team verfehlt ständig die Sprintziele

Wir sind ein kleines Softwareunternehmen mit einem Produkt.

Wir verwenden Scrum , und unsere Entwickler wählen die Funktionen aus, die sie in jeden Sprint einbeziehen möchten. Leider hat das Team in den letzten 18 Monaten nicht ein einziges Mal die Features geliefert, die für einen Sprint zugesagt wurden.

Ich habe eine Menge Posts / Antworten gelesen, in denen es heißt: "Software ist erledigt, wenn sie erledigt ist, nicht früher, nicht später. Es hilft nicht, Druck auf das Team auszuüben, mehr Leute darauf zu setzen." "Ich habe von einem der Entwickler ein ähnliches Feedback zu meiner Frage erhalten, wie wir die Erfolgsquote von Sprints verbessern können. Oh, und ja, wir verwenden Retrospektiven .

Meine Frage ist im Grunde:

Wann ist es fair, das Problem in der Qualität der Entwickler zu suchen?

Ich beginne zu denken, dass, wenn Sie Ihre eigenen Arbeiten / Funktionen auswählen und dennoch jeden Sprint scheitern, Sie die Komplexität Ihres eigenen Codes nicht überwachen können; - oder der Code ist so komplex, dass niemand die Komplexität übersehen kann.

Vermisse ich etwas?

Sie sollten zuerst fragen, "wen interessiert das"?

Das Abschließen von Sprints fühlt sich gut an und führt in einigen Unternehmen zu Cookies von den Scrum-Eltern. Der ultimative Test ist jedoch, ob das Unternehmen seine Ziele erreicht.

Das Obige ist scherzhaft. Wenn das Unternehmen erfolgreich ist, ohne den geplanten Inhalt eines Sprints zu Ende zu bringen, können Sie stattdessen auch Kanban verwenden: Sie sortieren den Rückstand, arbeiten am Wichtigsten und kümmern sich nicht so sehr um definierte Iterationen.

Einer der Werte definierter Iterationen besteht darin, die Prozessverbesserung voranzutreiben (oder Leistungseinbußen bei bestimmten Mentalitäten zu beseitigen). Das verstehst du jetzt nicht. Sie können also entweder den Rest des Prozesses übernehmen, der den Prozess verbessert (und schließlich Sprints abschließt), oder Sie können entscheiden, ob Ihnen das gefällt, was Sie haben.

Vermisse ich etwas?

JA!

Du warst 18 Monate unterwegs - oder irgendwo in der Nähe von 36 Sprints mit Rückblick, aber irgendwie konnte das nicht behoben werden? Management nicht hielt das Team verantwortlich, und dann sie hat Management hält nicht sie verantwortlich für das Team nicht zur Rechenschaft zu ziehen?

Sie vermissen, dass Ihr Unternehmen durchweg inkompetent ist .

Also, wie man es repariert. Sie (der Entwickler) hören auf, sich auf so viel Arbeit festzulegen. Wenn die Geschichten so groß sind, dass Sie das nicht können, müssen Sie sie in kleinere Teile aufteilen. Und dann macht man die Leute dafür verantwortlich, dass sie getan haben, was sie sagen, dass sie getan haben werden. Wenn sich herausstellt, dass sie bei jedem Sprint nur ein winziges Feature ausführen können, finden Sie heraus, warum und verbessern Sie es (möglicherweise muss der Entwickler ausgetauscht werden). Wenn sich herausstellt, dass sie nicht herausfinden können, wie sie sich auf angemessene Mengen an Arbeit festlegen sollen, entlassen Sie sie .

Aber vorher habe ich mir das Management angeschaut, das die Dinge so lange laufen lässt, und herausgefunden, warum sie nicht ihren Job machen.

Ich möchte Ihnen vorschlagen, eine kleine Änderung vorzunehmen und Kanban für ein paar Wochen anstelle von Scrum auszuprobieren . Es könnte für Ihr Team besser funktionieren.

Während Scrum die Produktivität steigert, indem die in einem Sprint verfügbare Arbeitszeit begrenzt wird, steigert Kanban die Produktivität und Geschwindigkeit, indem die Anzahl der aktiven, gleichzeitig auftretenden Probleme begrenzt wird. Die Zeitschätzung ist nicht mehr Teil des Prozesses. ( Quelle )

Kurz gesagt, was ist Kanban?

Kanban ist auch ein Werkzeug, um die Arbeit der Effizienz halber zu organisieren. Wie Scrum fördert Kanban die Aufteilung der Arbeit in überschaubare Teile und verwendet ein Kanban-Board (das dem Scrum-Board sehr ähnlich ist), um diese Arbeit im Verlauf des Arbeitsablaufs zu visualisieren. Während Scrum die Zeit begrenzt, die zum Ausführen einer bestimmten Arbeitsmenge (mithilfe von Sprints) erforderlich ist, begrenzt Kanban die Arbeitsmenge, die in einer bestimmten Bedingung zulässig ist (nur so viele Aufgaben können ausgeführt werden, nur so viele können ausgeführt werden) -Do-Liste.)

Wie sind SCRUM und Kanban gleich?

Sowohl Scrum als auch Kanban ermöglichen es, große und komplexe Aufgaben effizient zu lösen und zu erledigen. Beide legen großen Wert auf kontinuierliche Verbesserung, Optimierung der Arbeit und des Prozesses. Und beide teilen den sehr ähnlichen Fokus auf einen gut sichtbaren Arbeitsablauf, der alle Teammitglieder über WIP und die kommenden Aufgaben auf dem Laufenden hält.

Weitere Details finden Sie unter diesem Link

Meine Frage ist im Grunde: Wann ist es fair, das Problem in der Qualität der Entwickler zu suchen

Ihr Beitrag enthält nicht genügend Informationen, um diese Frage zu beantworten. Es gibt keine Möglichkeit festzustellen, ob sie versagen, weil sie inkompetent sind, oder weil sie sich dazu verpflichten, mehr Arbeit zu leisten, als zumutbar ist.

Wenn ich ein unglaublich begabter Entwickler bin, in einem Team von unglaublich begabten Entwicklern, und es uns nicht gelingt, X-Storys in zwei Sprints (oder 36!) Zu beenden, sind wir inkompetent? Oder saugen wir nur an der Schätzung? Das hängt davon ab, ob die Geschichten "einen Anmeldebildschirm erstellen" oder "einen Mann sicher zum Mars schicken" lauten.

Das Problem beginnt mit schlechten Geschichten und / oder falschen Schätzungen

Die Einschätzung ist schwierig. Sehr hart. Menschen saugen daran, weshalb Scrum uns die Arbeit in Blöcke aufteilen lässt, die nicht länger als ein oder zwei Tage dauern sollten, und um kleine Gruppen dieser Blöcke zusammenzustellen, von denen wir sicher sind, dass wir sie in kurzer Zeit fertig stellen können . Je größer die Blöcke sind und je länger der Zeitraum, desto ungenauer sind unsere Schätzungen.

Wie sind deine Läden? Sind sie gut geschrieben und haben gute Akzeptanzkriterien? Sind sie klein genug, um in wenigen Tagen fertig zu werden? Ohne gut geschriebene Geschichten (was die Schuld des gesamten Entwicklungsteams ist, einschließlich des Produktbesitzers) kann nicht erwartet werden, dass das Team eine gute Schätzung vornimmt.

Das Problem wird durch schlechte Rückblicke verstärkt

Was Sie anscheinend falsch machen, ist, dass Sie keine Retrospektiven nutzen. Sie haben 18 Monate gebraucht, um dieses Problem zu lösen. Entweder bemerkt das Team das Problem nicht oder es wird im Nachhinein nicht behandelt.

Beendet sich jede Retrospektive mit mindestens einem Aktionspunkt für das Team, um es beim nächsten Sprint besser zu machen? Beinhaltet jede Retrospektive das Besprechen der Aktionselemente aus dem vorherigen Sprint, um zu sehen, ob sie ausgeführt wurden und ob sie effektiv waren?

Die Lösung besteht nicht darin, Schuld zuzuweisen, sondern zu lernen

Der erste Schritt sollte darin bestehen, keine Schuld mehr zu suchen und stattdessen daran zu arbeiten, das Team zu verbessern. Ihr Team ist wahrscheinlich nicht inkompetent, nur schlecht in Einschätzung und Planung. Zwingen Sie das Team, einen Sprint zu beenden, auch wenn dies bedeutet, dass es eine einzelne Story auswählt und eine Woche früher fertig wird. Wenn sie das nicht können, sind sie entweder inkompetent oder die Geschichten sind einfach zu komplex. Die Antwort auf diese Frage sollte offensichtlich sein.

Sobald sie in der Lage sind, die eine Geschichte zu beenden, werden sie mit hinreichender Sicherheit wissen, dass sie in einem Sprint X Punkte für die Geschichte erzielen können. Einfache Mathematik hilft bei der Beantwortung der Frage, ob sie mehr Geschichten schreiben können oder nicht.

Kontinuierliche Verbesserung ist die Lösung

Sobald sie eine Geschichte in einem Sprint beendet haben, ist es Zeit zu sehen, ob sie zwei schaffen können. Aufschäumen, ausspülen, wiederholen. Wenn sie anfangen, die Sprintziele zu verfehlen, haben Sie die Grenze für ihre Schätzfähigkeiten gefunden. Kehren Sie zur Anzahl der Story-Punkte aus der vorherigen Story zurück und bleiben Sie eine Weile dabei.

Nehmen Sie die Rückblicke immer ernst. Wenn sie einen Sprint nicht beendet haben, finden Sie heraus, warum und handeln Sie danach. Hatten sie zu viele Unbekannte? Haben sie die falsche Mischung von Fähigkeiten? Wie gut waren ihre Schätzungen? Wenn sie eine Geschichte auf X Punkte schätzten, erforderte sie einen relativ gleichen Arbeitsaufwand wie Geschichten aus dem Priorat, die X Punkte wert waren? Wenn nicht, verwenden Sie diese Option, um die zukünftigen Punkte der Storys anzupassen.

Sie sagen, Sie "verwenden Retrospektiven." Aber was macht das Team in diesen Rückblicken? Da Sie seit 18 Monaten nicht mehr auf diesen Aspekt Ihres Prozesses eingegangen sind, lautet die Antwort vermutlich: Nichts sehr Nützliches.

Die Retrospektive ist für mich der wichtigste Teil des Prozesses. Wirf oder ändere alles andere an Scrum, was du willst (natürlich im gegenseitigen Einvernehmen des Teams während einer Retrospektive), aber nimm dir regelmäßig die Zeit, um darüber zu sprechen, wie der Prozess für alle funktioniert, was funktioniert und was nicht nicht funktionieren und Verbesserungsvorschläge machen. Versuchen Sie nach und nach, Ihren Prozess bei jedem Sprint zu verbessern, und früher oder später können Sie etwas haben, das ziemlich gut funktioniert.

In Ihrem Fall scheint dieser Prozess nicht zu funktionieren. Da die Sprintziele nicht erreicht werden, ist es ratsam, sich im Nachhinein darauf zu konzentrieren, warum dies der Fall ist. Offensichtlich hat das Team zu viel Arbeit für den Sprint auf sich genommen. Aber warum haben sie das getan?

• Haben sie die Komplexität der Arbeit unterschätzt?
• Hat das Management sie unter Druck gesetzt, mehr Arbeit zu übernehmen, als das Team erwartet hatte?
• Hatten sie zu viele Unterbrechungen / Notfälle, die Ressourcen für die Ausführung der geplanten Arbeit in Anspruch nahmen?
• Gab es Engpässe, die den Abschluss der Arbeiten verzögerten (z. B. das Warten auf Assets eines externen Designteams)?
• Und sogar: Waren ein oder mehrere Teammitglieder überhaupt nicht in der Lage, die Arbeit zu erledigen?

Diese Art von Fragen hätte sich das Team in den letzten 18 Monaten bei jedem Sprint stellen sollen. Mit den Antworten können sie dann Vorschläge für Prozessverbesserungen vorlegen, um sie für den nächsten Sprint zu testen. Dies können sein:

• Nimm im nächsten Sprint weniger Arbeit auf (duh!)
• Seien Sie konservativer in Schätzungen
• Sagen Sie, wer uns unter Druck setzt, mehr Arbeit zu leisten, um abzuhauen, da wir bereits mehr übernehmen, als wir derzeit erreichen können
• Verwalten Sie Unterbrechungen besser und passen Sie den Arbeitsaufwand im nächsten Sprint an, um unvermeidbaren Notfällen Rechnung zu tragen
• Beheben Sie die Engpässe oder planen Sie um diejenigen herum, die Sie nicht vermeiden können
• Weisen Sie Teammitgliedern, die dies nicht können, keine Storys zu (und ermitteln Sie separat die Reaktion des Managements, um eine Situation mit einem Teammitglied mit schlechten Leistungen anzugehen, von Training und Mentoring bis hin zur Entlassung).

Dies ist die Art von Unterhaltung, die in den letzten 18 Monaten bei jedem einzelnen Sprint hätte stattfinden sollen. Es geht nicht darum, Druck auf das Team auszuüben oder mehr Ressourcen hinzuzufügen, sondern darum, Ihre Rückblicke zu nutzen, um Ihren Prozess kontinuierlich zu verbessern. Das passiert hier eindeutig nicht.

Man könnte meinen, dass das Team beim 15. Sprint mit verpassten Toren so oft in der Rückschau darüber diskutiert hätte, bis zu dem Punkt, an dem es beschlossen hat, nur die minimalstmöglichen Sprintziele zu erreichen, um ein Ziel zu erreichen. Bis zum 25. unvollständigen Sprint würde ich nur einen Sprint mit einem einzigen Saitenwechsel und sonst nichts machen. Wenn das Team das im Sprint nicht schafft, sind die Probleme noch schlimmer, als Sie vermuten.

Wie bereits von mehreren erwähnt, handelt es sich bei den Sprintzielen um Prognosen, nicht um eiserne Verpflichtungen, und fehlende Ziele sind selbst kein Anzeichen für etwas anderes als ungenaue Prognosen. Ein großartiges Team kann Tonnen von Toren verfehlen, weil sie schlechte Prognostiker sind, während ein schreckliches Team jeden treffen und keinen tatsächlichen Wert liefern kann. Wenn Ihre Prognosen jedoch 18 Monate lang in derselben Richtung falsch sind, funktioniert dieser Teil Ihres Prozesses nicht. Verwenden Sie Ihre Rückblicke, um den Prozess so zu optimieren, dass Ihre Prognosen der tatsächlichen Realität des jeweiligen Sprints des Teams einigermaßen nahe kommen.

"Software ist fertig, wenn sie fertig ist, nicht früher, nicht später."

Dies ist richtig, aber versteht jeder in Ihrer Organisation für jede Aufgabe, an der Ihre Entwickler zu arbeiten beginnen, die Definition von "Fertig" für jede Aufgabe?

Es scheint, dass eines Ihrer größten Probleme die Schätzung ist , aber Entwickler können nur dann eine realistische Schätzung abgeben , wenn sie eine eindeutige und klar definierte "Definition von erledigt" haben. (Dies umfasst Probleme mit Unternehmensprozessen - z. B. Benutzerdokumentation, Arbeitspakete für eine formelle Freigabe usw.)

Es ist nicht verwunderlich, dass eine Überschätzung ein Problem verursacht, da die meisten Entwickler der Ansicht sind, dass es am schwierigsten ist, die für die Ausführung einer Aufgabe erforderliche Zeit zu schätzen.

Die meisten Entwickler haben jedoch einen vernünftigen (wenn auch optimistischen ) Umgang mit dem Aufwand, den sie für einen bestimmten Zeitraum aufwenden können.

Das Problem ist oft, dass Entwickler Schwierigkeiten haben, eine Beziehung zwischen einer Aufgabe und dem Gesamtaufwand für die Bearbeitung unvollständiger Informationen herzustellen. Dies gilt insbesondere dann, wenn sie gezwungen sind, alle Antworten vorab auf eine wirklich große Aufgabe zu finden .

Dies führt natürlich dazu, dass sich Zeitschätzungen von der Realität lösen und Dinge wie den Erstellungsprozess und die Benutzerdokumentation aus den Augen verlieren.

Die Trennung beginnt in der Regel ganz am Anfang, wenn die Aufgabe beschrieben wird. und es wird normalerweise von einer nicht-technischen Person zusammengesetzt, die eine Liste von Anforderungen erstellt, ohne eine Ahnung davon zu haben, wie viel Aufwand erforderlich ist.

Manchmal spezifizieren Führungskräfte Aufgaben und ignorieren Probleme mit Unternehmensprozessen vollständig. Für Führungskräfte ist es nicht ungewöhnlich, dass Dinge wie das Definieren von Tests oder das Erstellen eines formalen freigegebenen Builds oder das Aktualisieren eines Benutzerdokuments ohne Zeit- oder Arbeitsaufwand auf magische Weise geschehen. erforderlich.

Manchmal scheitern Projekte, bevor ein Entwickler überhaupt eine Codezeile geschrieben hat, weil jemand, irgendwo, seine Arbeit nicht richtig macht.

Wenn das Entwicklungsteam nicht daran beteiligt ist, Anforderungen zu vereinbaren oder Akzeptanzkriterien zu erfassen, ist dies ein Misserfolg des Managements. Dies bedeutet, dass jemand, der den Code und die technischen Probleme nicht ausreichend versteht, das Unternehmen zu einem unvollständigen Satz von Anforderungen verpflichtet hat. und ließ das Projekt offen für Fehlinterpretationen, Scope Creep, Vergoldung usw.

Wenn das Entwicklungsteam bei der Erfassung und Abstimmung Anforderungen beteiligt ist, dann könnte es ein Versagen des Teams sein, die die Details für die Klärung verantwortlich sind (und die Akzeptanzkriterien - „Was bedeutet die lieferbaren aussehen , wenn es also getan ?“ ). Das Entwicklungsteam ist auch dafür verantwortlich, NEIN zu sagen, wenn andere Blockierungsprobleme vorliegen oder wenn eine Anforderung nur unrealistisch ist.

Wenn die Entwickler an der Erfassung der Anforderungen beteiligt sind:

• Hat das Team die Möglichkeit, sich mit dem Produktmanager zusammenzusetzen, um die Anforderungen / Definition von „erledigt“ zu klären?
• Stellt das Team ausreichende Fragen, um implizite / angenommene Anforderungen zu klären? Wie oft werden diese Fragen zufriedenstellend beantwortet?
• Verlangt das Team Akzeptanzkriterien (Definition von erledigt), bevor es eine Schätzung abgibt?
• Wie gut werden Akzeptanzkriterien normalerweise für jede Aufgabe erfasst? Handelt es sich um ein vages Dokument mit wenigen Details oder beschreibt es konkrete Funktionen und Formulierungen, die ein Entwickler eindeutig in einen Test übersetzen könnte ?

Möglicherweise spielt die Produktivität Ihres Teams keine Rolle. Ihr Team wird wahrscheinlich alle Anstrengungen unternehmen, die es in Bezug auf die Entwicklung unternehmen kann. Ihre eigentlichen Probleme können eines oder mehrere der folgenden sein:

• Unvollständige und vage Anforderungen.
• Anforderungen / Aufgaben, die einfach zu groß sind.
• Schlechte Kommunikation zwischen dem Entwicklungsteam und dem oberen Management.
• Fehlen klar definierter Akzeptanzkriterien, bevor die Aufgaben an das Team übergeben werden.
• Unvollständige oder vage / mehrdeutige Spezifikation von Abnahmetests. (dh Definition von Done)
• Unzureichende Zeit für die Festlegung / Vereinbarung von Akzeptanzkriterien.
• Die Entwickler haben keine Zeit in Betracht gezogen, um vorhandenen Baseline-Code zu testen oder vorhandene Fehler zu beheben
• Die Entwickler haben den vorhandenen Baseline-Code getestet, die Fehler jedoch nicht als Blockierungsprobleme gemeldet, bevor sie Schätzungen zu den Anforderungen vorgelegt haben
• Das Management erkannte die Probleme / Fehler und entschied, dass Fehler nicht behoben werden müssen, bevor neuer Code geschrieben wird.
• Entwickler stehen unter dem Druck, 100% ihrer Zeit in Anspruch zu nehmen, obwohl möglicherweise 20% (oder eine ähnliche Anzahl) ihrer Zeit von Besprechungen, Ablenkungen, E-Mails usw. beansprucht wird.
• Die Schätzungen werden zum Nennwert vereinbart, und niemand passt den Raum für Fehler oder Unvorhergesehenes an (z. B. "Wir haben beschlossen, dass dies 5 Tage dauern sollte, also erwarten wir, dass dies in 8 getan wird.").
• Schätzungen werden von allen (Entwicklern und Management) als einzelne Zahlen anstatt als realistische "Bereichs" -Zahlen behandelt - d. H
  • Bester Fall Schätzung
  • Realistische Schätzung
  • Worst-Case-Schätzung

... die Liste könnte viel länger dauern.

Sie müssen einige "Fakten finden" und genau herausfinden, warum die Schätzungen konsequent von der Realität getrennt sind. Ist die vorhandene Basissoftware fehlerhaft? Fehlt es an Unit-Test-Abdeckung? Vermeiden Ihre Entwickler die Kommunikation mit dem Management? Vermeidet das Management die Kommunikation mit Entwicklern? Gibt es eine Diskrepanz zwischen den Erwartungen des Managements und den Erwartungen der Entwickler, wenn es um "Definition of Done" geht ?

Mein Rat, das Team neu zu starten, ist, die kleinstmögliche Story pro Team und Sprint auszuwählen und diese eine Story und nur diese eine Story zu vervollständigen!

Ich stimme den anderen Postern zu, entweder ist das Team inkompetent oder sie versuchen zu viel zu tun.

Beginnen Sie mit den kleinsten Dingen, den am meisten reduzierten Geschichten und beenden Sie einen einzelnen Sprint. Bringen Sie das Team dazu, einen Sprint zu beenden und erfolgreich zu sein. Auf diese Weise lernen Sie, wie Sie Ihre Zeit- und Arbeitsverpflichtungen priorisieren können. Mit der Zeit wird das Team in der Lage sein, mehr und mehr zu arbeiten, bis die maximale Produktivität erreicht ist.

Sie sollten Daten sammeln und Vertrauensniveaus auf der Grundlage der früheren Leistung aufbauen.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

Das einfachste Beispiel sind Sprints mit konstanter Zeit, beispielsweise alle zwei Wochen. Schätzen Sie, wie viele Story Points das Team innerhalb von zwei Wochen beenden wird. Dann, nachdem der zweiwöchige Sprint vorbei ist, sehen Sie, wie viele Story-Punkte tatsächlich abgeschlossen wurden. Mit der Zeit werden Sie vielleicht 15 Punkte schätzen, aber nur 10 Punkte erreichen. In diesem einfachen Fall können Sie mit einer Geschwindigkeitsanpassung beginnen, sodass Sie nur 10 Punkte pro Sprint planen. Oder dass Sie planen, 66% der geschätzten Arbeit zu erledigen.

Indem Sie das Konfidenzniveau mit Standardabweichungen aufbauen, können Sie dem Management mitteilen: Gemäß den aktuellen Projektzielen erwarten wir nur 50% Konfidenz, die wir in 3 Wochen beenden können, aber 95% Konfidenz, die wir in 5 Wochen beenden können.

Die Idee hinter Agile und Scrum ist es, eine enge Feedback-Schleife einzurichten, damit Sie Ihren Prozess beurteilen können. Man muss sich fragen: "Wo ist das zusammengebrochen?", Da es völlig zusammengebrochen zu sein scheint.

1. Planen Sie, was Sie tun werden, und erstellen Sie eine Liste
   • Dies sollte darin bestehen, Elemente aus einem Rückstand von Elementen auszuwählen, die vervollständigt werden müssen. Bevor etwas für den Sprint in die To-Do-Liste aufgenommen wird, muss das Team sich darauf einigen, dass es vollständig verstanden wird und dass es ungefähr weniger als einen Sprint dauern wird, bis es fertig ist.
   • Im Idealfall wird der Rückstand nach Priorität (für das Unternehmen) sortiert, und Sie können die Prioritätsreihenfolge festlegen.
   • Wenn Elemente aus dem Rückstand zu groß sind, teilen Sie sie in kleinere Teile auf. Teilen Sie die Blöcke dann in einzelne Aufgaben auf, die in einem Tag oder weniger erledigt werden können.
   • Erwarten Sie nicht, dass diese Planung einfach oder schnell sein wird.
2. Für einen definierten Zeitraum auf Elementen aus der Liste ausführen (Sprint)
3. Überprüfen Sie, was Sie erreicht haben
   • Welche Geschichten wurden beendet?
   • Wenn keine Geschichten fertig waren, welche Aufgaben wurden dann erledigt?
   • Wenn keine Aufgaben erledigt wurden, was genau haben dann alle am vergangenen Montag getan? Letzten Dienstag? Usw. - an diesem Punkt ist es Zeit für strenge Selbstbeobachtung ...

4. Beheben Sie die Probleme (analysieren Sie Feedback und passen Sie es an)

   • Wie lange hat es gedauert, bis die Dinge fertig waren?
   • Was verhinderte, dass Aufgaben erledigt wurden?
   • Teilen die Teammitglieder die Storys (Features) in Aufgaben auf, die innerhalb eines Tages oder weniger erledigt werden können? Wenn nicht, machen Sie dies und machen Sie es zu einem Teil der To-Do-Liste.
   • Welche Änderungen an der Aufgabenliste oder den Elementen in der Aufgabenliste wurden während des Sprints vorgenommen? War dies ein Grund für das Nichtvollenden? Wenn dies der Fall ist, ändern Sie weder die Liste noch die Funktionen. Wirf das geänderte Feature in den Backlog, bis es stabil ist.
   • Wie können Sie die Größe und den Umfang einiger Elemente auf einen Wert reduzieren, der im Sprint erreicht werden kann? Wählen Sie eine Kleinigkeit wie eine Verbesserung der Protokollierung, eine einfache Fehlerbehebung oder einen Tippfehler, um ein paar Dinge zu erledigen, damit das Team einen Eindruck davon bekommt, was sie können. Wenn Sie dies nicht tun können, hören Sie auf zu sprinten und planen Sie neu .

5. Zurück zu Schritt eins und wiederholen, bis loslassen ...

Gibt es Dokumentationshindernisse, Kopplungsprobleme beim Erstellen von Abhängigkeiten, Kommunikationsprobleme, nicht genügend Informationen in den Anforderungen? ... Was? Haben die Entwickler ihre Zeit damit verbracht, neue Technologien zu erlernen? Haben sie viel Zeit mit Design verbracht? Wurden Dinge wie das Lernen in der Sprint-Aufgabenliste berücksichtigt?

Glaubst du, dein Team hat gedacht, sie hätten ihre Probleme in jeder Rückschau isoliert? Hat das Team gehandelt, um die Probleme zu beheben? Hat das Team nicht geantwortet und das Management einfach die Lösungen und die Vorgehensweise vorgegeben?

In Anbetracht der langen Zeitspanne stimmt systematisch etwas nicht, nicht nur mit den Entwicklern. Irgendwann (vor Ablauf eines Jahres) hätte jemand im Team (einschließlich des Scrum-Masters) fragen sollen, was wir erreichen können , egal wie klein es ist ?

In Ihrer Situation sind Rückblicke zu spät.
Führen Sie tägliche Stand-up-Meetings durch und erhalten Sie von den Leuten wirklich den Status darüber, was sie in den letzten 24 Stunden getan haben?
Verwendet der Scrum Master diese Meetings, um den Fortschritt jedes Entwicklers an seinen Zielen zu messen?
Sie müssen diesen Teil der Scrum-Methodik verwenden, um den Fortschritt auf Ihrem Weg zu überwachen. Es sollte Ihnen einen guten Einblick in das geben, was die Leute tun.
Sind sie abgelenkt? Verbringen Sie zu viel Zeit mit Kaffee, helfen Sie anderen Leuten bei SE / SO, lesen Sie die Nachrichten oder führen Sie Inspektionen durch, die nicht berücksichtigt werden? Oder sind sie wirklich kopfüber, mit voller Kraft voraus und zutiefst überfordert? Die tägliche Ansicht sollte Ihnen eine gute Idee geben. Es wird auch helfen, die Entwickler auf die bevorstehende Aufgabe zu konzentrieren, damit sie nicht zugeben müssen, dass sie gestern nichts getan haben.
Und natürlich, wenn sie während des gesamten Sprints konstante Fortschritte melden und am Ende immer noch nicht liefern, dann haben sie gelogen und es könnte Zeit für einen neuen Entwickler sein.

Das Abschätzen des Aufwands und der Zeit, die zum Ausführen einer komplexen Aufgabe erforderlich sind, z. B. Programmcode, ist schwierig. Wie Joel Spolsky es ausdrückt:

Softwareentwickler mögen es nicht, Zeitpläne zu erstellen. Normalerweise versuchen sie, ohne eins davonzukommen. "Es wird erledigt, wenn es erledigt ist!", Sagen sie und erwarten, dass ein so mutiger, lustiger Zinger ihren Chef zu einem Anfall von Kichern werden lässt, und in der folgenden Gelassenheit wird der Zeitplan vergessen.

Unternehmen benötigen jedoch Fristen, um operieren zu können. Versuchen Sie, wie Joel vorgeschlagen hat, Evidence Based Scheduling zu verwenden, das Zeitschätzungen mit der damit verbundenen Wahrscheinlichkeit liefert, auf die sich das Management als jede Art von Risiko beziehen kann.

Scrum macht ein paar Dinge.

Erstens wird die Priorisierung gefördert. Der Lieferant der Arbeit muss sagen, was er zuerst tun möchte, und nicht sagen, dass "alles gleich wichtig ist".

Zweitens erzeugt es etwas brauchbares Produkt, auch wenn nicht alles fertig ist. Das ist der Punkt, an dem am Ende jeder Iteration ein "potenziell versandfähiges Produkt" steht.

Drittens ergibt sich eine engere Rückkopplungsschleife. Indem Sie darauf bestehen, dass die Dinge am Ende eines Sprints erledigt werden, vermeiden Sie das Problem, dass 90% der Funktionen vollständig, aber nur zur Hälfte erledigt sind. Wenn Sie auf Termine drängen, können Sie Dinge, die erledigt werden müssen, beiseite schieben, sodass es so aussieht, als ob Sie den Termin fast erreicht hätten, oder Sie können ihn vortäuschen. Wenn Sie eine Definition von erledigt haben und darauf bestehen, dass Dinge erledigt werden, wissen Sie, ob etwas schwieriger ist, als es früher aussieht, anstatt später.

Viertens werden Inventuren vermieden, indem die detaillierte Planung in die Nähe der Arbeit gebracht wird. Das Planen von weit entfernten Objekten ist eine Form von Inventar: Kapital, das für Ressourcen ausgegeben wird, die nicht zum Verkauf oder zur sofortigen Verwendung durch Kunden verfügbar sind. Solches Inventar kann verrotten (Pläne ändern sich unter den Füßen, neue Informationen machen es obsolet), mit den Bedürfnissen in Konflikt geraten (es stellt sich heraus, dass wir kein verteiltes Netzwerk benötigen, weil sich das Ding, das es verwendet, nicht gelohnt hat) und den Wert der versendeten Waren verringern (Wenn im letzten Jahr die Hälfte Ihrer Zeit für die Planung für das nächste Jahr und darüber hinaus aufgewendet worden wäre, hätten Sie doppelt so viel verschickt bekommen, wenn Sie stattdessen an Dingen gearbeitet hätten, die für den Moment bereit sind). Wenn Sie die Planung verlustfrei an die Ausführung heranrücken können (knifflig!), Können Sie den Lagerbestand verringern.

Dies ist nicht der einzige Weg, um diese Probleme zu lösen. Anscheinend verwenden Sie Scrum, um den Entwicklern einen Datenstrom zur Verfügung zu stellen, an dem sie für jeden Zeitraum arbeiten können. In regelmäßigen Abständen fügen Sie neue Aufgaben hinzu und überprüfen den Fortschritt.

Dies ist eine nützliche Methode, um Scrum-Esque-Muster zu verwenden. Es sorgt für einen reibungslosen Arbeitsablauf, eine produktionsnahe Planung, einige Rückkopplungsschleifen usw. Es hat sogar den Vorteil, dass es die Entwicklung nicht verzieht und die Tests nicht an das System anpasst (wenn die Tests am besten mit der Arbeit durchgeführt werden, sind sie im Grunde abgeschlossen) Der Versuch, die Dinge im selben Sprint fertigzustellen und zu testen, zwingt das Back-End des Sprints, keine Neuentwicklung mit sich zu bringen!)

Das Versäumnis, genau das zu tun, was sie in einen Sprint stecken, ist kein Beweis dafür, dass Ihre Entwickler keine großartige Arbeit leisten. Dies bedeutet, dass sie SCRUM nicht aus der Luft folgen, sondern Teile des Frameworks verwenden.

Wenn sie halbiert (oder geviertelt) hätten, wie viel sie für jeden Sprint begangen haben, aber alles andere gleich gehalten hätten, dann wären sie mehr gelaufen, als sie für jeden Sprint begangen hätten! Sie würden die gleiche Menge an Code produzieren lassen. Offensichtlich sind die "Sprintfehler" nicht der wichtige Teil, da dies nur ein internes Prozessdetail ist. Das Ziel der Firma ist es, Scheiße zu machen, und diese Scheiße ist gut. Nicht einem bestimmten Prozess folgen, es sei denn, Ihr Ziel ist eine bestimmte Art der ISO-Prozesszertifizierung.

Der Prozess ist dem Ziel des Erledigten unterworfen.

Andererseits erhalten Sie nicht die gleiche Art von Rückmeldung , da sie nicht den Regeln von SCRUM entsprechen . Sie sollten das resultierende Material untersuchen, um festzustellen, ob die Art der Fehler die Fehler sind, für die SCRUM entwickelt wurde. Gibt es Geschichten, die für immer wie Zombies leben und erst spät getötet werden? Gibt es Geschichten, die einfach erscheinen, explodieren und im Nachhinein die Arbeit nicht wert sind? Ist das Produkt tatsächlich zu dem Zeitpunkt lieferbar, zu dem Sie es benötigen / möchten?

"Software ist fertig, wenn sie fertig ist, nicht früher, nicht später" ist ein Rezept für einen Fehler, wenn Sie nicht definiert haben, wie "fertig" aussieht.

Die meisten Ingenieure werden versuchen, die bestmögliche Lösung zu finden. Dies kann jedoch leicht zu einer Vergoldung führen, insbesondere bei weniger erfahrenen Ingenieuren. Die einzige Verantwortung des Managements besteht darin, genau zu definieren, wo das Ziel liegt, und Ihre Ingenieure in diese Richtung zu lenken. Ingenieure versuchen häufig, seitliche Abbiegungen vorzunehmen, um die Funktionen zu verbessern, und es ist Sache des Managements, zu entscheiden, ob diese seitliche Abbiegung die Dinge auf lange Sicht beschleunigt oder ob sie sich nur zur gleichen Verbesserung verbessert.

Der Punkt der agilen Entwicklung ist, dass jedes neue Stück Arbeit so gut wie nötig sein sollte, um diesen Sprint zu meistern UND KEIN BESSERES !!!!!! Ja, das ist ungefähr die Betonung, die ich in StackOverflow hinzufügen kann - und es ist immer noch nicht genug Betonung. Wenn Sie feststellen, dass Leute Dinge hinzufügen, die in dieser Sekunde nicht benötigt werden, müssen sie darin geschult werden, wie man agile Entwicklung richtig macht.

Oh, und ja, wir verwenden Retrospektiven.

Oh gut, also wissen Sie, warum Ihr Team versagt, oder? Sie hatten 36 Gelegenheiten, darüber zu sprechen, was funktioniert hat und was nicht. Die Scrum-Meister sollten also genau wissen, wie sie die Probleme lösen können, oder?

Ich habe eine Ahnung, wie Sie beschreiben, dass Ihr Unternehmen in die "SCRUM macht uns produktiv" -Mentalität gefallen ist. Die Wahrheit ist, dass SCRUM Ihre Produktivität nicht steigert. Vielmehr handelt es sich um ein Tool, mit dem Sie Ihre Produktivität auf eine Weise steigern können, die die Realität der Entwicklung erkennt, die von Management und Entwicklern häufig übersehen wird.

Was hat der Scrum Master als potenzielle Probleme mit dem Team identifiziert? Vergeben sie ständig doppelt so viel Arbeit, wie sie bewältigen können? In diesem Fall sollte der Scrum-Master vorsichtig vorschlagen, weniger Arbeit aufzunehmen, da der Scrum-Master die Geschwindigkeit des Teams ablesen kann.

Wann ist es fair, das Problem in der Qualität der Entwickler zu suchen?

Die Zeit, in der man nach dem Problem in der Qualität der Entwickler suchen sollte, ist der Moment, in dem Sie sicher sind, dass dies das Problem ist. Dies ist keine neue Ausgabe von SCRUM. Dies ist die Realität des Geschäfts. SCRUM sollte Ihnen wesentlich mehr Informationen über die Fähigkeiten Ihrer Teammitglieder geben als herkömmliche Ansätze. Sie sollten wissen, ob das Problem "Softwareentwickler sind nicht gut genug" oder "Managementerwartungen sind unrealistisch" ist. Dies ist die Zeit für das Management, um das zu tun, was es am besten kann: die richtigen Leute für den Job zu finden, damit das Unternehmen Geld verdienen kann. Wenn Sie nicht wissen, wo das Problem liegt, stellen Sie sich vor, wie schwer es wäre, es ohne all diese Rückblicke zu sagen!

Wenn Sie der Meinung sind, dass die Leute gut genug sind (was bedeutet, dass ihre Einstellung kein Fehler für das Management war), dann wäre mein Rat, über den Tellerrand hinaus zu denken. Wenn die Arbeit nicht erledigt wird, sollten Sie die Form der Arbeit für die Entwickler ändern. Eine der einfachsten Möglichkeiten, die ich gefunden habe, um die Fristen für die Sprint-Fertigstellung einzuhalten, besteht darin, die FERTIG-Kriterien so anzupassen, dass Sie mit dem Ergebnis zufrieden sind, unabhängig davon, wie es ausgeführt wird. So wird das Fertigstellen zur Tautologie.

Hier liegt die Verantwortung beim Management, insbesondere beim SCRUM-Master. Der Trick besteht darin, Aufgaben zu schreiben, die, wenn sie erledigt sind, sehr wertvoll sind, aber wenn sie unvollständig bleiben, immer noch einen ausreichenden Mehrwert für das Unternehmen bieten, um ihren Gehaltsscheck wert zu sein. Nach 18 Monaten würde ich erwarten, dass Ihre Rückblicke Ihnen etwas beigebracht haben. Wenn dies nicht der Fall ist, sollten Sie die Geschichten möglicherweise mit der ausdrücklichen Absicht verfassen, fehlgeschlagene Geschichten ausfindig zu machen, die in Ihrem Unternehmen nicht stimmen, und sie ans Licht bringen. Dies würde dem Unternehmen immense wertvolle Daten liefern, wenn man bedenkt, wie frustriert das Unternehmen mit dem Entwicklungsteam zu sein scheint. Das Problem können in der Tat die Entwickler sein, wie Sie fragen. Oder das Problem könnte eine Pathologie in der Denkweise des Unternehmens sein, von der Sie bis jetzt keine Ahnung hatten!

Wenn das Problem in der Tat beim Unternehmen und nicht bei den Entwicklern liegt, sind die Informationen, die Sie aus diesen unvollständigen Geschichten abrufen, möglicherweise mehr wert als das Produkt, das Sie aus den erfolgreichen Geschichten zusammengetragen haben! Möglicherweise sind es die Informationen, die Ihr gesamtes Unternehmen retten! Das scheint mir wirklich wertvolle Informationen zu sein, und Sie können SCRUM als Werkzeug verwenden, um sie zu sammeln.

"Wann ist es fair, die Qualität der Entwickler zu betrachten?"

Die ganze Zeit. Offensichtlich sind einige Menschen produktiver als andere. Sie brauchen keine Entschuldigung als Arbeitgeber, um ihre Leistung zu messen.

Das Schwierige ist, wie Sie es tun. Mein Rat ist, einige erfahrene Vertragspartner anzustellen, die zusammen mit Ihrem Dauerwellenpersonal an den gleichen Aufgaben arbeiten, die von Ihren Dauerwellen-Mitarbeitern geschätzt werden, und zu prüfen, ob sie eine höhere Geschwindigkeit haben.

Dies gibt Ihnen einen guten Vergleich mit dem aktuellen Markt, ohne Sie an eine langfristige Miete zu binden.

Es könnte auch den Jungs von der Dauerwelle einen Kick in den Arsch geben.

Wenn sich die Auftragnehmer darüber beschweren, dass sie auf Qualität usw. verzichten, um an Geschwindigkeit zu gewinnen, führt dies zu einem Gespräch darüber, wo der geschäftliche Wert liegt. Langfristige Wartbarkeit oder kurzfristige Lieferung.

Wenn es das langfristige Zeug ist, werden Sie gezwungen, es zu quantifizieren und es als Anforderung in den Sprint zu schreiben!

Es gibt bereits mehrere ausgezeichnete Antworten. Insbesondere Fehleinschätzungen, zu viel Engagement und / oder ungeplante Arbeiten sind häufige Ursachen für einen Schlupf.

Aber ich bin gespannt, warum "[Ihre] Entwickler die Funktionen auswählen, die sie in jeden Sprint einbeziehen möchten". Die Entwickler sollten in der Regel zuerst an den Features mit der höchsten Priorität arbeiten - und die Priorität ist eine Geschäftsentscheidung, dh sie sollte vom Product Owner ausgehen, der als Proxy für die Geschäftsinteressenten fungiert.
(Hiervon gibt es Ausnahmen. Insbesondere werden Features mit hohem Risiko in der Regel früher ausgeführt. In einigen Fällen hängt ein Feature für Benutzer von anderen Funktionen ab, z. B. "Wir müssen wirklich eine Datenbank hinzufügen, bevor wir X implementieren können". )

Andererseits handelt es sich bei Schätzungen um technische Entscheidungen, die von Geschäftsleuten nicht nachträglich getroffen werden sollten . Sie sagen nichts dazu - ich spreche das nur deshalb an, weil es meiner Erfahrung nach für Geschäftsleute üblich ist, zu bestimmen, wie lange es dauern soll, wenn Entwickler entscheiden, woran sie arbeiten.

Es hört sich so an, als ob Sie einen ziemlich gestörten Prozess haben. Ich würde zumindest vorerst davon abraten, Entwicklerberater hinzuzuziehen, da sich dies wahrscheinlich negativ auf die Moral auswirken wird. Es hört sich jedoch so an, als könnte Ihre Organisation Hilfe beim Projektmanagement gebrauchen. Hier würde ich mit einem erfahrenen agilen Coach anfangen - wenn nicht für ein mittel- bis langfristiges Engagement, dann zumindest für eine Beurteilung oder einen "Gesundheitscheck". Ein guter Trainer wird Ihnen sagen, ob Sie unterdurchschnittliche Entwickler haben, aber zumindest auf diese Weise wird das gesamte Team (nicht nur die Entwickler) überprüft.

Eine weitere Beobachtung: Nach meiner Erfahrung ist es sehr schwierig, Scrum als Projektmanagement-Methode zum Erfolg zu führen, wenn Sie nicht auch gute Entwicklungsprozesse verfolgen. Führen Sie automatisierte Komponententests durch? oder noch besser automatisierte abnahmeprüfungen? Koppeln sich Ihre Entwickler oder führen Sie zumindest häufige Codeüberprüfungen und / oder Komplettlösungen durch? Übst du irgendeine Form der kontinuierlichen Integration?