Gdy dołączyłem do zespołu półtora roku temu jedną z
pierwszych rzeczy, która zwróciła moją uwagę, były Daily Scrum’y. Wszystkie
osoby uczestniczące w projekcie (a było ich 17) ustawiały się w kółku, które z powodu wielkości
zespołu, zajmowało cały pokój. Następnie każdy recytował odpowiedzi na trzy
pytania: „Co robił wczoraj ?” , „Co będzie robił dzisiaj” i „Czy ma problemy?”.
A te odpowiedzi wyglądały mniej więcej tak: „Wczoraj pracowałem na ticketem
XYZ, dzisiaj nadal będę pracował nad ticketem XYZ, problemów nie mam”. Gdy
pojawił się problem cały zespół nad nim dyskutował. Po kilku takich spotkaniach
uświadomiłem sobie że:
- Daily SCRUM’y strasznie się przedłużają. Zajmowały często ponad 30 minut
- Po zakończeniu spotkania tak naprawdę nie mam pojęcia co się dzieje w Sprincie
- Członkowie zespołu byli zmęczeni i znudzeni („no nieeee… znowu Standup. Muszę na niego iść ?”)
- Poszczególni developerzy koncentrowali się na wąskich obszarach (swoich ticketach)
Aby potwierdzić moje obserwacje na końcu Daily SCRUM’a
zacząłem zadawać niezręczne pytania typu: „Jasiu co dzisiaj będzie robił
Krzysiu ?”, „Małgosiu jak idzie Jasiowi ?”, „Ludziska czy dowieziemy cały
commitment ?”. Większość odpowiedzi potwierdzały moje przypuszczenia… coś było
nie tak.
Zacząłem
kombinować jak można byłoby zwiększyć efektywność Daily SCRUM’ów, lecz za chiny
ludowe nie mogłem wymyślić jak tego dokonać przy tak dużej ilości osób w
zespole. I nagle uświadomiłem sobie, że kluczowym elementem jest właśnie ta
„duża ilość osób”. Rzecz wydawałoby się oczywista, lecz jak to często bywa,
ciężka do zauważenia wśród nawarstwienia innych problemów. Zacząłem więc
zastanawiać się nad podziałem zespołu. Pojawiły się dwa problemy. Pierwszym z
nich było wymyślenie jak to zrobić. Najpopularniejszą techniką jest oczywiście
„Scrum of Scrums”. Słyszałem jednak wiele negatywnych opinii na jej temat i nie
byłem przekonany, czy sprawdzi się w naszym przypadku. Drugim problemem był
strach. Zespół współpracował z sobą przez długi czas i był ze sobą zżyty. Nie
pomagała też spora liczba publikacji które przeczytałem i opisywały zjawiska
typu „synergia zespołu” i „team glue”. Właśnie
wtedy w moje ręce wpadła książka Craiga Larmana „Scaling Lean & Agile Development: Thinking and Organizational Tools
for Large-Scale Scrum”. Opisywał on w
niej ciekawe podejście do tego problem, które prezentuje obrazek poniżej.
Na retrospekcji przedyskutowałem problem z zespołem i razem ustaliliśmy
nasz wariant implementacji tego modelu. Wygląda on następująco:
- Mamy jednego Product Ownera i jeden Product Backlog. Sprint Planning I przeprowadzamy razem jako jeden zespół
- Po Sprint Planningu I dzielimy się na 2-3 zespoły. Dostosowujemy wielość i skład zespołów do User Stories, które potencjalnie chcemy zrobić w tym sprincie (te informacje mamy z SP I)
- Rozdzielamy User Stories na zespoły
- Każdy zespół przeprowadza swój własny Sprint Planning II i posiada swój własny Sprint Backlog
- Jest jeden Scrum Master dla wszystkich zespołów
- Każdy zespół ma swoje własne Daily Scrumy. Członkowie innych zespołów mogą „wpaść z wizytą” na Dialy Scrumy innych zespołów (jako kurczaki)
- Demo i Retrospekcje przeprowadzamy wspólnie
- Przy groomingu dzielimy się na zespoły, lecz nie muszą to być te same zespoły które realizują aktualny Sprint
- Wprowadzamy rolę Feature Owner’a (FO). Jest to stricte techniczna rola odpowiednik technical team leadera ograniczona do jednego obszaru systemu.
Jak widać nie wykorzystaliśmy bezpośrednio modelu
przedstawionego przez Larmana, lecz wprowadziliśmy
nasze własne zmiany, aby
lepiej dostosować go do naszych realiów. Najważniejsze z nich to:
- Zostawiliśmy tylko jednego Scrum Mastera, aby zwiększyć efektywność prac. Łączenie roli SM z rolą Developera w naszym przypadku to kiepski pomysł, ponieważ kontakty z zespołem biznesowym miały tendencję do zabierania 100% czasu osoby zaangażowanej. SM zaczął stanowić filtr pozwalający zespołowi wykonywać swoją pracę bez ciągłych „przeszkadzajek” ze strony zespołu biznesowego.
- Dynamicznie zespoły zmieniające się co sprint pozwoliły nam zachować integralność zespołu (prędzej czy później każdy będzie pracował z każdym) oraz lepiej dostosować się do planów Product Ownera przedstawionych na Sprint Planningu I
Oczywiście nie ma róży bez kolców. Przy podziale na zespoły
narzuciłem pewne ograniczenia:
- Zespół musi liczyć minimum 3 osoby
- Zespół musi siedzieć razem w jednym pokoju (nasz projekt ma do dyspozycji dwa pokoje)
Kontrowersje budził szczególnie ten drugi punkt. Na początku
trudno było „odkleić” niektóre osoby od miejsc na których siedziały przez
ostatni rok. Nie pomagały również
procedury firmowe, które wymagały formalnego przekazywania kluczy do pokoi z
podpisaniem oficjalnego „świstka” (a.k.a. protokołu zdania i odbioru). Prowadziło
to na początku do kłótni, które trwały czasem ponad godzinę zanim zespół się
podzielił. Poruszyliśmy ten temat na retrospekcji i cały zespół ustalił
następujące rozwiązanie: gdy po 15 minutach nie udaje się stworzyć zespołów (i
co ważniejsze miejsc siedzenia :P ) jedna osoba arbitralnie ustala podział (ten
„zaszczyt” przypadł mnie). I powiem
szczerze, że od tamtej retrospekcji bardzo rzadko musiałem interweniować.
Na koniec inna sytuacja związana z podziałem zespołów. Jakiś
czas temu na korytarzu zaczepił mnie kolega z pracy, który prowadzi dwa małe
projekty. Zapytał mnie w jaki sposób powinien zorganizować product baclogi tych
projektów, aby mieć większą kontrolę nad nimi. Zaproponowałem, aby połączył oba
backlogi w jeden. On jednak poszedł o krok dalej i połączył zarówno backlogi
jak i zespoły (liczące 2-3 osoby). Po jakimś czasie stwierdził, iż było to tak
naturalne rozwiązanie, że aż dziw bierze że nie wpadł na to wcześniej. Teraz ma
większą kontrolę nad projektem, lepszy przepływ wiedzy między ludźmi oraz
potencjalnie mniejsze problemy w okresie wakacyjnym.
Z opisanych sytuacji ja wyciągnąłem następujące lekcje:
- Warto zastanowić się nad strukturą zespołu. Czy odpowiada aktualnej sytuacji w twoim projekcie?
- „Najciemniej pod latarnią” . Czasem potencjalnie najbardziej oczywiste rozwiązania są najtrudniejsze do zauważenia
- Strach przed zmianą jest jednym z największych wrogów zwinności
- Techniki i metody opisywane w różnych źródłach (książkach, artykułach, blogach ;)) niech będą dla Ciebie inspiracją a nie procedurą postępowania. Nie bój się eksperymentować.
