Team macht konsequent keine Sprints

Der Zweck von Sprints besteht nicht darin, Punkte zu liefern, sondern Wert zu liefern. Das Team verpflichtet sich nicht, eine bestimmte Menge an Punkten oder eine Reihe von Product-Backlog-Einträgen zu liefern. Stattdessen prognostiziert das Team im Rahmen der Sprint-Planung, wie viel Arbeit es bewältigen kann. Während des gesamten Sprints sollte sich das Team darauf konzentrieren, das Sprintziel zu erreichen, anstatt eine bestimmte Arbeit zu erledigen oder so viele Punkte oder andere Leistungsmaßstäbe zu erreichen.

Wenn ich mir die spezifischen Praktiken anschaue, sehe ich mehrere potenzielle Probleme oder Verbesserungsmöglichkeiten.

Ihr Verfeinerungsprozess scheint mangelhaft zu sein. Jüngste Überarbeitungen des Scrum-Leitfadens schlagen vor, dass etwa 10 % der Kapazität des Entwicklungsteams für das Product Backlog Refinement zugewiesen werden sollten. Wenn Sie ein Entwicklungsteam von 3 Personen und eine Standardarbeitswoche von 40 Stunden haben, würde ich ungefähr 12 Stunden pro Woche für die Verfeinerung erwarten. Es gibt keine definierte Methode zur Durchführung der Verfeinerung. Bei einigen Teams, mit denen ich zusammengearbeitet habe, trafen sich alle ein paar Mal pro Woche. Bei anderen arbeiteten die Leute einzeln an der Verfeinerung und kamen dann für etwa eine Stunde pro Woche zusammen, um sich abzustimmen. Das Team muss herausfinden, was für es funktioniert, aber es ist wichtig, dass es sich um eine Aktivität des gesamten Teams handelt, um das Wissen zu verbreiten und das gesamte Team dazu zu bringen, sich für die geleistete Arbeit einzusetzen.

Ich glaube, dass die schlechte Verfeinerung zu einer Reihe der beschriebenen Probleme führt, einschließlich eines nicht vollständigen Verständnisses der Funktionen, die sie erstellen sollen, und der zu langen Zeit, um die Funktionen zu entwickeln. Es ist sehr wahrscheinlich, dass das mangelnde Verständnis zu längeren Entwicklungszeiten führt.

Die "Planung 1" und "Planung 2" ist mir nicht klar. Sprint Planning ist eine einzelne Sitzung. Es gibt zwei Aspekte – der erste ist die Bestimmung, was basierend auf Prognosen erstellt werden soll, und der zweite Aspekt ist die Bestimmung, wie es erstellt wird. Genauer gesagt, das primäre Ergebnis für den ersten Teil der Sprint-Planung ist ein Sprint-Ziel, und das Ergebnis für den zweiten Teil ist ein Plan, um dieses Sprint-Ziel zu erreichen.

Die Teamgröße und -zusammensetzung können ebenfalls Probleme bereiten.

Obwohl Scrum keine Regeln für eine minimale oder maximale Teamgröße erzwingt, ist Scrum am effektivsten mit einer Entwicklungsteamgröße zwischen 3 und 9. Sie haben 13, vielleicht 15 (je nachdem, ob die Teamleiter Teil des Entwicklungsteams sind). . Das fühlt sich sehr groß an und die Kommunikation wird mit so vielen Menschen schwierig.

Ich möchte auch darauf hinweisen, dass Scrum keinen "Teamleiter" kennt. Ein solches Konzept führt tendenziell dazu, dass die Arbeit den Menschen aufgeschoben wird, die die Arbeit erledigen, anstatt in einen Sprint und dann in die Entwicklung gezogen zu werden. Es fördert auch keine selbstorganisierten Teams.

Es gibt keine Erwähnung des Daily Scrum oder der Sprint Retrospektive, aber ich würde zwei Dinge vermuten. Erstens sind Sie mit einem so großen Team nicht in der Lage, ein Daily Scrum in einem angemessenen Zeitraum effektiv abzuhalten. Zweitens können viele dieser Probleme in einer gut geführten Sprint-Retrospektive ans Licht kommen.

Das größte Problem, das ich sehe, ist die schlechte Kommunikation. Die Teamgröße und der Mangel an ständiger Zusammenarbeit sind wahrscheinlich die beiden größten Treiber.

Es hört sich so an, als hätten Sie es mit einem großen Team zu tun, und ich habe den Eindruck, dass Sie Scrum oder Elemente davon machen. Wenn dies nicht der Fall ist, können Sie den Rest dieses Beitrags wahrscheinlich ignorieren.

