Schwarm in Scrum

Swarming ist die Handlung aller Mitglieder des Entwicklungsteams, die während des Sprints jeweils nur eine Anforderung bearbeiten. Obwohl dies kein Scrum-spezifischer Grundsatz ist, ist es für Teams so effektiv, ihren Sprint-Backlog auszuführen, so dass weitere Diskussionen erforderlich sind.

Noch einmal, einer der Hauptvorteile von Scrum ist, dass Entwicklungsteams die Anforderungen von Start und Ziel erfüllen, um eine potenziell lieferbare Produktinkrementierung innerhalb einer relativ kurzen Zeitspanne zu erreichen und diesen Zyklus mit immer wieder neu erlernten Lektionen zu wiederholen. .. Das Ziel ist es, möglichst viele Anforderungen zu erfüllen und nicht nur zu starten.

Swarming ermöglicht Teams die folgenden Vorteile:

  • Maximierte Erfolgschancen mit den Fähigkeiten und Fähigkeiten des gesamten Teams, das sich auf eine einzige Anforderung konzentriert.

  • Vervollständigen Sie den gesamten Zyklus von Planung, Entwurf, Entwicklung und Test bis zur Fertigstellung für jede Anforderung.

  • Beheben Sie Probleme und Hindernisse heute, im Jetzt.

  • Verringern Sie drastisch die Einführung von Fehlern in ein Produkt im Voraus durch Pairing und Single-Tasking (im Gegensatz zu Multitasking).

  • Beseitigen Sie Single Points of Failure in Wissen, Prozess und Skillsets.

  • Die wichtigsten Anforderungen werden erledigt, vollständig erledigt und zuerst erledigt.

Wenn die Teammitglieder sehen, wie alle ihre Mitentwickler an einer Aufgabe arbeiten, und es bleibt ihnen nichts übrig, um an der gleichen Anforderung (der User Story) zu arbeiten, ist es für sie selbstverständlich, sie produktiver zu betrachten. Anforderung statt die anderen auf die aktuelle Anforderung im Gange zu helfen. Diese Tendenz kann jedoch aus dem Ruder laufen, bis sich die Teams mit mehreren Anforderungen konfrontiert sehen, aber keiner von ihnen ist fertig. Durch Shadowing, Pairing, Recherche oder Hilfe auf welche Art und Weise die Aufgabe erledigt wird, werden Entwicklungsteams dieses Risiko vermeiden.

Bleiben Sie konzentriert. Stoppen Sie den Start und beginnen Sie mit dem Ende.

Dieser Prozess stellt sicher, dass in jedem Sprint etwas vollständig entwickelt wird und den Stakeholdern zur Verfügung steht. Jeder Sprint wird "versendbare" Ergebnisse liefern. Die Anstrengungen des Entwicklungsteams sind konzentriert, die Teamarbeit wird dadurch verbessert, dass sie ermutigt werden, sich gegenseitig zu helfen, und der iterative Prozess des Scrum wird ins Spiel gebracht.

Vor kurzem führte Microsoft eine Studie über die Auswirkungen von Multitasking durch. Das Ergebnis war, dass Multitasking einfach nicht funktioniert. Im Durchschnitt dauert es 15 Minuten, um Ihr Gehirn wieder auf das Niveau zu bringen, auf dem es sich befand, bevor Sie den Anruf oder die E-Mail beantwortet haben. Studien haben auch gezeigt, dass eine Unterbrechung so kurz wie 4 ist.4 Sekunden verdreifachen die Anzahl oder Fehler bei nachfolgenden Aufgaben, die eine Sequenzierung erfordern. Die Reduzierung von Multitasking in Ihrem Entwicklungsteam wird Ihnen einen guten Start in die 30-40-prozentige Steigerung der Produkt-zu-Markt-Zeit bringen.

Thrashing ist, wenn Entwickler zwischen Projekten, Anforderungen und Aufgaben hin und her springen - Kontextwechsel. Thrashing erhöht die Zeit, die für die Ausführung von Aufgaben erforderlich ist, um 30 Prozent. Wenn Sie nicht genug Leute haben, um die Arbeit als engagierte, schwärmerische Entwickler zu übernehmen, haben Sie definitiv keine Zeit, sie zu verprügeln.

Wenn eine Anforderung in der Spalte Akzeptieren vom Product Owner abgelehnt wird, haben die Entwickler mehrere Optionen:

  • Beenden Sie ihre aktuellen Aufgaben, und wenn diese abgeschlossen sind, wird die abgelehnte Anforderung ausgeführt.

    Dies ist möglicherweise die beste Option, wenn im Sprint noch viel Zeit verbleibt, um die aktuellen Aufgaben und die abgelehnten Anforderungen abzuschließen.

  • Geben Sie ihre aktuellen Aufgaben auf, um die abgelehnte Anforderung zu verwirklichen.

    Dies könnte die beste Option sein, wenn nicht viel Zeit im Sprint verbleibt, um beide zu beenden.

Der Product Owner entscheidet die Priorität, wenn er mit dieser Entscheidung konfrontiert wird. Andere Variablen als die verbleibende Zeit im Sprint können die Entscheidung des Product Owners beeinflussen. Während das Team ihr Lernen inspiziert und sich während eines Sprints anpasst, kann die abgelehnte Geschichte für das Erreichen des Sprintziels weniger wertvoll werden als die nächste laufende Anforderung, und so bleibt, auch wenn im Sprint noch Zeit bleibt, beides zu tun, das Risiko, nicht zu beenden. Die in Bearbeitung befindliche Anforderung kann höher sein als das Beenden der zurückgewiesenen Anforderung nicht.

In jedem Fall behalten die Priorität und die enge tägliche Abstimmung mit dem Product Owner während des gesamten Sprints das gesamte Scrum-Team (einschließlich des Product Owners) im Fokus und im wahrsten Sinne des Wortes.

Scrum-Teams sollten sich immer drängen. Wenn Entwicklerteams jedes Mal 100 Prozent ihres Sprint-Rückstands erreichen, drängen sie sich vielleicht nicht ans Limit. Ein hoher Prozentsatz des Abschlusses des Sprint-Backlogs sollte das Ziel sein, aber es sollte nicht erwartet werden, dass Scrum-Teams jedes Mal 100 Prozent erreichen. Während sich die Entwicklungsteams selbst anstrengen, helfen Scrum-Master wie Luftfahrtingenieuren dem Scrum-Team dabei, Wege zu finden, den Widerstand zu reduzieren, um effektiver zu werden und in jedem Sprint mehr zu erreichen. Solange die Teams ihre Sprints abschließen und die Geschwindigkeit erhöhen, erkennen sie den kontinuierlichen Verbesserungsvorteil von Scrum.