Według Scrum Guide optymalna wielkość zespołu developerskiego to maksymalnie 10 osób. Tymczasem mój team przez 1,5 roku mocno się rozrósł i przekroczył 20 członków. Praca w tak dużej grupie przestała być efektywna – pojawił się więc pomysł, aby ją podzielić. Jak to jednak zrobić bez szkody dla zespołu i realizowanego projektu? Z pomocą przyszedł framework LeSS.
Nasz produkt
Zanim o zespole, parę słów o tworzonym przez nas produkcie. Jest nim nowy moduł platformy webowej wspierającej jedno z najpopularniejszych urządzeń kuchennych IoT. To złożone rozwiązanie, o wyrafinowanej mikroserwisowej architekturze, dość skomplikowanej logice biznesowej, obsługującej wiele urządzeń (Web, Mobile, IoT) i wykorzystującej inteligentne technologie Natural Language Processing.
Zespół przed podziałem
Rozpoczynając pracę nad bieżącym projektem nasz zespół liczył zaledwie kilka osób i był typowym zespołem scrumowym. Ze względu na wysoki priorytet tworzonego produktu i zwiększające się potrzeby, miesiąc po miesiącu nasza liczebność stopniowo rosła. Tuż przed podziałem skład zespołu kształtował się następująco:
Skład zespołu Scrum
Rola | Ilość | Uwagi |
Product Owner | 1 | Reprezentant klienta (nie stanowiący integralnej części zespołu) |
Solution Architect | 1 | Reprezentant klienta (nie stanowiący integralnej części zespołu) |
Scrum Master | 2 | Drugi Scrum Master został zaangażowany do pomocy organizacyjnej |
Business Analyst | 2 | Wspierający Product Ownera w zarządzaniu backlogiem, analizą i formułowaniem wymagań |
Web Developer | 9 | Skupiający w sobie kompetencje BackEnd, FrontEnd i DevOps (mimo specjalizacji, każdy developer posiada umiejętności w każdym z tych obszarów) |
Tester (QA) | 4 | Testy zarówno manualne (na różnych urządzeniach: IoT, Web, Mobile), jak i automatyczne |
Data Engineer / Scientist | 5 | Odpowiedzialni za rozwój modułu wykorzystującego technologię Natural Language Processing |
UX Designer | 2 | Projektanci odpowiedzialni za User Experience oraz interfejs naszych rozwiązań |
Łącznie | 26 |
Jak pracowaliśmy?
W naszej pracy opieraliśmy się na frameworku Scrum, możliwie wiernie stosując się do jego zaleceń (dot. m.in. wartości zespołu, ról projektowych, artefaktów czy procesów).
Prawie cały zespół developerski pracował w ramach tego samego kodu źródłowego, realizując wspólny zakres funkcjonalny.
Wyjątkiem była rosnąca grupa Data Science, zaangażowana w osobny, inteligentny moduł NLP (Natural Language Processing). Z czasem, z racji znacząco odrębnego zakresu względem reszty zespołu, ekipa ta stała się swego rodzaju „podzespołem”, z odrębnymi artefaktami Scrum oraz własnymi procesami.
Problemy w zbyt dużym zespole Scrum
Jak już wspomniałem, pracowaliśmy w ten sposób dość długo, zaczynając w stosunkowo nielicznej grupie. Z tego względu nie od razu dostrzegliśmy problemy, które narastały wraz ze wzrostem zespołu. Z czasem zaczęły nam jednak mocno doskwierać:
- nieefektywne spotkania projektowe, m.in.:
- za długie i powierzchowne (wyrecytowane od niechcenia) daily, nie wnoszące żadnej wartości dla zespołu,
- retrospektywa nie dająca wystarczającej przestrzeni do „wygadania się” wszystkim jej uczestnikom oraz niechęć zespołu do szczerych wypowiedzi spowodowana obecnością klienta (Product Owner oraz Solution Architect),
- refinement oraz planning zdominowany przez kilka aktywnych osób – nie zachęcający pozostałych do wzięcia udziału w dyskusji,
- zaburzona transparentność i skupienie – zbyt duża liczba developerów realizowała zbyt dużą liczbę zadań, nie skupiając się na tym, co najważniejsze (cel sprintu) i nie rozumiejąc priorytetów zespołu,
- kłopoty komunikacyjne pomiędzy zespołem podstawowym, a grupą Data Science (brak konkretnych zasad współpracy),
- bardzo utrudniony pomiar prędkości zespołu (większy zespół = więcej pracy w toku, więcej nieukończonych zadań w sprincie, więcej absencji itd.),
- zespoły w zespole – wokół (zbyt wielu, niepisanych) liderów utworzyły się rywalizujące ze sobą grupy interesu (np. zainteresowane realizacją zupełnie innych zadań, pomysłów, reprezentujące odmienne podejście do danych zagadnień technologicznych).
Podział zespołu
Pomysł podzielenia zespołu pojawił się 2-3 miesiące wcześniej, jednak ze względu na napięty harmonogram projektu nie mógł zostać zrealizowany. Brakowało również jasnej wizji tego, w jaki sposób wprowadzić go w życie.
Wydawało się, że naturalnym rozwiązaniem będzie podział zespołu bazowego na minimum dwa (grupa Data Science funkcjonowała już bowiem jako odrębny byt) – wraz z podziałem zakresu projektu, w taki sposób, aby oba zespoły pracowały niezależnie, nie wchodząc sobie w drogę.
Backlog projektu okazał się jednak zbyt jednolity aby go podzielić. Obdarowanie jednego zespołu funkcjonalnością A, a drugiego funkcjonalnością B mogłoby również prowadzić do niezadowolenia (indywidualne preferencje, „u sąsiada trawa zawsze bardziej zielona” itd.). Nowy system pracy obwarowany był również szeregiem wymagań zewnętrznych.
Wymagania wobec podziału
- Zespół niezależnie od wewnętrznej struktury (podziału) miał funkcjonować jako jednolita grupa dla świata zewnętrznego. Przykładowo: interesariusze i inne zespoły nie powinny zastanawiać się do którego zespołu przypisać np. zgłoszenie serwisowe. Z ich punktu widzenia wszyscy mieliśmy istnieć pod wspólnym szyldem.
- Zmiany w strukturze zespołu nie powinny być rewolucją – warunkiem dla ich wprowadzenia było to, aby nie wpłynęły negatywnie na produktywność zespołu (również w krótkim terminie) – z uwagi na zbliżający się release naszego produktu.
- Nasz klient zażyczył sobie, aby ówcześni Product Owner oraz Solution Architect dalej pełnili te role – dla wszystkich nowych zespołów. Wygenerowało to dwa kolejne wymagania:
- nowy układ musiał być lekki, jeśli chodzi o liczbę spotkań (jeden PO oraz Architekt nie byliby w stanie uczestniczyć w standardowej pracy scrumowej kilku zespołów jednocześnie,
- rola Product Ownera oraz Solution Architekta powinny zostać dostosowane, tak aby – również merytorycznie – mogli udźwignąć ciężar równoległej pracy z wieloma zespołami.
Powyższe wymagania mocno ograniczyły dostępne możliwości podziału zespołu. Rozwiązania postanowiłem szukać wśród najpopularniejszych sposobów pracy w Scrumie przez więcej niż jeden zespół. Okazał się nim LeSS, czyli Large-Scale Scrum.
Czym jest LeSS?
LeSS (Large-Scale Scrum) to Scrum powiększonej skali – gdzie wiele zespołów wspólnie pracuje nad rozwojem jednego produktu. Jest frameworkiem wykorzystującym zasady, założenia, cele oraz elementy Scruma w dużym środowisku.
Large-Scale Scrum występuje w dwóch wariantach:
- LeSS – dla 2-8 zespołów (jest więc właściwym wyborem dla nas),
- LeSS Huge – dla więcej niż 8 zespołów (teoretycznie jest więc rozwiązaniem, w ramach którego tysiące ludzi pracują nad jednym produktem!)
Scrum dużej skali nie jest specjalnym frameworkiem, który stosuje Scrum tylko na poziomie pojedynczego zespołu. Prawdziwy Scrum dużej skali to po prostu wyskalowany Scrum.
less.works
Wdrożenie LeSS
1. Trzy (niemal) równorzędne zespoły
Implementację LeSS rozpocząłem od podjęcia decyzji dot. liczby przyszłych zespołów. Lektura dobrych praktyk LeSS odwlokła mnie od pomysłu podzielenia mojej grupy według realizowanej funkcjonalności produktu. W efekcie powstały trzy (niemal) równorzędne zespoły Scrum:
- Zespół I – odpowiedzialny za rozwój podstawowej warstwy funkcjonalnej systemu,
- Zespół II – zespół bliźniaczy, o identycznej odpowiedzialności względem pierwszego,
- Zespół III – zespół Data Science, zajmujący się modułem NLP systemu.
2. ustalenie składów zespołów
Ustalając składy zespołów brałem pod uwagę m.in.:
- kompetencje pracowników (umiejętności, wiedzę domenową, pełnioną do tej pory rolę, staż pracy, staż w projekcie, ew. zdolności przywódcze),
- relacje między pracownikami,
- charaktery pracowników,
- znane mi długofalowe plany rozwoju pracowników,
- indywidualne opinie i oczekiwania pracowników (zdobyte nieco później, bo w punkcie 4.).
3. Zaprojektowanie Procesu
Zasady i elementy procesu LeSS bardzo dobrze opisano w jego dokumentacji – nie będę więc silił się na przepisywanie czegoś, co już istnieje w internecie. Przedstawię natomiast wersję wdrożoną przez nas – na potrzeby naszych trzech zespołów.
Element procesu | Cel | PO Architekt | Zespół I Zespół II | Zespół Data Science |
Global Sprint Planning (LeSS: Sprint Planning 1) | Ustalenie i zrozumienie celów i priorytetów na najbliższy sprint. Podzielenie pracy pomiędzy zespołami. | TAK | TAK | TAK (reprezentanci) |
Individual Sprint Planning (LeSS: Sprint Planning 2) | Wewnątrzzespołowe ustalenie priorytetów i strategii osiągnięcia wyznaczonych celów. | Opcjonalnie | Gdy potrzebny | TAK |
Individual Daily (LeSS: Daily) | Zapewnienie bieżącej komunikacji i transparentności w pojedynczym zespole + usunięcie ewentualnych przeszkód | Opcjonalnie | TAK | TAK |
Global Backlog Refinement (LeSS: Overall Product Backlog Refinement) | Zrozumienie, dopracowanie oraz oszacowanie elementów Product Backlogu (przynajmniej na wysokim poziomie). | TAK | TAK | TAK (reprezentanci) |
Individual Backlog Refinement (LeSS: Single Team Product Backlog Refinement) | Dopracowanie elementów Product Backlogu i szczegółowe nakreślenie strategii ich implementacji (jeśli konieczne). | Opcjonalnie | Gdy potrzebny | TAK |
Common Sprint Review (LeSS: Sprint Review) | Przedstawienie rezultatów pracy zespołu wszystkim jego członkom oraz interesariuszom. | TAK | TAK | TAK |
Individual Retrospective (LeSS: Retrospective) | Inspekcja i adaptacja na poziomie pojedynczego zespołu. | NIE | TAK | TAK |
Global Retrospective (LeSS: Overall Retrospective) | Inspekcja i adaptacja na poziomie wszystkich zespołów. | TAK | TAK (reprezentanci) | TAK (reprezentanci) |
Ustaliliśmy, że z racji tożsamych kompetencji, wspólnych celów oraz zakresu, Sprint Planning 1 (Global) oraz Overall Product Backlog Refinement (Global) będą przeznaczone dla pełnych zespołów I i II. Z ich punktu widzenia spotkania te niewiele się zmieniły: podczas planningu decydujemy nie tylko o tym, które User Stories realizować w rozpoczynającym się sprincie, ale również który z zespołów będzie zajmował się poszczególnymi zagadnieniami (uzupełniamy dwa Sprint Backlogi, obierając indywidualne cele sprintów dla obu zespołów).
W spotkaniach tych biorą również udział reprezentanci zespołu Data Science – aby mieć świadomość obranych celów, przyjętych priorytetów oraz szczegółów implementacyjnych. Własną cześć projektowego zakresu grupa ta omawia i planuje jednak samodzielnie w ramach Sprint Planning 2 (Individual) oraz Single Team Product Backlog Refinement (Individual) – a więc także bez większych zmian. Dla zespołów I i II również je zaplanowaliśmy, odbywają się jednak wyłącznie w razie potrzeby.
Nieco więcej zmian przyniosły Dailies oraz Retrospectives – odbywające się w 100% w zespołowym (czyli zdecydowanie mniej licznym) gronie. Zupełną nowością jest natomiast Overall Retrospective (Global), czyli retrospektywa z udziałem reprezentantów wszystkich zespołów, Product Ownera oraz Architekta.
Poza wymienionymi stałymi elementami sprintu, w codziennej pracy wykorzystujemy też inne narzędzia proponowane przez LeSS, jak np. Multi-Team Product Backlog Refinement. Nie używamy jednak tej nazwy – w naszym rozumieniu są to raczej spotkania „na żądanie”, w adekwatnym do tematu gronie, mające na celu wypracowanie rozwiązania dla danego zagadnienia, szczegółów implementacyjnych itp. Porozumienie techniczne osiągamy ponadto stosując międzyzespołowe code review: kod danego rozwiązania musi przejść nie tylko weryfikację własnego zespołu, ale również min. jednego developera z innego teamu).
Każda iteracja kończy się wspólnym Sprint Review – które nie uległo zmianie. Reprezentanci wszystkich zespołów prezentują w nim dokonania całej grupy – zarówno sobie nawzajem, najważniejszym interesariuszom, jak i wszystkim zainteresowanym.
4. Indywidualne rozmowy z zespołem i interesariuszami
Po stworzeniu projektu wdrożenia LeSS w naszym zespole, przyszedł czas na indywidualne rozmowy z jego członkami oraz interesariuszami (Product Owner, Architekt oraz kilku innych przedstawicieli klienta). Zależało mi aby przed oficjalnym przedstawieniem koncepcji osoby te miały okazję wypowiedzieć się na jej temat, wyjaśnić wątpliwości, być może coś zasugerować. Znacznie obniżyło to ryzyko negatywnej reakcji / bojkotu pomysłu, a zarazem niepowodzenia wdrożenia, już na etapie prezentacji. Pozwoliło również dopracować niektóre elementy.
5. Prezentacja nowego sposobu Pracy
Mimo że prezentacja koncepcji nie była już de facto potrzebna (każdy poznał założenia podczas wcześniejszych indywiduanych sesji), wspólne spotkanie pozwoliło nam upewnić się, że proponowane zmiany płyną z potrzeby całej grupy i są przez nią akceptowane – nie są natomiast wymysłem jedynie Project Managera.
Podczas spotkania wyjaśniliśmy sobie resztę wątpliwości, omówiliśmy pomysły i ustaliliśmy następne kroki wdrożenia LeSS – albowiem tak: zgodziliśmy się, że jest to właściwy kierunek.
6. Ustalenie terminu startu
W zasadzie jedynym otwartym tematem pozostał więc termin wprowadzenia zmian. W naszej grupie dominowały dwie opinie:
- „podzielmy zespół jak najszybciej – już, zaraz” – gdyż praca w ówczesny sposób bardzo mocno doskwierała wielu pracownikom (uważali, że odwlekanie zmian tylko potęguje problemy),
- „nie eksperymentujmy, podzielmy zespół po wydaniu produktu” (czyli za ok. 2-3 miesiące) – mówili ci, którzy obawiali się, że wdrożenie LeSS w krytycznym momencie projektu (na krótko przed releasem) zahamuje prace i zrodzi nowe problemy.
Decyzję o terminie wprowadzenia zmian podjęliśmy demokratycznie – przeprowadzając ankietę wśród wszystkich członków zespołu. Zdecydowana większość opowiedziała się za najszybszą możliwą opcją: początkiem kolejnego sprintu. Mimo zaledwie kilku dni na przygotowania, uruchomienie nowych procesów przebiegło bez większych problemów i zakończyło się sukcesem.
Ocena: LeSS pół roku później
W nowym systemie pracujemy już niemal pół roku. Myślę więc, że mogę pokusić się o krótkie podsumowanie zmian wynikających z podziału zespołu i wdrożeniu LeSS. Garść rezultatów i przemyśleń:
Sukcesy
- Co zaskakujące, wzrosła łączna produktywność grupy. W pierwszych kilku sprintach po podziale zespołu suma velocity nie uległa zmianie. Jednak w kolejnych iteracjach każdy z zespołów zaczął przyspieszać i spalać coraz więcej Story Points. W chwili obecnej łączne velocity zespołów jest około 30% wyższe niż przed zmianami.
- Bardzo poprawiła się jakość spotkań projektowych, zwłaszcza Daily oraz Retrospektywy. W mniejszym, bardziej homogenicznym gronie oraz bez udziału klienta, zespoły prowadzą je znacznie efektywniej. Jest miejsce na humor, solidną wymianę informacji (daily), a także szczerość i kreatywność w rozwiązywaniu problemów (retrospektywa).
- W mniejszych zespołach praca przebiega transparentnie. Łatwiej skupić się na celach sprintu i obserwować postęp prac. Natomiast osobom, które nie grzeszą produktywnością – trudniej „ukryć się” przed wzrokiem wymagających kolegów z zespołu (pozytywny wpływ na poczucie indywidualnej odpowiedzialności). Gdy jeden z zespołów permanentnie nie realizował swojego celu sprintu, bardzo łatwo i szybko znaleźliśmy i wyeliminowaliśmy przyczynę.
- Udało nam się uniknąć wzrostu liczby spotkań projektowych. Z punktu widzenia regularnego członka zespołu ich ilość i charakter nie zmieniły się. Początkowo ekipa Data Science narzekała na konieczność uczestnictwa (reprezentanci) w Global Product Backlog Refinementach (gdzie zakres zwykle nie jest bezpośrednio związany z ich własnym modułem), jednak z czasem wypracowaliśmy dobre rozwiązanie. Obecnie ich obecność na wspólnych spotkaniach jest uzależniona od publikowanej wcześniej agendy.
Wyzwania
- Odseparowani od siebie liderzy formujący teraz dwa-trzy odrębne zespoły zaczęli ze sobą rywalizować. Podczas wspólnych spotkań daje się niekiedy wyczuć napięcie, chęć przeforsowania własnej wizji rozwiązania, pojawiają się również drobne złośliwości. Myślę, że do pewnego stopnia zdrowa rywalizacja może być motorem napędowym dla całej grupy, jednak zdecydowanie ciężko jest utrzymać ją w rozsądnych ryzach.
- Problemem ściśle związanym z powyższym jest ponadto niewystarczająca komunikacja pomiędzy zespołami podczas bieżącej pracy. Okazuje się, że wspólne refinementy, spotkania tematyczne „na żądanie” oraz cross-zespołowe code review nie zawsze gwarantują pełną zgodność w podejściu do tych samych zagadnień.
Mimo kilku problemów, ja sam jestem bardzo zadowolony z obecnego kształtu i współpracy zespołów. Według mnie rozwiązania zaproponowane przez LeSS w praktyce sprawdziły się świetnie. Potwierdza to również sam zespół pozytywnie oceniając wprowadzone zmiany (zweryfikowane ankietą) oraz utrzymując swój poziom satysfakcji (element naszej retrospektywy) na bardzo wysokim poziomie.
Spodziewam się, że możesz mieć sporo pytań, uwag bądź przemyśleń związanych z zastosowaniem LeSS w naszym projekcie. Proszę, opisz je wszystkie w komentarzu poniżej.
1 thought on “Case Study: jak podzielić (za duży) zespół Scrum metodą LeSS?”