Angesichts der von Ihnen beschriebenen Probleme würde ich vorschlagen, dass Sie Ihr großes Team in mehrere kleinere Teams aufteilen, die denselben Rückstand abarbeiten. Es ist eine große organisatorische Veränderung, also keine, die man auf die leichte Schulter nehmen sollte, aber es ist ein Ratschlag, den ich den meisten in dieser Situation geben würde. Kleine Teams können flexibel sein und schneller reagieren.

Einige Beobachtungen aus den von Ihnen bereitgestellten Informationen:

• Es hört sich so an, als ob Sie die Verantwortlichkeiten/Verantwortlichkeiten in Ihrem Entwicklerteam/Ihrer Organisation zumindest überprüfen möchten. Wer ist für die Bereitstellung der Teamergebnisse verantwortlich? Was sind die Verantwortlichkeiten der Teamleiter und der anderen Mitglieder?

• Es hört sich so an, als ob sich das Team nicht voll verantwortlich für seine Arbeit und seinen Output fühlt. Was ist mit jedem einzelnen Teammitglied? Wie empfinden sie die Situation? Worauf führen sie dieses „Versagen“ zurück?

• Weniger Mitglieder zu haben, kann helfen, alle zugrunde liegenden Probleme zu identifizieren, die in Ihrer aktuellen Konstellation nicht auftauchen. Ist jedes einzelne Mitglied voll ausgelastet oder hat es mit wiederkehrenden Problemen zu kämpfen?

• Weniger Teammitglieder in einer Gruppe zu haben, kann dazu beitragen, die Gruppe zu stärken und sie effizienter zu machen.

Überlegen Sie, ob 1 Lead + 2 Entwickler + 1 QA + 1 PO ein Team bilden könnten. Sehen Sie Gründe, warum das nicht funktionieren sollte? Sind Ihre Stories / Backlog bereit dafür? Ist Ihr Code-Repository dafür bereit?

Wenn das obige funktionieren könnte, könnten Sie drei dieser Konstellationen mit den aktuellen Teammitgliedern erstellen? Ist in jedem Team genügend Domänenwissen vorhanden? Machen Sie sich keine Sorgen, wenn ein oder zwei Personen zwei Teams überbrücken müssen. Dies kann durch Einstellung oder spätere Neukonfiguration überwunden werden, wenn Sie das Gefühl haben, auf dem richtigen Weg zu sein.

Bitten Sie sie, weniger Geschichten zu übernehmen und versuchen Sie, ein paar Sprints zu beenden. Legen Sie die Geschwindigkeit für jedes Team fest. Erst dann nehmen Sie weitere Geschichten auf.

Viel Glück unabhängig von den Maßnahmen, die Sie umsetzen möchten.

Ich gehe davon aus, dass Ihr Team von etwas Coaching/Mentoring profitieren könnte, da es anscheinend einige komplexe Probleme gibt, die sie nicht wirklich übernehmen.

Einige Beobachtungen. Sie erwähnen insgesamt 15 Personen, was für ein Scrum-Team ungewöhnlich groß ist. Teilen Sie sich in mehrere Teams auf und halten Sie es auf weniger als 10 pro Team. Welche Rolle spielen die Teamleiter? Es gibt keinen „Lead“ in Scrum, aber die Tatsache, dass Sie diese Frage stellen, deutet darauf hin, dass sie auch keine sehr effektiven Leads sind. Warum den nächsten Sprint in Woche 2 des aktuellen Sprints planen? Das erscheint kontraproduktiv, weil es das Team in einer kritischen Zeit ablenkt. Planen Sie am Tag 1 jedes Sprints und belassen Sie es dabei.

Da sie Schwierigkeiten haben, zwei Wochen Arbeit einzuschätzen, kann es sich lohnen, Sprints auf eine Woche zu verkürzen. Das könnte die Schätzschwierigkeiten ein wenig lindern, unerwartete Scope-Änderungen reduzieren und das Team wird wahrscheinlich von der nötigen Disziplin für kurze Sprints profitieren. Versuchen Sie auch, eine Zeit lang auf punktebasierte Schätzungen zu verzichten. Der Grund für die Schätzung der Teams besteht darin, herauszufinden, was in den Sprint passen kann. Punkte scheinen für sie nicht zu funktionieren, und vielleicht ist es einfacher, sie einfach zu bitten, die Dinge, von denen sie sicher sind, dass sie sie tun können, von der Spitze des Rückstands auszuwählen.

Dies sind sehr reale Probleme, mit denen viele Menschen konfrontiert sind.

Ich werde versuchen, einige Ratschläge / Meinungen (Sie müssen sie nicht annehmen) zu Ihren Punkten zu geben

