Nexus to zaproponowane przez Scrum.org podejście do skalowania Scruma. Ma ono za zadanie pomagać Scrum Teamom osiągać więcej razem niż gdyby produkt tworzył jeden zespół. W tym tekście postaram się opisać podstawy tej formy pracy i to, jak zmienia ono struktury pracy w Scrum.
Przewodnik po Nexusie znajdziesz na oficjalnej stronie scrum.org.
Nexus wg Przewodnika
Nexus to ramy postępowania składające się z ról, zdarzeń, odpowiedzialności, artefaktów i zaangażowań. Podobnie jak pozostałe metody skalowania, zasady Nexusa definiują sposób pracy około 3 do 9 zespołów pracujących w Scrumie. Praca Teamów nadal bazuje na Przewodniku po Scrumie i jest uzupełniona o zasady Nexusa. Całość skupia się przede wszystkim na usuwaniu zależności i przeszkód pomiędzy pracą wielu zespołów, tak, by integracja przyrostu była możliwa.
Nexusem nazywamy także grupę Scrum Teamów, które pracują razem by stworzyć produkt spełniający określony cel. Mają oni jednego Product Ownera, jeden Product Backlog (przeczytaj: Artefakty Scruma cz.1 – Backlog Produktu) i szereg technik pozwalających na zredukowanie złożoności pracy występujących podczas tworzenia przyrostu produktu.
Zależności i utrudnienia w sytuacjach, gdy nad jedną sprawą pracuje wiele osób wynikają głównie z dwóch przyczyn: struktury produktu i struktury komunikacji. Nexus odpowiada na te obszary i proponuje rozwiązania mające realny wpływ na ich usprawnienie.
W relacji do Scruma, Nexus nie zmienia go, a uzupełnia i rozszerza. Do najważniejszych nowości należą:
- Odpowiedzialności – wprowadzona jest nowa rola, Nexus Integration Team. Odpowiada on za dostarczenie wartościowego, użytecznego i zintegrowanego przyrostu, przynajmniej raz na Sprint.
- Zdarzenia – pojawiają się nowe zdarzenia, które uzupełniają lub zastępują spotkania Scrumowe, ale nie dyskwalifikują płynących z nich wartości.
- Artefakty – pojawiają się Nexus Sprint Backlog oraz Integrated Increment. Oba nie stoją w konflikcie z podstawą Scruma, uzupełniają ją o wymagane dla integracji elementy.
Odpowiedzialności w Nexusie
Zanim opowiem o odpowiedzialnościach, warto wprowadzić i wyjaśnić nową rolę jaką jest Nexus Integration Team. Składa się on z Product Ownera, Scrum Mastera i jednego lub większej liczby członków zespołu (wybieranych z poszczególnych Scrum Teamów). Warto zaznaczyć, że członkowie muszą posiadać odpowiednie umiejętności, by być w stanie zintegrować finalny Increment produktu. Nie muszą to być zawsze te same osoby – Developers mogą się zmieniać gdy zajdzie taka potrzeba.
Nexus Integration Team jest odpowiedzialny za konsultowanie i coaching Scrum Teamów w celu wzrostu zdolności do wydawania wartościowego Incrementu. Te zadania są nadrzędne w stosunku do tych przypisanych w podstawowym zespole. Podczas gdy zespoły pracujące nad poszczególnymi elementami produktu odpowiadają za swoje obszary, NIT ma za zadanie wszystkie połączyć.
Product Owner w Nexusie pełni rolę taką samą jak w Scrumie. Nadal, skupiony jest on głównie na celu i wartość jaką dostarcza produkt. Mimo skalowania zespołów, nie pojawiają się nowe odpowiedzialności, występują za to nowe zadania i wyzwania. Zwiększenie skali to inna struktura, większy produkt i więcej zespołów, które mogą mieć na to wpływ.
Scrum Master w Nexusie pojawia się w dwóch aspektach. Oczywiście jako klasyczna rola, opiekun ram Scruma oraz jako strażnik zasad Nexusa. W NIT będzie on pełnił właśnie ten drugi zestaw zadań. Nie jest to oczywiście jakiegoś rodzaju lider SMów, tylko osoba, która skupia się na tym, by skalowanie działało, a robi to wspierając cały skład osobowy pracujący nad produktem.
Wydarzenia w Nexusie
Co do zasady, wszystkie wartości dostarczane przez zdarzenia Scrumowe zostały zachowane również w Nexusie. Z uwagi na skalowalny charakter działań, konieczne były wprowadzenie nowych punktów inspekcji i adaptacji. Tak więc wśród wydarzeń Nexusa wyróżniamy:
- Sprint
- Nexus Sprint Planning
- Nexus Daily Scrum
- Cross-Team Refinement
- Nexus Sprint Review
- Nexus Sprint Retrospective
O ile sam Sprint pozostaje niezmienny, pozostałe spotkania stanowią punkt wyjścia do poszczególnych wydarzeń Scrum Teamów i dają szerokie spojrzenie na działania w Nexusie. Ich założenia są identyczne jak te opisywane w Przewodniku po Scrumie.
Artefakty i zaangażowanie w Nexusie
Artefakty mają za zadanie wspierać przejrzystość w pracy nad produktem i podobnie jak przy wydarzeniach, w sytuacji skalowania potrzebne są drobne modyfikacje. Wprowadzone są po to, by nowe aspekty pracy w przypadku wielu zespołów zostały w równym stopniu objęte inspekcją i adaptacją.
Znany ze Scruma Product Backlog i jego zobowiązanie, Cel Produktu, pozostają niezmienne. Jedynie perspektywa rozmiaru produktu może mieć tu znaczenie, choć z pewnością nie wpłynie to na same ramy postępowania.
Dwa nowe artefakty, czyli Nexus Sprint Backlog i Integrated Increment są odzwierciedleniem tych podstawowych z dopasowaniem ich do środowiska w skali. Ich zaangażowania pozostają takie same.
Warto podkreślić w tym miejscu, że przejrzystość artefaktów jest szczególnie istotna w Nexusie, bo zainteresowanie nimi rozszerza się na wiele zespołów. W takiej sytuacji, niezwykle ważne jest, by poziom wiedzy o nich był równy, a przynajmniej by artefakty były tak samo dostępne i widoczne dla każdego członka zespołów pracujących nad produktem. Analogicznie jak ma to miejsce podczas pracy w Scrumie.
Podsumowanie
Skalowanie Scruma w przypadku Nexusa, to podejście dość proste w swoim opisie – podobnie jak Przewodnik po Scrumie, Przewodnik po Nexusie jest krótki i bardzo treściwy. Samo stosowanie opisanych tam zasad może być wyzwaniem. Nie zmienia to jednak faktu, że jest jednym z prostszych podejść skalowalnych. W odróżnieniu od innych (np. SAFe, LeSS), Nexus nie posiada obszernie opisywanych zasad i narzędzi. To właśnie czyni go elastycznym i wartym rozważenia w organizacjach, które z powodzeniem korzystają lub planują wdrożyć Scruma.
Sprawdź nasze ostatnie wpisy:
