Blog

Jedną z cech zespołów developerskich w Scrumie jest to, że „(…) są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu (…)”. Ta lakoniczna definicja wyciągnięta ze Scrum Guide zdaje się nie wymagać dodatkowej interpretacji, a jednak wciąż zdarzają się nieporozumienia z nią związane.

Zacznijmy od nazwy

Przymiotnik „cross-functional” na język polski przełożony został jako „międzyfunkcjonalny”, choć puryści językowi woleliby zapewne formę „między-funkcjonalny”. Zaproponowana przez autorów tłumaczenia nazwa nie jest powszechnie używana; dużo częściej można usłyszeć o zespołach „wskroś-funkcjonalnych” (aż zęby bolą, jak się to słyszy), a króluje niemający nic wspólnego z językiem polskim „cross-funkcjonalny”, lub po prostu skrót XFT (od angielskiego cross functional team).

Problem z tymi nazwami, bynajmniej nie związany z ich językową poprawnością, jest następujący: dążą one do maksymalnego zbliżenia do angielskiego oryginału (najlepiej również brzmieniem), zamiast poszukiwać najlepszego odpowiednika już istniejącego w języku polskim. A takim, zakurzonym być może i mniej atrakcyjnym niż „cross-cokolwiek” słowem, jest „wszechstronny”.

