W naszej podróży po metodyce Scrum staramy się wyjaśnić wszystkie idee, na których jest ona oparta. Dziś nadeszła pora na kross-funkcjonalność.
Kross-funkcjonalność zespołu
Trzeba przyznać, że chociaż sam proces scrumowy jest dość prosty, to im dokładniej dowiemy się, co przyświecało autorom Scrum Guide, tym lepiej będziemy w stanie wykorzystać Scrum na naszą korzyść. Na nasze szczęście Przewodnik Scrum jest napisany zwięźle i precyzyjnie.
„Scrum Teams are self-organizing and cross-functional. (…) Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” – Scrum Guide
Powyższe zdania pojawiają się na samym początku rozdziału poświęconego Scrum Team. O samoorganizacji już rozmawialiśmy, dlatego tym bardziej warto przyjrzeć się kross-funkcjonalności.
Z przytoczonej definicji wynika, że Zespół Scrumowy powinien posiadać wszystkie kompetencje niezbędne do wykonania pracy bez wspomagania się osobami z poza zespołu.
Wiele osób popełnia błąd, zakładając, że kross-funkcjonalność dotyczy jednostek. Zarówno zdrowy rozsądek, jak i Scrum Guide podpowiadają nam jednak, że nie możemy oczekiwać od każdej jednej osoby, aby była ekspertem we wszystkim. To Scrum Team, całościowo, jest zespołem eksperckim.
Oczywiście wśród członków tegoż zespołu znajdą się specjaliści i eksperci. Często będą to też osoby dedykowane poszczególnym aspektom iteracyjnego wytwarzania oprogramowania, jak np. testerzy, programiści czy analitycy. Nie zmienia to jednak faktu, że kross-funkcjonalność zawsze powinna być rozpatrywana co najmniej na poziomie Development Teamu.
„Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment.” – Scrum Guide
Zarówno Scrum Team, jak i zawierający się w nim Development Team powinny być kross-funkcjonalne w zakresie przewidzianych dla nich obowiązków. To znaczy, że ten pierwszy powinien uwzględniać zadania Scrum Mastera i Product Ownera, a ten drugi dotyczy „jedynie” budowania Przyrostu.
Zakres kross-funkcjonalności
Najczęściej spotykana fraza przy omawianiu kross-funkcjonalności to „w zakresie niezbędnym do wykonania zadania”. To znaczy, że najpierw musimy jasno i precyzyjnie zdefiniować, czym będziemy się zajmować. Dla Development Teamu tą precyzyjną definicję stanowi Product Backlog.
Wszyscy członkowie zespołu powinni znać backlog i pilnować, żeby nie znalazły się w nim żadne elementy, które wykraczają poza ich kompetencje.
Znów mówimy tu o kompetencjach w ujęciu całego zespołu. Każdy, kto w trakcie sesji Product Backlog Refinement ma wątpliwości co do jakiegokolwiek wymagania, powinien o tym głośno i wyraźnie powiedzieć. A Scrum Master, który podejrzewa, że taka sytuacja ma miejsce, powinien drążyć i wyciągać wątpliwości na światło dzienne.
Każde wymaganie z backlogu może znaleźć się na szczycie listy i trafić na kolejny Sprint Planning. Jeżeli dopiero tam okaże się, że nie mamy odpowiednich umiejętności czy zasobów do jego realizacji, to nie tylko stracimy mnóstwo czasu, ale i spowodujemy istotne opóźnienia. Bo jeśli te wymaganie przekażemy do innego zespołu przy okazji planowania, to trafi ono do backlogu i będzie czekało na realizację co najmniej do następnego Sprintu.
„Posiadaj w zespole tyle ludzi i tyle umiejętności, aby być w stanie dostarczyć to, do czego ten zespół został powołany.” – #białko
Kross-funkcjonalność możemy zapewnić na dwa sposoby. Pierwszy z nich to ściągnięcie do zespołu wielu wszechstronnych osób, potrafiących zająć się każdym aspektem tworzonego produktu. Drugie podejście zaleca ograniczenie różnorodności backlogu i wąską specjalizację.
Pamiętając o tym, że idealna wielkość zespołu to około 5 osób, wybór powinien być prosty.
Silosy kontra eksperci, czyli pułapki kross-funkcjonalności
Zarówno pójście w stronę wąskiej specjalizacji, jak i absolutnej uniwersalności niosą ze sobą wiele problemów. Jeżeli chcemy znać się na wszystkim, to ogrom czasu poświęcimy na doskonaleniu się i przekazywaniu/zdobywaniu umiejętności. Czasami może okazać się, że z wielu z nich nawet nie skorzystamy.
Z drugiej strony, jeżeli zajmujemy się tylko i wyłącznie określonym kawałkiem systemu, to żeby zrealizować niektóre funkcjonalności będziemy musieli łączyć siły z innymi zespołami. Spowoduje to uciążliwe zależności pomiędzy backlogami i konieczność częstej synchronizacji.
Na pewno warto znać się na tym, z czego często korzystamy. Jednak w dzisiejszych czasach trudno być uniwersalnym i znać się na wszystkim całościowo.
Trzeba w tym momencie wspomnieć o odwiecznej walce pomiędzy zwolennikami Component i Feature Teamów. Te pierwsze są ekspertami od jakiejś części systemu (komponentu), a te drugie – od jakiegoś obszaru funkcjonalności (w zakresie wszystkich komponentów). Podobnie jak analizując kross-funkcjonalność, tak i tutaj musimy przeanalizować nasze potrzeby.
Jeżeli mamy zespoły odpowiedzialne za poszczególne komponenty systemu, to w przypadku funkcjonalności wykorzystującej wiele z nich, zaplanowanie jej do realizacji będzie koszmarem z uwagi na zależności. Z drugiej strony, jeśli nasze zespoły potrafią realizować kompletne funkcjonalności dotykające wszystkich zakamarków systemu, to przy realizacji kilkudziesięciu z nich w każdym Sprincie, uzgodnienie tych wszystkich zmian i ich zmerge’owanie będzie koszmarem.
Jak zawsze więc musimy odpowiedzieć sobie na pytanie: w którym miejscu chcemy mieć problemy? Jest to kwestia indywidualna, bo niektórzy lepiej sobie poradzą z wspólnym planowaniem, a inni z jednoczesnym operowaniem na kodzie przez wiele osób.
To jednak jest już temat samoorganizacji, a nie kross-funkcjonalności.
Kross-funkcjonalność poruszaliśmy też kiedyś na naszym kanale na YouTube, na którym poruszamy też tematy związane z szeroko pojętą zwinnością. Zachęcamy do subskrypcji.
