Po przeczytaniu książki Jacka Wieczorka “Labirynty Scruma”, której recenzja gościła zresztą na blogu Karoliny, natknąłem się na naprawdę skomplikowany projekt, prowadzony przez wiele zespołów. Przez jakiś czas obracając się w tak skomplikowanym, trudnym i wymagającym środowisku zdałem sobie sprawę z tego jak trudnym zadaniem jest problem skalowalności. Główne problemy jakie się pojawiły dotyczyły zależności pomiędzy zespołami. Trudne okazało się ustalenie już na etapie planowania czy, tworząc coś, jeden zespół będzie zależny od drugiego. Ponieważ temat wykracza poza obszar Scruma oraz poza obszar egzaminu scrum.org na Scrum Mastera, pomyślałem, że pociągnę temat trochę tak jak Jacek – o problemach, dodając trochę swoich własnych przemyśleń.
Pętlę sprzężenia zwrotnego
Temat współpracy i współdziałania wielu zespołów przy większych projektach został dostrzeżony, jednak zaadresowanie problemu okazało się skomplikowane na tyle, że powstało wiele różnych metodyk skalowania takich jak SAFe, Spotify, czy Nexus, którego głównym celem jest zaadresowanie zależności, a który bazuje na Scrumie, będąc w istocie jego rozwinięciem. Kluczowe do działania okazały się trzy pętlę sprzężenia zwrotnego pomiędzy nowymi ceremoniami dodanymi ponad Scrumem w ramach Nexusa, a ceremoniami istniejącymi w samym Scrumie, które opisałem poniżej.
Planowanie Sprintu Nexusa
W Nexusie jest Planowanie Sprintu Nexusa (ang. Nexus Sprint Planning), które przeprowadzone jest przez reprezentantów zespołów. Jego efektem ma być Cel Sprintu Nexusa (ang. Nexus Sprint Goal) oraz ustalenie, który zespół co będzie robił. Kluczowe staje się tu wykrycie zależności pomiędzy zespołami. Po Planowanie Sprintu Nexusa mamy tradycyjne Planowanie Sprintu we wszystkich zespołach, ale wejściem dla tej ceremonii jest rezultat właśnie Planowania Sprintu Nexusa i tu pojawia się pierwsza, kluczowa pętla zwrotna. Po Planowaniu Sprintu do uczestników Planowania Sprintu Nexusa powinna trafić informacja o potencjalnych, wykrytych problemach, zależnościach lub po prostu informacją, że zespół nie da rady dowieźć czegoś, co co zaplanowano na podczas Planowania Sprintu Nexusa.
Codzienny Scrum Nexusa
Ta pętla informacji zwrotnej jest pomiędzy Codziennym Scrumem Nexusa (ang. Nexus Daily Scrum) a Codziennym Scrumem (ang. Daily Scrum). Najpierw odbywa się Codziennym Scrum Nexusa przeprowadzany przez delegatów zespołów scrumowych. Po nim, już równolegle w zespołach, odbywa się codzienny stand-up z uwzględnieniem informacji pochodzących ze spotkania na poziomie produktu. Tu znów mogą znów zostać wykryte zależności i/lub problemy wymagające zgłoszenia podczas następnego Nexus Daily.
Przegląd i Retrospektywa Sprintu Nexusa
Sprint Nexusa kończy się Przeglądem Sprintu Nexusa (ang. Nexus Sprint Review) i Retrospektywą Sprintu Nexusa (ang. Nexus Sprint Retrospective). Najpierw jest Nexus Sprint Review z udziałem delegatów z każdego zespołu. Zastępuje indywidualne Przeglądy Sprintu Zespołów Scrumowych; tu przedmiotem oceny biznesu jest Zintegrowany Przyrost.
Retrospektywa zaś odbywa się na trzech poziomach.
- Najpierw spotykaj się przedstawiciele poszczególnych zespołów i tu poruszane są kwestie, które wykraczają poza dany zespół i mogą wpływać na inne – celem jest to, aby wspólne problemy były widoczne dla wszystkich (przypominam, że jednym z filarów Agile jest właście transparentność).
- Następnie swoje Przeglądy Sprintu mają poszczególne zespoły osobno. Tu również mogą być poruszane tematy omawiane na powyższym spotkaniu. Pozostałe reguły co do zasady są takie same jak w Scrumie.
- Po zespołowych retrospektywach znów mogą pojawić się informacje zwrotne dla pozostałych zespołów, co oznacza, że potrzebne jest jeszcze jedno spotkanie wyznaczonych przedstawicieli zespołów scrumowych i ustalenie, w jaki sposób należy monitorować realizację zidentyfikowanych działań.
Najczęstsze problemy Nexusa
Poza tym, że wspomniane pętle sprzężenia zwrotnego mogą nie działać, zdarzają się te same problemy, które trapią Scruma, które w swojej książce doskonale opisał Jacek Wieczorek wraz z potencjalnymi sposobami jak je można rozwiązać. Dochodzą też jednak nowe, wynikające z tego, że zespołów mamy więcej oraz pojawiają się między nimi zależności.
Dostępność Product Ownera dla kilku zespołów
Rozpoznanie: Product Owner jest jeden, jednak nie jest dostępny dla zespołu ponieważ jest to fizycznie niemożliwe, bo on jest jeden, a zespołów jest dużo. Zwyczajnie może również zdarzyć się taka sytuacja, że jeden człowiek, nawet bardzo dobry w roli Właściciela Produktu, nie będzie w stanie radzić sobie ze wszystkimi detalami wymagań biznesowych.
Rozwiązanie: Proxy Product Owner – delegat Product Ownera, który będzie pracował z danym zespołem, pomimo, że osobą decyzyjną pozostaje wciąż Product Owner, który mniej będzie skupiał się na detalach wymagań, a bardziej na wizji rozwoju produktu – odpowie na pytanie, w którym kierunku należy podążać i decydować, które z “grubych” wymagań powinny być realizowane i w jakiej kolejności.
Nexus Daily Scrum nie działa
Rozpoznanie: Delegaci zespołów nie chcą uczestniczyć w Nexus Daily, uważając, że jest to strata czasu. Inny symptom to Nexus Daily jest rzadziej niż raz dziennie, np. raz lub dwa razy w tygodniu.
Rozwiązanie: Proponowałbym najpierw sprawdzenie jakie tematy są poruszane podczas tych spotkań. Nexus Guide rekomenduje 3 pytania:
- Czy praca wykonana poprzedniego dnia została pomyślnie zintegrowana? Jeśli nie – dlaczego tak jest?
- Jakie nowe zależności odkryto?
- Jakie informacje należy przekazać wszystkim zespołom działającym w ramach Nexusa?
Podczas Codziennego Scruma Nexusa uczestnicy powinni się skupić na wpływie każdego zespołu na Zintegrowany Przyrost. Ważna jest ich świadomość, motywacja, a także wzajemna odpowiedzialność. Nawiążę tu do złotego kręgu, o którym mówi w swoim wystąpieniu Simon Sinek. Często wiemy co robimy oraz w jaki sposób, fundamentalne jest jednak zrozumienie dlaczego / po co coś robimy. Na starcie daj to zrozumienie swojemu zespołowi.
Wyjątkowo duża ilość zależności
Rozpoznanie: Pomiędzy zespołami istnieje wyjątkowo dużo zależności, jakakolwiek historyjka powoduje, że aby ją zaimplementować, wymagany jest skoordynowany wysiłek wielu zespołów.
Rozwiązanie: Proponuję sprawdzić jak podzielone są zespoły względem architektury. Może się okazać, że zespoły nie są podzielone pionowo na zespoły odpowiedzialne za dane fragmenty wartości biznesowej, ale są podzielone i przypisane horyzontalnie do komponentów albo architektonicznych warstw. Taki podział horyzontalny powoduje, że aby zrobić czasem prostą wartość biznesową, należy przekopać się przez cały stos warstw. Takie ustawienie pracy potęguje zależności pomiędzy zespołami oraz dodaje olbrzymi narzut organizacyjno-komunikacyjno-koordynacyjny wymagany w takiej sytuacji.
Zbyt wielu interesariuszy
Rozpoznanie: Przy skomplikowanych i złożonych projektach często bywa tak, że ilość interesariuszy, o których potrzeby należy zadbać, jest tak duża, że dochodzi do konfliktu interesów czy wewnętrznych tarć bądź to na skutek niewystarczającej komunikacji pomiędzy nimi lub po prostu z uwagi na to, że każdy ma swoje priorytety. Oczywiście dla każdej osoby osobno jej priorytet jest tym najbardziej priorytetowym :)
Rozwiązanie: Metody radzenia sobie z taką, dosyć trudną sytuacją, przy założeniu, że nie uda się sprawić, aby to jedna osoba ostatecznie miała decydujący głos, to zebranie wszystkich interesariuszy razem, zrozumienie ich potrzeb, umożliwienie im wypracowania kompromisu między sobą albo próba demokracji.
Podsumowanie
Praktyka pokazała, że jeśli wzrastają ilości zespołów, lawinowo rosną zależności między komponentami i już nie lawinowo, a wykładniczo rośnie stopień skomplikowania projektu. Pojawiają się nieuchronne konflikty i napięcia pomiędzy zespołami wynikające z zależności, których nie zawsze udało się odpowiednio wcześnie wykryć. Dodatkowo sprawę może pogorszyć fakt, jeśli Product Owner albo jego delegat wraz z zespołem dosyć późno zdadzą sobie sprawę z tego, że aby coś zrobić, wymagana jest zależność od innego zespołu – inny zespół ma już zaplanowany aktualny sprint albo jest w trakcie, a terminy gonią. Wymaga to sporego doświadczenia, ogromnej odporności na stres oraz umiejętności “kanalizowania” spornych sytuacji do właściwego procesu, jednocześnie unikając wzajemnych oskarżeń.
Kluczowa jest rola Scrum Masterów, którzy powinni rozumieć jak cały ten proces powinien działać. Ich rola jest znacznie trudniejsza w porównaniu do i tak niełatwej roli jaką ma Scrum Master w pojedynczym zespole. Wymaga też współpracy z innymi Scrum Masterami, a także dużej orientacji w całym projektowym środowisku.
Reasumując, Nexus jest ramą do prowadzenie trudnych, skomplikowanych projektów prowadzonych jednocześnie przez wiele zespołów – a więc już nie małych projektów. W swoich założeniach jest frameworkiem pomagającym wykrywać, śledzić oraz rozwiązywać zależności pomiędzy zespołami, niezależnie od tego czy zależności są na poziomie wymagań, wiedzy czy pomiędzy finalnie dostarczanymi przyrostami w postaci gotowego oprogramowania. Największym wyzwaniem skali według mnie nie są procesy, a ludzie. Kilka zespołów często znaczy kilka lokalizacji, różne strefy czasowe i wiele kultur. Wyzwania z tym związane, to temat na odrębny artykuł, który już zresztą pojawił się na blogu, a napisał go Maciej Bieniasz.
W komentarzach dajcie znać jakie są Wasze doświadczenia we współpracy kilku zespołów w jednym projekcie, co poszło nie tak i jakie były tego powody. Ciekaw jestem, czy wyzwania są tak uniwersalne, jak mi się wydaje.
