Wie man ein Scrum-Team aufteilt: Neue Teams bei FQ erstellen

Letztes Jahr Chris Ngo hatte einen Beitrag darüber, wie man einen Scrum-Team-Split durchläuft aus der Sicht eines Ingenieurs. Dieser Beitrag ist ein schrittweiser interner Prozess, den wir in der Regel verwenden und wiederholen, um Scrum-Teams aufzuteilen, wobei wir Ziele wie Stabilität, Entkopplung und frühzeitiges Gelingen vor Augen haben. Wie bei den meisten Unterlagen kann Ihr Kilometerstand variieren und es kann zu Anpassungen für Ihre Teams und Ihr Unternehmen kommen.

Das Problem

In der Regel trennen wir neue Scrum-Teams von den bestehenden bei FloQast R&D, wenn:

• Der aktuelle Rückstand des Teams beträgt etwa ein Jahr oder länger
• Wir wollen früher als später zu diesen Backlog-Elementen kommen

Ein Teamwechsel kann für die Teammitglieder eine erschütternde Erfahrung sein, daher prüfen wir die Bewegung sorgfältig. Wenn es schlecht gemacht wird, kann es zu Instabilität im Team, eng gekoppelten Codebasen und einer längeren Storming-Phase führen, ohne dass unsere Kunden zufrieden sind.

Annahmen

• Bei FloQast haben die meisten unserer Engineering-Scrum-Teams 2-4 Full-Stack-Softwareingenieure und einen Qualitätsingenieur pro Team, und ihre Arbeit ist ebenfalls Full-Stack. Es gibt einige Scrum-Teams, die hauptsächlich aus Backend- oder Frontend-Teams bestehen.
• Neben dem Personalmanagement und der technischen Beratung sind unsere Engineering Manager auch als Agile- und Scrum-Leads tätig.
• Ein Großteil dieses Beitrags geht auch davon aus, dass es sich um ein Team mit einer langen Roadmap handelt und nicht um ein neues experimentelles Team, in dem wir eine einzigartige Kundenchance validieren. Für diese Teams kannst du die ersten zwei oder drei Schritte überspringen.

(So) machen wir das 🎵

Schritte

• Finden Sie die Datengrenzen
• Definieren Sie eine Roadmap
• Selbstorganisierende Teams
• Team-Kickoff
• Lieferung in Sprint 1

👩🏽 ‍ 💻 Datengrenzen

Tor: Die Schaffung einer fokussierten Domain für ein Team läuft darauf hinaus, die Grenzen zu finden, die unseren aktuellen und zukünftigen Kundenbedürfnissen entsprechen.

Was: Sieh dir die Epen für das Team an und finde anhand der Daten, Codebasen, Funktionen und Epen heraus, welche zukünftige Roadmap zu Team 1 und Team 2 gehört.

Wer: Führung auf POD-Ebene (Produktmanager, technischer Leiter, technischer Leiter, falls zutreffend)

Leistung: Klare Kenntnis der Daten- und Produktbereiche, für die ein neues Team verantwortlich sein wird, sowie aller gemeinsamen Grenzen mit anderen Teams.

🛣️ Definieren Sie eine Roadmap

Ziel: Durch das Verständnis der Produkt- und Datengrenzen kann Pod Leadership die hochrangigen Initiativen überprüfen, an denen das Team in den nächsten sechs Monaten oder länger arbeiten wird.

Was: Stellen Sie auf der Grundlage der Domain-Übung einen Zeitplan für mehr als 4-6 Monate für jedes Team sicher. Eine nachhaltige Roadmap reduziert die Instabilität/den Stress, der durch einen ungesunden Teamrückstand entsteht. Wenn es keine ausreichend lange Roadmap gibt, ist dies eine Gelegenheit zu überlegen, ob wir überhaupt ein neues Team zusammenstellen müssen oder ob wir stattdessen bestimmte Initiativen in Team 1 anders priorisieren sollten. Sobald die Epen aufgeteilt sind, wirf einen Blick auf die Roadmaps. Ist ein Team stark ausbalanciert, während das andere leicht ist? Gibt es Bereiche, in denen die Teams auf denselben Codebasen arbeiten werden? Wie könnten wir das reduzieren? Sieht jedes Team in seiner Domäne generell wie ein Full-Stack aus? Wenn nicht, wirkt sich das auf die Einstellung/Rekrutierung für das Team aus?

Wer: Führung auf POD-Ebene (Produktmanager, technischer Leiter)

Leistung: Hochkarätige Epen für zwei Teams

🧠 Selbstorganisierende Teams

