- PagerDuty /
- Der Blog /
- Best Practices und Einblicke /
- Lektionen zum Aufbau gut aufgestellter Scrum- und Kanban-Teams
Der Blog
Lektionen zum Aufbau gut aufgestellter Scrum- und Kanban-Teams
In den Anfangstagen von Amazon stellte Jeff Bezos eine Regel auf: Teams sollten nicht größer sein als zwei Pizzas, egal wie groß ein Unternehmen wird. Diese Regel für kleine Teams bedeutete, dass die einzelnen Mitarbeiter weniger Zeit damit verbrachten, sich gegenseitig Statusaktualisierungen zu übermitteln, und mehr Zeit damit, tatsächlich Dinge zu erledigen. Außerdem hatten die Teammitglieder mehr Zeit, sich auf kontinuierliche Verbesserungen zu konzentrieren.
PagerDuty hat, wie Amazon, eine ausgeprägte Kultur der kontinuierlichen Verbesserung. Wir haben viel über den Aufbau gut aufgestellter Teams experimentiert und gelernt. In diesem Blogbeitrag verrate ich Ihnen unser Rezept für die Zusammenstellung eines erfolgreichen Teams, damit auch Sie von diesen Erkenntnissen profitieren können.
Was wir gemacht haben: Ein Experiment mit der Teamgröße > 2 Pizzas reichen aus
Wir begannen mit zwei Scrum-Teams, jedes mit seinen eigenen Team-Chartas und Roadmaps. Wir hatten gerade ein Umfrage zum Team-Gesundheitscheck für beide Teams. Eines der Teams war ziemlich zufrieden und optimistisch, was die Richtung und das Erreichen der Ziele anging. Das andere Team war unzufrieden und pessimistisch hinsichtlich seines Fahrplans und hatte Probleme, seine Sprint-Verpflichtungen (Arbeitsverpflichtungen innerhalb eines Zeitrahmens von 2-4 Wochen) einzuhalten.
Aufgrund von Ressourcenproblemen und Moralproblemen im Team wurde die Entscheidung getroffen, die beiden Teams zusammenzulegen. Am Ende hatten wir ein riesiges Kanban-Team, dessen Aufgabe darin bestand, Funktionen für unsere größten Kunden zu entwickeln und gleichzeitig unsere monolithische Architektur zu modernisieren.
(Sie fragen sich vielleicht, warum das Team sich dafür entschieden hat Kanban versus Scrum ? Der Gedanke war, dass Scrum für ein übergroßes Team zu viel Aufwand bedeuten würde. Können Sie sich vorstellen, Sprint Planning für ein 14-köpfiges Team durchzuführen?)
Was ist passiert
An diesem Punkt sind Sie vielleicht skeptisch, ob dieses Team auf Erfolg eingestellt war oder nicht. Und nachdem Sie bis hierhin gelesen haben, sollten Sie es auch sein. Hier ist die Kurzfassung dessen, was passiert ist:
Dem übergroßen Team wurde eine übergroße Arbeitsbelastung zugewiesen.
Ergebnis : Mangelnde Konzentration, 5–6 Arbeitsabläufe für das Team zu einem bestimmten Zeitpunkt.
Zwei Team-Roadmaps wurden zusammengequetscht, parallele Arbeitsabläufe wurden als gleich hohe Priorität für das Team erachtet.
Ergebnis : Herausforderungen bei agilen Prognosen und Planungen.
Aufgrund der Teamgröße und -dynamik kam es bei der Prozessverbesserung im Team zu Pattsituationen.
Ergebnis : Begrenzte Prozessverbesserung für das Team aufgrund fehlenden Konsenses.
Was wir gelernt haben
Die wichtigste Lektion, die wir aus diesem Experiment gelernt haben, war, dass Die Teamgröße ist wirklich wichtig . Die Zwei-Pizza-Regel von Jeff Bezos wird durch die Organisationsforschung gestützt. Der Organisationspsychologe J. Richard Hackman weist darauf hin Das, Wenn ein Team wächst, wird die Kommunikation aufgrund der Anzahl der Verbindungen zwischen den Personen zunehmend schwieriger. Wenn Sie ein Standardteam mit zwei Pizzas nehmen, also beispielsweise 6 Personen, sind das 15 Pizzabälle für jeden. Verdoppeln Sie diese Zahl für ein Team von 12 Personen, und es sind 66 Pizzabälle.
Die Kommunikationsschwierigkeiten eines 14-köpfigen Teams zeigten sich am deutlichsten bei Teambesprechungen. Es war schwierig, die Besprechungen effektiv zu gestalten, und wir alle mussten lernen, besser zuzuhören. Es wurde auch schwieriger, einen Konsens zu erzielen, und es kam häufiger zu Pattsituationen im Team bei Ideen zur Prozessverbesserung.
Der Ringelmann-Effekt war auch für unser übergroßes Team im Spiel. Das ist die Tendenz einzelner Gruppenmitglieder, mit zunehmender Gruppengröße immer weniger produktiv zu werden. Dieser Effekt wurde sogar bei körperlichen Aktivitäten wie Tauziehen dokumentiert.
Und schließlich erfuhren wir, dass Die Begrenzung der Work-in-Progress-Arbeit (WIP), ein Kernprinzip von Kanban, gilt für Teams jeder Größe . Ein Team, das an 5–6 Projekten parallel arbeitet, hat keine Erfolgsaussichten und läuft eher Gefahr, Prognosen zu verfehlen und den Fokus zu verlieren.
Was wir jetzt tun
Heute werden die Delivery Teams bei PagerDuty so zusammengestellt, dass ihre Effektivität optimiert wird. Gut zusammengestellte Teams können die wichtigsten Initiativen schnell umsetzen und eine konsistente Produktlieferung gewährleisten.
Bevor wir ein neues Lieferteam bilden, stellen wir sicher, dass alle der folgenden Kästchen angekreuzt sind:
[ ] Klare Spezifikation der Teameigentümerschaft: Das Team verfügt über eine Satzung, in der seine Aufgaben und sein Eigentum aufgeführt sind. Zudem gibt es keine Eigentumsüberschneidungen mit anderen Teams.
[ ] Definierte Kunden: Das Team weiß, für wen es baut. Ein Team kann mehrere Kunden haben.
[ ] Besitzen Sie ihre Roadmap: Das Team kann Kundenanfragen entgegennehmen, diese priorisieren und eine Vorhersage abgeben, wann diese Anfragen erfüllt werden können.
[ ] Selbständig: Das Team hat nur minimale externe Abhängigkeiten, sodass es sich konzentrieren und seine Aufgaben erledigen kann.
[ ] Führung vor Ort: Das Team verfügt über einen Produktinhaber (der die Stimme des Kunden vertritt), eine technische Leitung (um eine gute Architektur sicherzustellen) und eine Managementleitung (um dafür zu sorgen, dass das Team auf die Geschäftsziele ausgerichtet bleibt und die Teammitglieder produktiv und engagiert bleiben).
[ ] Passende Größe: Die Größe der Teams richtet sich nach den Richtlinien des Offizieller Scrum Guide : Drei bis neun Teammitglieder. Weniger als drei Teammitglieder verringern die Interaktion und führen zu geringeren Produktivitätsgewinnen, während mehr als neun Teammitglieder zu viel Koordination erfordern.
Teilen Sie Ihre Erkenntnisse
Haben Sie ähnliche Erfahrungen gemacht, während Sie daran gearbeitet haben, gut geformte Lieferteams aufzubauen? Was sind Ihre Best Practices für den Teamaufbau? Wir würden uns freuen, von Ihnen zu hören in PagerDuty Community.