Wie man ein Scrum-Team aufteilt: Neue Teams bei FQ erstellen
Letztes Jahr hat Christopher Ngo einen Beitrag über die Aufteilung eines Scrum-Teams aus der Perspektive eines Ingenieurs veröffentlicht. Dieser Beitrag ist ein schrittweiser interner Prozess, den wir in der Regel für die Aufteilung von Scrum-Teams mit den Zielen Stabilität, Entkopplung und frühzeitiger Erfolg verwenden und wiederholen. Wie bei den meisten Dokumentationen gilt auch hier - je nach Team und Unternehmen kann es zu Anpassungen kommen.
Das Problem
In der Regel trennen wir bei FloQast R&D neue Scrum-Teams von bestehenden Teams, wenn:
- Der Rückstand des derzeitigen Teams beträgt etwa ein Jahr oder mehr.
- Wir wollen diese rückständigen Punkte lieber früher als später abarbeiten
Der Wechsel von Teams kann für die Teammitglieder eine erschütternde Erfahrung sein, daher überlegen wir uns den Wechsel sorgfältig. Wenn dies schlecht gemacht wird, kann es zu Instabilität im Team, eng gekoppelten Codebases und einer langen Sturmperiode führen, ohne dass wir unseren Kunden etwas liefern können.
Annahmen
- Bei FloQast haben die meisten unserer technischen Scrum-Teams 2-4 Full-Stack-Software-Ingenieure und einen Qualitätsingenieur pro Team, und ihre Arbeit ist ebenfalls Full-Stack. Es gibt ein paar Scrum-Teams, die hauptsächlich Backend oder Frontend arbeiten.
- Neben dem Personalmanagement und der technischen Anleitung fungieren unsere Engineering Manager auch als Agile/Scrum-Leader
- 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, das eine einzigartige Kundenmöglichkeit validiert. Für diese Teams können Sie die ersten zwei oder drei Schritte auslassen.
(So) machen wir es 🎵
Schritte
- Finden Sie die Datengrenzen
- Einen Fahrplan festlegen
- Selbstorganisierende Teams
- Anstoß der Mannschaft
- Lieferung in Sprint 1
👩🏽💻 Daten-Grenzen
Ziel: Die Schaffung eines fokussierten Bereichs für ein Team läuft darauf hinaus, die Grenzen zu finden, die unseren aktuellen und zukünftigen Kundenbedürfnissen entsprechen.
Was: Schauen Sie sich die Epics für das Team an und finden Sie Grenzen, welche zukünftige Roadmap zu Team 1 und welche zu Team 2 gehört, basierend auf den Daten, Codebases, Features und Epics.
Wer: Führungskräfte auf Pod-Ebene (Produktmanager, technischer Leiter, ggf. technischer Leiter)
Ergebnis: Klares Verständnis der Daten- und Produktbereiche, für die ein neues Team zuständig sein wird, sowie aller gemeinsamen Grenzen mit anderen Teams.
🛣️ Definieren Sie einen Fahrplan
Ziel: Durch das Verständnis der Produkt- und Datengrenzen kann die Pod-Leitung die hochrangigen Initiativen prüfen, an denen das Team in den nächsten sechs Monaten oder länger arbeiten wird.
Was: Stellen Sie auf der Grundlage der Domänenübung eine Roadmap von 4-6+ Monaten für jedes Team sicher. Eine nachhaltige Roadmap verringert die Instabilität/den Stress eines ungesunden Team-Backlogs. Wenn es keine ausreichend lange Roadmap gibt, ist dies eine Gelegenheit zu überlegen, ob wir überhaupt ein neues Team bilden müssen oder ob wir stattdessen bestimmte Initiativen in Team 1 anders priorisieren sollten. Sobald die Epics aufgeteilt sind, sollten Sie einen Blick auf die Roadmaps werfen. Ist ein Team stark und das andere leicht gewichtet? Gibt es Bereiche, in denen die Teams in denselben Codebases arbeiten werden? Wie könnten wir das reduzieren? Sieht jedes Team in seinem Bereich generell nach Full-Stack aus? Wenn nicht, hat das Auswirkungen auf die Einstellung/Rekrutierung von Mitarbeitern für das Team?
Wer: Führungskräfte auf Pod-Ebene (Produktmanager, technischer Leiter)
Ergebnis: Hochrangige Epen für zwei Teams
🧠 Selbstorganisierende Teams
Ziel: Die Bereiche und der Fahrplan werden immer deutlicher, aber wer zum Team gehören wird, ist noch unklar. Das wollen wir klären.
Was: Der EM/PM stellt dem Team den Fahrplan und die bevorstehende Teamaufteilung vor. Der EM erwähnt, dass er bei den anstehenden 1:1-Gesprächen nach den Präferenzen der einzelnen Teammitglieder fragt und versucht, diese so gut wie möglich zu berücksichtigen. Der EM stellt die Gruppierungen mit dem Manager des EM zusammen, um die Teambesetzung abzuschließen.
Was passiert, wenn sich alle für Team A entscheiden? In diesem Fall wird die EM ihr Bestes tun, um sowohl die Bedürfnisse der Organisation als auch die der Ingenieure zu erfüllen und das Ergebnis transparent zu machen.
Wer: Technischer Leiter
Ergebnis: Ein Dokument, in dem die Präferenzen der einzelnen Teammitglieder für die Teilnahme an einem Team mit den entsprechenden Kriterien (personelle Fähigkeiten, Ausrichtung auf den Fahrplan usw.) festgehalten werden.
Hinweis: Die Verwendung eines solchen Dokuments ist ideal, kann aber manchmal auch nicht funktionieren. Setzen Sie so früh wie möglich auf Transparenz, um Überraschungen zu vermeiden.
🤝 Team 2 Anpfiff
Ziel: Jetzt, da wir das Warum, das Was und das Wer kennen, bilden wir das neue Team.
Was: Die EM teilt den Leuten mit, welchem Team sie angehören und wann das neue Team beginnen wird. Die Leitung der Pod-Ebene beginnt mit der Zusammenstellung der Nordstern- und Quartalsziele. Der EM beruft eine Team-Kickoff-Sitzung mit den neuen Teammitgliedern ein, bei der die Gruppe das vierteljährliche Nordstern-Ziel des Teams bespricht. Außerdem werden die Arbeitsvereinbarung und ein Teamname festgelegt.
Name der Mannschaft
Bei FloQast sind die meisten unserer Teamnamen Monde. (Lange Geschichte 😂) Die EM führt das Team durch eine Übung zu Teamwerten und Namensgebung. Der Grund dafür ist, dass jedes Team Stärken hat, die es einzigartig machen, und dass die Werte zu einem gemeinsamen Verständnis werden.
Team-Charta
Eine Teamcharta ist der Nordstern für ein Team, und sie bietet auch die Möglichkeit, die Arbeit dieses Teams von der eines anderen Teams zu unterscheiden. Der Abschnitt über Rollen und Verantwortlichkeiten stammt aus einem Buch von Lara Hogan, das viele unserer Engineering Manager lesen.
Teamarbeitsvereinbarung
Die neuen Teammitglieder erstellen dieses Dokument gemeinsam. Menschen arbeiten auf unterschiedliche Weise miteinander - und wenn alle auf derselben Seite stehen, kann das Team schneller zusammenwachsen.
Der PM leitet in der Regel die Team-Vision, und dann übernimmt der EM die Diskussion über die Rollen und Verantwortlichkeiten und die Teamarbeitsvereinbarung.
Wer: PM/Engineering Manager
Ausgabe:
- Team Confluence Seite (mit allen oben genannten Informationen)
- Slack-Benutzergruppe mit neuem Teamnamen
- Jira epic und Sprint Boards
- Jira-Automatisierung
- Änderungen der Schema- und Repo-Eigentümerschaft, die für das neue Team gelten.
- Benachrichtigung verschiedener Slack-Kanäle für neue Pod-Setups
🏃🏻♂️ Lieferung in Sprint 1
Ziel: Wir haben jetzt das Warum, das Was und das Wer - das Makroteam kann mit der Zersplitterung beginnen und die verbleibende Arbeit abschließen.
Was: Zu diesem Zeitpunkt arbeiten die Mitglieder von Team 1 und Team 2 im Sprint von Team 1 gemeinsam an einer Discovery Card. Die gesamte Gruppe arbeitet ein bevorstehendes Epos für Team 2 durch, um die gemeinsamen Datengrenzen und Arbeiten zu verstehen. Am Ende dieses Prozesses sind die Tickets für Team 2 bereit, um sie in ihrem ersten Sprint in die Produktion zu überführen.
Wer: Technischer Leiter
Ergebnis: Neue Sprints mit den beiden neuen Teams werden gestartet, mit klaren Sprint-Zielen, und eine Zusammenfassung des neuen Teams wird in unserem Haupt-Engineering-Slack-Kanal angekündigt. Ein neues Team ist einsatzbereit!
Vinoj Zacharia
Vinoj Zacharia ist ein Entwickler, der sich in eine technische Führungspersönlichkeit verwandelt hat, die mit Einfühlungsvermögen datengesteuerte, befähigte und kollaborative Teams von Grund auf aufbaut. Er ist Director of Engineering bei FloQast.
Zurück zu Blog