Ziel: Die Domains und die Roadmap werden immer offensichtlicher, aber wer im Team sein wird, ist noch nicht bekannt. Lassen Sie uns das klarstellen.

Was: Der EM/PM präsentiert dem Team die Roadmap und die bevorstehende Teamaufteilung. Die EM erwähnt, dass sie in den kommenden Einzelgesprächen nach den Vorlieben jedes Teammitglieds fragen und versuchen, so gut es geht, auf die bevorstehende Trennung einzugehen. Die EM stellt die Gruppierungen zusammen mit dem EM-Manager zusammen, um die Teambesetzung abzuschließen.

Was passiert, wenn sich jeder für Team A entscheidet? Hier werden die EM ihr Bestes geben, um sowohl die Bedürfnisse des Unternehmens als auch des Ingenieurs zu erfüllen und das Ergebnis transparent zu teilen.

Wer: Technischer Leiter

Leistung: Ein Dokument, das die Präferenzen jedes Teammitglieds in Bezug auf das Team, dem es beitreten möchte, mit Kriterien (Personalkompetenz, Ausrichtung der Roadmap usw.) zusammenfasst.

Hinweis: Die Verwendung eines solchen Dokuments ist ideal, aber manchmal funktioniert es möglicherweise nicht. Sorgen Sie so früh wie möglich für Transparenz, um Überraschungen zu vermeiden.

🤝 Anpfiff für Team 2

Ziel: Jetzt, wo wir das Warum, das Was und das Wer haben, bilden wir das neue Team.

Was: Die EM informiert die Leute darüber, in welchem Team sie sind und wann das neue Team beginnen wird. Die Leitung auf Pod-Ebene beginnt mit der Zusammenstellung der North Star- und Quartalsziele. Die EM organisiert ein Team-Kickoff-Meeting mit den neuen Teammitgliedern, bei dem die Gruppe das North Star-Quartalziel des Teams überprüft. Sie erstellen auch die Arbeitsvereinbarung und einen Teamnamen.

Name des Teams

Bei FloQast sind die meisten unserer Teamnamen Monde. (Lange Geschichte 😂) Der EM führt das Team durch eine Teamwerte- und Benennungsübung. Der Grund dafür ist, dass jedes Team Stärken hat, die es einzigartig machen, und die Werte werden zu einem gemeinsamen Verständnis.

Beispieldokument

Teamcharta

Eine Teamcharta ist das A und O für ein Team und dient auch als Gelegenheit, um zu unterscheiden, wie sich dieses Team von der Arbeit eines anderen Teams unterscheidet. Der Abschnitt Rollen und Verantwortlichkeiten stammt aus einem Buch von Lara Hogan, das viele unserer technischen Manager gelesen haben.

Beispieldokument

Vereinbarung zur Teamarbeit

Die neuen Teammitglieder erstellen dieses Dokument gemeinsam. Die Leute arbeiten auf unterschiedliche Weise miteinander — und wenn alle auf derselben Wellenlänge sind, wächst das Team schneller zusammen.

Beispieldokument

Der PM leitet in der Regel die Teamvision, und dann übernimmt der EM die Rollen und Verantwortlichkeiten sowie die Diskussion der Teamarbeitsvereinbarung.

Wer: PM/Technischer Leiter

Leistung:

• Team Confluence Page (mit all den oben genannten Informationen)
• Slack-Benutzergruppe mit neuem Teamnamen
• Jira Epic- und Sprint-Boards
• Jira-Automatisierung
• Änderungen der Schema-Inhaberschaft und Änderungen der Repo-Inhaberschaft, sofern dies für das neue Team gilt.
• Benachrichtige verschiedene Slack-Kanäle über ein neues Pod-Setup

🏃🏻 ‍ ♂️ Lieferung in Sprint 1

Ziel: Wir haben jetzt das Warum, das Was und das Wer — das Makroteam kann anfangen, zu zerbrechen und alle verbleibenden Arbeiten zu Ende zu bringen.

Was: Zu diesem Zeitpunkt arbeiten die Mitglieder von Team 1 und Team 2 im Sprint von Team 1 zusammen auf einer Discovery Card. Die gesamte Gruppe arbeitet an einem kommenden Epos für Team 2, um die gemeinsamen Datengrenzen und die Arbeit zu verstehen. Am Ende sind die Tickets für Team 2 bereit, das sie in ihrem ersten Sprint zur Produktion einsetzen können.

Wer: Technischer Leiter

Leistung: Neue Sprints mit den beiden neuen Teams werden gestartet, mit klaren Sprintzielen, und eine Zusammenfassung des neuen Teams wird in unserem wichtigsten technischen Slack-Kanal bekannt gegeben. Ein neues Team ist startklar!