Wir haben 2-wöchige Sprints – das ist ein guter Anfang. Während des Sprints erhält das Produktteam Anfragen vom Kunden und sammelt die Anforderungen, wobei es Details an den Team-/Tech-Lead weiterleitet, bevor der Rückstand priorisiert wird (wir haben jedoch keine spezielle Grooming-Sitzung Geschichten werden vor der Planung richtig ausgearbeitet 1) Jede zweite Woche donnerstags planen wir

Wenn Sie Planung 1 angeben, gehe ich davon aus, dass es eine Planung 2 gibt, würde ich vorschlagen, diese in Backlog-Grooming und Sprint-Planung umzubenennen – beide haben unterschiedliche Funktionen. Beim Backlog-Grooming müssen Sie sicherstellen, dass das Team alle Informationen in den Tickets hat, sie müssen sie gemeinsam durcharbeiten und dürfen nicht erwarten, dass sie Dinge tun (wie ihre eigenen Geschichten erstellen usw. – das ist normalerweise für sehr reife Teams) – also machen sicher, dass Sie eine Definition von fertig und eine Definition von erledigt haben.

Lassen Sie den PO jedes Ticket mit ihm durcharbeiten und die Aufgabe/Geschichten erstellen, und wenn alle Informationen vorliegen, lassen Sie ihn schätzen (jetzt kann dies am Anfang einige Zeit dauern, aber je öfter er es tut, desto besser werden sie darin werden).

Apropos Sprints – das ist hier ein sehr schmaler Grat, ein Sprint ist ein Sprint, man steckt nicht mehr Arbeit in einen Sprint, wenn er schon begonnen hat, man stoppt einen Sprint erst, wenn das Sprint-Ziel hinfällig ist, aber ich weiß Dinge in der realen Welt passieren und wir bekommen P1s, die kritisch sind, normalerweise auf 2 Arten ansprechen, wenn es absolut kritisch ist, dann stoppe die Arbeit (erzeuge eine Spitze) und behebe das Problem, dann fahre mit dem Sprint fort – das könnte verwirrend sein, andere Option ist bis zum Ende des Sprints warten zu lassen (aber normalerweise nicht der Fall, da es geschäftskritisch ist) – die Kommunikation mit den Stakeholdern usw. ist hier der Schlüssel (aber Sie haben auch die Möglichkeit, einen BAU-Trupp zu haben, der sich um solche Dinge kümmert.

Diese Sitzung wird vom Produktteam durchgeführt, wir versuchen, so viele Stories im Rückstand wie möglich zu schätzen, der Rückstand wird basierend auf der aktuellen Priorität geordnet.

Das ist großartig!

Freitags in jeder zweiten Woche planen wir

Diese Sitzung wird vom Teamleiter geleitet. Es wird erwartet, dass das Team zwischen Sitzung 1 und 2 einige Zeit brauchte, um die erforderlichen Arbeiten zur Anpassung der Schätzungen durchzuführen, aber wir gehen auf die technischen Details der erforderlichen Änderung ein. Planung 1 ist für anfängliche Schätzungen , dies kann sich während der Planungssitzung 2 ändern. Das Team bleibt für 2 Wochen, es gibt Fälle, in denen es zu Umfangserweiterungen kommt. Versuchen Sie jedoch, dies so weit wie möglich einzuschränken, da wir einen dedizierten Entwickler haben, der an Produktionsproblemen arbeitet, der nicht Teil davon ist Sprintarbeit

Das klingt für mich wie ein paar gemischte Probleme, 1 der Unterschied zwischen Planungssitzungen – das ist ein schwieriger Punkt, aber es gibt einen PO aus einem bestimmten Grund und es gibt ein Lieferteam aus einem bestimmten Grund, Sie müssen sie für ihre Stärken einsetzen und Rollen 1. 1. Ein Team muss an der Grooming-Sitzung (Planung 1) zusammenarbeiten und die Schätzungen als Team durcharbeiten – es sollte nicht mehr Erwartungen an das Team geben, als den Artikel zu liefern, wenn er der Definition von entspricht Erledigt. – eine Grooming-Sitzung kann bis zu 4 Stunden dauern (time box it) 2. 2. Nur Standups als Updates haben (Teams müssen sich auf die Bereitstellung konzentrieren und nicht mikroverwaltet werden) 3. 3. Scope Creap ist ein stiller Killer, sollte aber verwaltet werden in Geschichten und Verbesserungen nicht nur das gleiche Ticket größer 4 entwickeln. 4. Es gibt mehr

Die Probleme, mit denen ich konfrontiert bin, sind die folgenden:

Das Team kommuniziert nicht, dass es keine Sprint-Deadlines geben wird

Dies kann eine ganze Reihe von Gründen haben, Vertrauen, Transparenz, Risikobereitschaft, Unterschätzung usw. – wenn der Teamleiter nun ihr Vorgesetzter ist, kann dies auch zu Problemen führen, da die Leute sich ihrem Teamleiter nicht immer öffnen, obwohl sie es sollten und es sollte eine starke berufliche Bindung bestehen.

Die Empfehlung liegt in der Pflege (Planung), um die Geschichten klein genug zu machen, um sie einzeln zu verfolgen – lassen Sie das Team gemeinsam entscheiden, ob die Schätzungen zusammenarbeiten, und ziehen Sie sie zur Rechenschaft.

Das Team scheint die angeforderten Funktionen nicht vollständig zu verstehen (Könnte auf fehlende Anforderungen hinweisen, aber ich glaube nicht ganz)

Würde wieder sicherstellen, dass 1. Team die Pflege richtig macht und dass sie richtig zusammen schätzen (nicht einzeln, aber gleichzeitig, dann Fragen stellen und sehen, warum die Leute die Dinge anders denken) Aber ich stimme zu, dass es an Anforderungen fehlen könnte oder Verständnis für sie

Das Team braucht zu lange, um Funktionen zu entwickeln, und geht über die erwartete Lieferschätzung hinaus. Das Team ergreift während der Lücke zwischen Planung 1 und 2 nicht die Initiative, zukünftige Geschichten durchzugehen

Das wiederum bringt mich zum Grooming (sollte die einzige Sitzung sein, in der Sie den Rückstand für die zukünftige Arbeit pflegen – in Ihren Worten ist es die Planung 1) – dann nehmen Sie die Planung (Sitzung 2) und planen die Arbeit für Ihren nächsten Sprint. Wenn die Schätzung zu lange dauert, könnte dies bedeuten, dass die Geschichte nicht richtig dimensioniert/erklärt/durchgearbeitet wurde. Für mich scheint es einen Mangel an Verständnis, Prozess und Teamarbeit zu geben (nicht insgesamt, aber es hört sich so an, als müsste dieses Team nur in eine Rhythmus)

Wenn Sie sich die Teamgröße ansehen, teilen Sie sie in 2 Teams auf. Sie ist zu groß für einen einzelnen Kader (Empfehlung ist 7 + - 2). Auf diese Weise können Sie die Teams einzeln messen und die Arbeit usw. überprüfen, da ein so großes Team eine Herausforderung sein muss managen

Sind die Teamleiter den Teams/Squads gewidmet? als ob sie nicht an der Schätzung beteiligt sein sollten usw. :)

Irgendwann, wenn der gesamte Prozess usw. gelöst ist und sie immer noch nicht funktionieren, müssen Sie sich möglicherweise die individuelle Leistung ansehen, aber das sollte der letzte Ausweg sein!

Berechnen Sie die Geschwindigkeit des Teams , indem Sie die durchschnittliche Anzahl an Story Points nehmen, die das Team in den letzten 3 Sprints liefern konnte. Verwenden Sie die Geschwindigkeit als Kapazität des Teams für zukünftige Sprints.

Auf diese Weise haben Sie in jedem Sprint einen realistischen Arbeitsaufwand und können Ihrem Kunden eine weitaus zuverlässigere Schätzung liefern.

Sobald Sie in jedem Sprint eine realistische Menge an Arbeit leisten, können Sie in den Retrospektiven einige Zeit damit verbringen, die anderen Probleme zu lösen.

Ein weiterer unmittelbarer Gedanke ist, dass Sie vielleicht das „Anforderungssammeln“ und „Bestimmen, was erforderlich ist, um diese Anforderungen zu erfüllen“ vor oder sogar zwischen Ihre Sprints legen möchten. Vielleicht haben Sie zwischen jedem Sprint ein paar Nicht-Sprint-Tage, an denen Sie sich richtig darauf vorbereiten, was der nächste Sprint sein sollte, und dies verwenden, um die Auswahl des Teams zu leiten, was aufgenommen werden soll. Geben Sie ihnen „einen vollen zweiwöchigen Sprint, um das zu erreichen“ , was sie sich vorgenommen haben. Ich entwickle jetzt schon seit (koff, koff ...) Software, und ich sehe wirklich nicht, wie irgendjemand all diese Dinge tun könnte, die Sie "in zwei Wochen" beschreiben. Vergiss für einen Moment,sagt, und suchen Sie nach einem anderen Arbeitsablauf, der für Ihren Fall realistischer ist. Jede Organisation ist anders, und das ist in Ordnung.