Słownik Języka Polskiego (https://sjp.pwn.pl/szukaj/wszechstronny.html) wyjaśnia, że wszechstronny to „(…) mający rozległe zainteresowania i wiele umiejętności, rozwijający działalność w wielu dziedzinach (…)” lub „(…) obejmujący rozległy zakres, uwzględniający wszystkie aspekty czegoś (…)”. Pasuje idealnie, czyż nie?

Innym pięknym słowem, którego można użyć, jest „interdyscyplinarny” (https://sjp.pwn.pl/szukaj/interdyscyplinarny.html). Co prawda kojarzy się z domeną badań naukowych bardziej niż ze zwyczajnym budowaniem produktów (na przykład oprogramowania), ale bez wątpienia oddaje dobrze istotę tego, czym XFT jest…

Do nazwy jeszcze wrócę, na razie chciałbym doprecyzować co się pod nią kryje, czyli jaka jest charakterystyka zespołu wszechstronnego („między-funkcjonalnego”).

Problem nieprzewidywalności

W każdym sprincie zespół realizuje kolejne elementy backlogu produktu, czasem podobne do siebie, ale często skrajnie różne. Ilość pracy, do której wykonania potrzeba konkretnej umiejętności, nie jest taka sama dla poszczególnych wymagań. To samo dotyczy realizowanych usprawnień, rozwiązywanych błędów, wsparcia użytkowników i wszystkich innych czynności, jakie wykonuje zespół.

Ta zmienność utrudnia przewidywanie, jakie kompetencje są potrzebne i „ile” ich powinno być w zespole. Ponieważ nośnikami kompetencji są ludzie (członkowie teamu, a w Scrumie po prostu developerzy), może zdarzyć się, że w jakimś sprincie nie wszystkie posiadane umiejętności będą potrzebne. Możliwa jest też sytuacja odwrotna, w której pracy jest więcej, niż osób zdolnych ją wykonać przed zakończeniem iteracji. Jak sobie z tym radzić?

Teoretycznie można na potrzeby każdej iteracji dopasowywać skład zespołu do charakteru pracy, która jest do wykonania. W praktyce jest to mało realne rozwiązanie, a jego zastosowane okazuje się nieskuteczne. Scruma używa się przecież do rozwiązywania problemów złożonych, z którymi „w pakiecie” przychodzi nieprzewidywalność. Planowanie sprintu jest w istocie prognozowaniem, a cechą każdej (nawet najlepszej) prognozy jest ograniczona sprawdzalność.

Skoro planowanie kończy się sformułowaniem prognozy (wysoko prawdopodobnej, ale wciąż obarczonej błędem), tym samym jest niemal pewne, że w czasie iteracji ujawni się coś, o czym podczas planowania nie było wiadomo. Nieznana jest też skala zmian, które trzeba będzie w planach poczynić w miarę, jak sprint zmierza ku zakończeniu. A to skutecznie uniemożliwia „dopasowanie” składu zespołu do charakteru pracy w danym sprincie. Prawie na pewno okaże się, że ktoś będzie musiał zrobić coś, co nie leży w zakresie jego podstawowych umiejętności…

Rozwiązanie z nieustannym przeformowaniem zespołu tak, by dopasować się do konkretnych wymagań w sprincie, ma też ogromną wadę związaną z utrudnieniem, a być może uniemożliwieniem, zbudowania relacji między developerami. Funkcjonując w takim zespole będą mieli poczucie tymczasowości, ciężko też będzie im w pełni zaangażować się rozwój produktu – o ile w ogóle uda się im zrozumieć, czym jest i dlaczego warto go budować.

Innym pomysłem jest takie układanie backlogu produktu, by w stały sposób obciążać osoby pracą adekwatną do ich kompetencji. Rzecz upiornie głupia, bo godzi w podstawy zwinności. Taka forma żonglerki backlogiem (bo ciężko to nazwać zarządzaniem) prowadziłaby do budowania nie tego, co potrzebne i wartościowe, ale tego, co zespół najlepiej potrafi wytwarzać. Poza tym problem nieprzewidywalności nadal istnieje, więc nieuchronnie w trakcie sprintów ujawniać się będzie praca, której być może nie będzie miał kto wykonać.

Pełna wymienność / zastępowalność

Wydawać by się mogło, że jedynym sposobem na zapewnienie, że zespół na pewno poradzi sobie z elementami backlogu produktu, jest zatrudnienie ludzi potrafiących robić wszystko. Zespół, w którym każdy developer potrafi wykonać dowolny rodzaj pracy niezbędnej przy budowaniu produktu, jest prawie zawsze wyjątkowo efektywny w działaniu (dlaczego nie zawsze wyjaśniam za moment).

Dla wielu osób pełna wzajemna zastępowalność (nazywana też pełną wymiennością) developerów jest synonimem „między-funkcjonalności”. Połączenie takiego przekonania z innym (równie niesłusznym), że „developer musi umieć programować” zaowocowało narodzinami mitu funkcjonującego w wielu organizacjach tworzących oprogramowanie, wedle którego zespół developerski składać musi się wyłącznie z programistów.

Pełna zastępowalność jest osiągalna (widziałem takie zespoły), ale jest zjawiskiem rzadkim. Nawet w zespołach, gdzie developerzy mają wszystkie kompetencje i mogliby takim „ninja-teamem” się stać, na przeszkodzie często staje niechęć do podejmowania określonego rodzaju pracy. Inaczej mówiąc z faktu, że ktoś coś potrafi, niekoniecznie wynika zapał, by to robić.

Zespoły, które faktycznie uzyskały pełną wymienność developerów nie powstały dzięki zatrudnieniu ludzi z niezbędnymi umiejętnościami, ale wyewoluowały do tego stanu. Niejednokrotnie zaczynały od zmagania się z brakiem wiedzy i kompetencji, lub musiały zdemontować wewnętrzne silosy kompetencyjne, powodujące „ukaskadowienie” pracy w sprintach.

Pełna wymienność jest czymś, do czego warto dążyć, zachowując przy tym zdrowy rozsądek. Scrum, podobnie jak inne metody zwinne, nie wymaga ani nawet nie oczekuje jej osiągnięcia.

Wszechstronny zespół

Wróćmy do Scruma i tego, jak definiuje on wszechstronność zespołu. Taki zespół musi mieć wszystkie umiejętności niezbędne do zbudowania nowej wersji Przyrostu zgodnie z ustalonym Definition of Done (DoD). W praktyce lista tych umiejętności wynikać będzie zarówno z DoD, jak i charakteru samego Przyrostu, którym może być fizyczny produkt, wirtualny byt jakim jest oprogramowanie, ale równie dobrze usługa lub proces biznesowy. Ba, może być to złożenie wszystkich tych rzeczy.

Co to właściwie znaczy „mieć wszystkie umiejętności”? Już wiadomo, że nie chodzi o pełną wymienność developerów, musi więc chodzić o zespół jako całość. Jeśli więc wszyscy developerzy (również ci nie programujący twórcy oprogramowania!) w sumie mają dość wiedzy i kompetencji, by wytworzyć Przyrost, to znaczy, że mamy zespół „między-funkcjonalny”, prawda? Cóż, niekoniecznie.

Liczy się nie tylko fakt posiadania umiejętności, ale też sposób, w jaki są one wykorzystywane. Podobnie jak „wszystko-potrafiący członkowie zespołu” nie wystarczą do osiągnięcia pełnej wymienności developerów, tak istnienie niezbędnych kompetencji w zespole nie wystarcza do uczynienia go wszechstronnym. Muszą być spełnione jeszcze dwa podstawowe warunki.

Warunek pierwszy: praca zespołowa

Skoro mówiąc o wszechstronności zespołu patrzymy na sumę kompetencji, jakie do niego wnieśli poszczególni developerzy, to jest oczywiste, że wyłącznie wspólna praca nad produktem dowodzi korzystania ze wszechstronności (i tym samym jej istnienia).

Jeśli w ramach zespołu dochodzi do powstania silosów specjalizujących się w poszczególnych rodzajach pracy, ciężko w ogóle mówić o zespole jako takim – jest to raczej zlepek mniejszych grup, bez wyjątku ograniczonych w zakresie posiadanych kompetencji. Możliwości całego zespołu zredukują się do najmniejszego wspólnego mianownika, którym będzie umiejętność przepychania pracy między tymi grupami. Niestety, nawet jeśli będzie to robione efektywnie, z definicji powstaną mini-kaskady, a zdolność radzenia sobie z nieprzewidzianymi problemami pozostanie bardzo ograniczona.

Innym sposobem na znaczące upośledzenie wszechstronności jest zorganizowanie pracy w sprincie tak, że każdy developer pracuje nad innym elementem backlogu produktu. „Front robót” to szeroka tyraliera, a współpraca między członkami zespołu niezbędna jest tylko w obszarach, gdzie występują zależności. Konieczność współpracy ujawni się również jeśli ktoś potrzebuje pomocy, bo zabraknie mu kompetencji, aby ukończyć pracę. Scrum nie zabrania takiego działania, ale w oczywisty sposób jest on sprzeczny z jedną z wartości jaką jest skupienie.

Prawdziwie wszechstronny zespół używa wspólnie swoich kompetencji do zrealizowania poszczególnych elementów backlogu produktu. Ale to nie wszystko (patrz: kolejny warunek).

Warunek drugi: przenikanie się kompetencji

Pisałem wcześniej o nieprzewidywalności, która czasami postawi zespół w trudnej sytuacji braku osoby potrafiącej zrobić coś pilnego, wcześniej nieplanowanego. Jedynym realnym sposobem radzenia sobie z tym jest uzyskanie stanu, w którym developerzy podejmują prace nie leżące w zakresie ich podstawowych (silnie wykształconych) kompetencji.

Skrajnym przykładem braku przenikania się kompetencji są wspomniane już silosy, których występowanie często jest pochodną sposobu funkcjonowania organizacji przed podjęciem decyzji o użyciu metod zwinnych. Im szybciej uda się takie „wyspy” kompetencji ze sobą połączyć, tym szybciej zespół uzyska wszechstronność w działaniu.

W literaturze można napotkać określenie „I-shaped developer”; opisuje ono developera, który bardzo twardo określa, jaką pracą się zajmuje, odmawiając podjęcia jakichkolwiek innych działań. Jeśli ktoś zdeklaruje „ja będę wyłącznie programował w C++”, inna osoba powie „ja potrafię wyłącznie testować”, a kolejna „ja jestem od tworzenia dokumentacji i niczego więcej” – wtedy realizacja wymagań przerzucana jest od osoby do osoby w zależności od tego, co jest akurat do zrobienia. To również mini-kaskada wewnątrz sprintu.

Minimum jakiego wymaga Scrum, by mówić o wszechstronności zespołu, to „T-shaped developers”, wyspecjalizowani w jakiejś dziedzinie ale zdolni sięgać poza nią (czego symbolem jest góra litery T).

Do dobrego zadziałania Scruma potrzeba w praktyce developerów posiadających nie jedną, ale przynajmniej dwie dobrze wykształcone kompetencje i umiejętność ich jednoczesnego wykorzystywania. Co więcej, taki „Π-shaped developer” ma też chęć i zdolność podejmowania tematów niekoniecznie leżących w obszarach kompetencyjnych reprezentowanych przez nóżki litery Π. Wystający nieco na prawo i lewo daszek litery Π symbolizuje więc zarówno łączenie dwóch kompetencji, jak i sięganie poza nie.

Wszechstronność a samodzielność

Do tej pory pisałem o dwóch mitach: utożsamiania wszechstronności z pełną wymiennością developerów, oraz przekonaniu, że wszechstronność to zwykła suma kompetencji. Pora zmierzyć się z mitem trzecim. Przypomnę cytat ze Scrum Guide mówiący, że zespoły są wszechstronne, jeśli „(…) w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu (…)”.

Wiele osób jest przekonanych, że aby spełnić ten postulat zespół musi być w stanie wykonać samodzielnie każdą pracę związaną z budowaniem Przyrostu. Skoro to developerzy wytwarzają Przyrost, to wydaje się oczywiste, że tylko oni pracować będą nad jego wytworzeniem. Może więc nie jest to mit? Aby odpowiedzieć na to pytanie, zastanówmy się jakie byłyby konsekwencje spełnienia tego postulatu w każdej sytuacji.

Jeśli zespół musi działać w pełni samodzielnie, za każdym razem, gdy ujawni się brak wymaganych kompetencji, niezbędne będzie zatrzymanie rozwoju produktu do momentu, gdy zespół pozyska nowe umiejętności. Czy oznaczałoby to zawieszenie na kołku Scruma na jakiś czas? Czy też wciąż praca odbywałaby się w sprintach, tyle że ich wynikiem nie byłby produkt a rozwój umiejętności? Obie odpowiedzi w umiarkowany sposób pasują do Scruma takiego, jaki opisany jest w Scrum Guide.

Alternatywnie, można by do zespołu dołączać kolejne osoby tak, by uzupełnić kompetencyjne braki. Ceną byłaby destabilizacja relacji, ale może warto byłoby ją płacić. Tyle tylko, że zespół potencjalnie rozrastałby się coraz bardziej, a w końcu nieuchronnie rozleciał na kilka mniejszych.

No więc może rozbudowanie zespołu powinno mieć miejsce „na jakiś czas”, a potem powinien on zostać zredukowany do składu, który ma kompetencje potrzebne teraz? Uważny czytelnik zauważy, że wracamy do problemu już wcześniej opisanego, a wynikającego z nieprzewidywalności. Nie do końca wiadomo, jakie kompetencje są potrzebne w rozpoczynającym się sprincie, co więc dopiero mówić o trafnym określeniu tego na wiele iteracji do przodu? Skąd wiedzieć jakich umiejętności zabraknie (i zawczasu je „dodać”), a które już będą niepotrzebne (i mogą zostać „usunięte”)?

Scrum jest metodą opartą o empiryzm, a więc musi być pragmatyczny. Istnieje proste rozwiązanie: zespół, który natrafi na brak kompetencyjny, powinien uzyskać pomoc z zewnątrz. Nawet jeśli czyni go to „niesamodzielnym” (o tym dwa słowa za moment). A jeśli jasne stanie się, że taka sytuacja się powtarza, wtedy sensownym będzie rozważenie jak niedobór umiejętności uzupełnić. I to niekoniecznie z dnia na dzień, być może potrzeba na to sprint lub dwa.

Czy takie postępowanie będzie zgodne z wymogami twórców Scruma? Oczywiście, że tak. „Posiadanie wszystkich umiejętności” obejmuje też zdolność do pozyskiwania pomocy z zewnątrz i uczenia się od zewnętrznych ekspertów. Jeśli developerzy potrafią zrobić prawie wszystko sami, a w niektórych obszarach wspierają się osobami spoza zespołu, dowodzi to jak najbardziej ich umiejętności wytwarzania Przyrostu.

To pozwala sobie pragmatycznie radzić z produktami, w których okazjonalnie (na przykład raz na kilkanaście sprintów) trzeba zrobić coś w egzotycznej lub przestarzałej technologii. Niekoniecznie warto uczyć się jej w zakresie dającym samodzielność, często wystarczy zdolność do przekazania pracy komuś, a następnie „skonsumowania” efektów.

Źle rozumiana „samodzielność” nie ma nic wspólnego ze wszechstronnością. Dążenie do niezależności w działaniu za wszelką cenę jest zazwyczaj szkodliwe (jak każda inna skrajność). Z drugiej strony umiejętność pozyskania pomocy nie świadczy wcale o „niesamodzielności” – wszystko zależy od sposobu, w jaki zewnętrzne wsparcie jest zdobywane i wykorzystywane. Dlatego pragnę zwrócić uwagę na dwie kwestie.

Umiejętność samoorganizacji

Korzystanie ze pomocy ekspertów (albo nawet innego zespołu) nie jest sprzeczne z postulatem wszechstronności zespołu, o ile organizatorem tego wsparcia są sami developerzy. Zwrócą się do kolegów lub ekspertów i współpracując z nimi, poradzą sobie z brakiem kompetencji. A jeśli organizacja wymaga formalnej decyzji Product Ownera lub managementu (bo pomoc eksperta może kosztować), developerzy zawnioskują o zgodę i będą mieli mocne argumenty ułatwiające jej uzyskanie.

Ciężko natomiast mówić o wszechstronności, jeśli po odkryciu luki kompetencyjnej zespół zatrzyma się w pół kroku, czekając na to, aż ktoś podpowie mu co zrobić. Inaczej mówiąc, jeśli pomoc organizowana jest nie z inicjatywy zespołu, tylko Product Ownera, Scrum Mastera lub szeroko rozumianego managementu organizacji, zespół nie jest ani w pełni samoorganizujący, ani wszechstronny.

Prywatnie uważam, że nie sposób rozdzielić tych dwóch cech zespołu developerskiego od siebie. Niezdolność do samoorganizacji choćby w minimalnym zakresie w praktyce nie daje szans na wszechstronność. Umiejętność samoorganizacji jest jedyną kompetencją, której nie da się uzyskać w formie zewnętrznego wsparcia, bo takie z definicji byłoby zaprzeczeniem całego konceptu.

Z drugiej strony nawet potężne braki kompetencyjne da się jakoś zniwelować i powoli usunąć, jeśli to zespół (a nie ktoś z zewnątrz) czuje się odpowiedzialny za ten proces i zależy mu na zmianie stanu spraw. Jeśli zespół jest świadom tego, co go ogranicza i dokonuje niezbędnych usprawnień, będzie stawał się coraz bardziej wszechstronny (i być może w końcu w pełni samodzielny, a może nawet uzyska pełną wymienność developerów).

Charakter luk kompetencyjnych

Drugą krytyczną kwestią przy dyskusji o „samodzielności” jest rozmiar i charakter luk kompetencyjnych. Zespół developerski musi być w stanie poradzić sobie z większością pracy, jaką trzeba wykonać, aby produkt zbudować. Inaczej mówiąc wsparcie musi mieć charakter incydentalny.

Przykładowo, jeśli czasami (w pojedynczych wymaganiach, co dwa-trzy sprinty) potrzebujemy wsparcia prawnika, to brak znajomości przepisów i umiejętności pisania dokumentów nie dowodzi braku wszechstronności zespołu.

Natomiast jeśli ten prawnik jest niezbędny do ukończenia prac nad większością elementów backlogu produktu, powinien stać się członkiem zespołu (jako developer, być może na część etatu). Zespół nieustannie konsultujący się z prawnikiem – zewnętrznym ekspertem – będzie miał kłopot z ukończeniem prac, a więc nie będzie wszechstronny w rozumieniu Scruma.

Istotne jest też pamiętanie o granicach sprintów. Pozyskiwanie wsparcia z zewnątrz musi umożliwiać kończenie podjętych prac w iteracji, w której one się rozpoczęły. Ciężko mówić o wszechstronności, jeśli zespół tylko co drugi sprint (albo i rzadziej) jest w stanie osiągnąć „done” dla swojego produktu.

Ciągłe doskonalenie

Na początku, tuż po powołaniu do istnienia, wiele zespołów ma bardzo ograniczone zdolności korzystania jako jeden organizm z kompetencji wniesionych przez poszczególnych developerów. Potrzeba minimum zdolności do samoorganizacji oraz zaangażowania, by nauczyć się jak posiadanych umiejętności używać efektywnie w tym konkretnym zespole. Przydaje się też odwaga i otwartość, żeby zrobić coś inaczej, albo podjąć zagadnienia niekoniecznie „ze swojej” dziedziny.

To oznacza, że wszechstronność nie jest binarna – jest to stan wynikający z bieżących uwarunkowań i tego, jak na te uwarunkowania reagują developerzy. Większość zespołów dojrzewając staje się coraz bardziej „między-funkcjonalna”, a towarzyszy temu rosnąca umiejętność samoorganizacji. Lub też rosnące zdolności samoorganizacji owocują wzrostem wszechstronności – sądzę, że oba stwierdzenia są prawdziwe.

Wracając na moment do nazwy: „między-funkcjonalny”, „wskroś-funkcjonalny”, „wszechstronny” czy „interdyscyplinarny”? Każde z tych określeń jest dobre, choć te dwa ostatnie zdają się najlepiej oddawać koncept opisany w Scrum Guide. Nie chodzi bowiem tylko o zdolność wykonania konkretnej pracy, ale też zdolność do zorganizowania sobie niezbędnego wsparcia (gdy kompetencji brak) i uczenia się (by kompetencje podnosić).