Jedną z cech Zespół Scrum jest to, że „(…) są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności potrzebne do wytwarzania wartości co Sprint”. 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 interdyscyplinarny. Czy to adekwatne tłumaczenie? Sprawdźmy.
Słownik Języka Polskiego wyjaśnia, że interdyscyplinarny to „dotyczący dwu lub więcej dyscyplin naukowych, korzystający z dorobku kilku nauk, złożony z naukowców reprezentujących różne gałęzie wiedzy”. Kojarzy się to z domeną badań naukowych bardziej niż z budowaniem produktów (np. oprogramowania), więc nie jest to idealny wybór językowy. Bez wątpienia jednak o wiele lepszy niż używany w poprzednich wersjach Scrum Guide dziwoląg: międzyfunkcjonalny.
Zaproponowana przez autorów tłumaczenia nazwa nie jest zresztą powszechnie używana i dużo częściej można usłyszeć o Zespołach wskroś-funkcjonalnych (aż zęby bolą, prawda?), 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 ze wszystkimi tymi tłumaczeniami jest taki, że są one próbą przełożenia terminu cross-functional dosłownie na polski albo stanowią jego kalkę brzmieniową. Tymczasem w polszczyźnie istnieje nieco zapomniany przymiotnik, który idealnie oddaje znaczenie oryginału: wszechstronny.
Zerknijmy raz jeszcze do Słownika Języka Polskiego. Wszechstronny to „mający rozległe zainteresowania i wiele umiejętności, rozwijający działalność w wielu dziedzinach, obejmujący rozległy zakres, uwzględniający wszystkie aspekty czegoś”. Pasuje idealnie, czyż nie?
Problem nieprzewidywalności
W każdym Sprincie Zespół dokonuje zmian w produkcie, kierując się podjętymi do realizacji elementami Backlogu Produktu. Ilość i charakter pracy, jakiej wymaga wykonanie każdej zmiany, właściwie za każdym razem jest inna. To oznacza, że poszczególne zmiany generują różne zapotrzebowanie na kompetencje, które są niezbędne do ukończenia pracy. To samo dotyczy zresztą realizowanych usprawnień, rozwiązywanych błędów, wsparcia użytkowników produktu i wszystkich innych czynności, jakie wykonuje Zespół w trakcie Sprintu.
Kompetencje wnoszą do Zespołu ludzie: Developerzy, Product Owner i Scrum Master. Nieustannie uczą się nowych rzeczy, a niektóre umiejętności tracą, jeśli rzadko z nich korzystają. Zmianie ulega też sam produkt, co pociąga za sobą konieczność dostosowania się Zespołu, który go wytwarza. A jakby tego wszystkiego było mało, dostępność ludzi bywa zmienna i mało przewidywalna, przez co równie zmienna i nieprzewidywalna staje się dostępność kompetencji.
Wszystkie te czynniki powodują, że czasami w Sprincie Zespół nie korzysta ze wszystkich posiadanych umiejętności, a innym razem doskwiera mu ich brak i potrzebuje pomocy z zewnątrz. Między innymi dlatego w trakcie Planowania Sprintu powstaje prognoza tego, co przyniesie rozpoczynająca się iteracja, ale nie da się zagwarantować, że coś na pewno uda się zrealizować.
Dobre dopasowanie kompetencji
Czy dałoby się na potrzeby każdej iteracji dopasowywać skład Zespołu tak, by idealnie pasował do charakteru pracy, którą trzeba będzie wykonać? Niektórzy są przekonani, że to klucz do wysokiej efektywności Zespołów i ich skuteczności, ale to mrzonki. Dlaczego?
Ze względu na niestabilną złożoność środowiska, w którym funkcjonuje Zespół (wspomnianą wcześniej nieprzewidywalną zmienność, z jaką się zmaga), w zasadzie nierealne jest określenie z góry, jakie dokładnie kompetencje będą potrzebne. Nie da się zagwarantować, że w trakcie Sprintu nie ujawni się konieczność wykonania niezaplanowanych prac. Nie da się również zagwarantować, że wszyscy ludzie dostępni będą przez cały czas.
To dopasowywanie składu Zespołu do charakteru wykonywanych prac nie mogłoby więc ograniczyć się do samego Planowania Sprintu, ale musiałoby potencjalnie następować za każdym razem, gdy adaptowane są plany już w trakcie iteracji. Pomijając ogrom problemów i negatywnych skutków, jakie mogłoby to spowodować, ten sposób działania właściwie uniemożliwiłby zaplanowanie Sprintów. Do już istniejących niewiadomych dodawana byłaby bowiem kolejna, jaką jest brak pewności, kto właściwie uczestniczył będzie w iteracji.
Nieustanne przeformowanie Zespołu skutecznie utrudni (a być może uniemożliwi) zbudowanie relacji między tworzącymi go osobami. Funkcjonując w takim Zespole, ludzie 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 „świetnym pomysłem” na optymalne wykorzystanie kompetencji jest takie układanie Backlogu Produktu, by dopasować go do dostępnych w Zespole kompetencji i jednocześnie w równy sposób obciążać osoby pracą adekwatną do ich umiejętności. To podejście upiornie głupie, bo stoi w sprzeczności z podstawowym celem, jakim jest uzyskanie wartościowego produktu.
Żonglerka Backlogiem w ten sposób (bo ciężko to nazwać zarządzaniem) prowadziłaby do budowania nie tego, co potrzebne i wartościowe, ale tego, co Zespół najlepiej potrafi aktualnie wytworzyć. Poza tym problem zmienności i nieprzewidywalności nie zniknie, więc nieuchronnie w trakcie Sprintów ujawniać się będzie nieplanowana praca, nierzadko bardzo pilna. Co wtedy? Zespól złamie zasady, że każdy robi to, co potrafi najlepiej i wszyscy mają być równo obciążeni pracą, czy też odłoży niezbędne czynności „na później”?
Pełna wymienność lub zastępowalność
Wydawać by się mogło, że jedynym sposobem zapewnienia, że Zespół na pewno poradzi sobie z elementami Backlogu Produktu, jest zatrudnienie ludzi umieją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 prawie, a nie zawsze, wyjaśniam za moment.
Dla wielu osób pełna wzajemna zastępowalność Developerów (nazywana też pełną wymiennością) jest synonimem wszechstronności. 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, by to osiągnąć, 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 wytworzenia wartości. W przypadku Developerów lista niezbędnych umiejętności wynikać będzie z zapisów Definicji Ukończenia oraz z 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, poza tym mowa o Zespole jako całości. Może więc o wszechstronności Zespołu mówić można, gdy Product Owner, Scrum Master i wszyscy Developerzy (również nieprogramujący twórcy oprogramowania, jeśli to ono jest produktem) w sumie mają dość wiedzy i kompetencji, by wytworzyć Przyrost? Cóż, niekoniecznie.
Liczy się nie sam fakt posiadania umiejętności, ale też sposób, w jaki są one wykorzystywane. Podobnie jak Developerzy, którzy potrafią wykonać każdy rodzaj pracy, nie wystarczą do osiągnięcia pełnej ich wymienności, 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
Wspólna praca nad produktem dowodzi korzystania ze wszechstronności (i tym samym jej istnienia). Jeśli w Zespole 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 najniższego 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ą minikaskady, 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ę jedynie od czasu do czasu, gdy 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. To jednak 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 dostępności osoby umiejącej zrobić coś pilnego, wcześniej nieplanowanego. Jedynym sposobem na poradzenie sobie wtedy jest podjęcie przez Developerów działań, które nie leżą w zakresie ich podstawowych (silnie wykształconych) kompetencji.
Skrajnym przykładem braku przenikania się kompetencji są wspomniane już silosy, które Zespół często odziedziczył po sposobie funkcjonowania organizacji w przeszłości (zanim sięgnięto po metody zwinne). 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 się „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 zmian w produkcie przerzucana jest od osoby do osoby w zależności od tego, co jest akurat do zrobienia. To również minikaskada wewnątrz Sprintu.
Minimum, jakiego wymaga Scrum, by mówić o wszechstronności Zespołu, to T-shaped Developers – Developerzy wyspecjalizowani w jakiejś dziedzinie (symbolizowanej przez pionową kreskę litery T), ale zdolni sięgać poza nią (czego symbolem jest górna pozioma część 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 Π. Daszek litery Π symbolizuje zarówno łączenie dwóch kompetencji, jak i sięganie poza nie.
Wszechstronność a samodzielność
Do tej pory pisałem o dwóch nieporozumieniach: utożsamiania wszechstronności z pełną wymiennością Developerów oraz przekonaniu, że wszechstronność to zwykła suma kompetencji. Pora zmierzyć się z nieporozumieniem trzecim. Przypomnę cytat ze Scrum Guide mówiący, że Zespoły są wszechstronne, jeśli „(…) ich członkowie mają wszystkie umiejętności potrzebne do wytwarzania wartości co Sprint”.
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. Przecież w Scrumie tylko Developerzy (w domyśle: z Zespołu, który rozwija produkt) wytwarzają Przyrost, więc wydaje się oczywiste, że tylko oni pracować powinni nad jego wytworzeniem. Zastanówmy się, jakie byłyby konsekwencje spełnienia tego postulatu w sytuacji, gdy w Zespole ujawni się brak wymaganych kompetencji.
Niezbędne byłoby zatrzymanie rozwoju produktu do momentu, gdy Zespół pozyska nowe umiejętności. Czy oznaczałoby to zawieszenie na kołku Scruma na jakiś czas i przeprowadzenie szkoleń? Czy też wciąż praca odbywałaby się w Sprintach, mimo że ich wynikiem nie byłby ukończony i nadający się do użycia produkt? 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 Zespołu po każdej takiej zmianie składu, ale niewykluczone, że warto byłoby ją płacić. Tyle tylko, że Zespół powoli rozrastałby się coraz bardziej i w końcu pogrążyłby się w chaosie organizacyjnym.
A może takie rozrośnięcie się Zespołu wcale nie byłoby złe, gdyby następowałoby jedynie na jakiś czas, po którym byłbym on redukowany do składu takiego, który będzie miał kompetencje wystarczające do realizacji kolejnych zmian w produkcie?
Uważny czytelnik zauważy, że wracamy okrężną drogą do nierozsądnego pomysłu, by dopasowywać skład Zespołu do aktualnie wykonywanych prac. Nie do końca wiadomo, jakie kompetencje okażą się 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 i pozwalać na proste rozwiązywanie problemów. W tym przypadku, skoro Zespół natrafił na brak kompetencyjny, powinien uzyskać pomoc z zewnątrz. Nawet jeśli czyni go to z pozoru niesamodzielnym (o tym dwa słowa za moment). Jeśli sytuacja będzie 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 zasadami Scruma? Oczywiście, że tak. Postulat posiadania wszystkich umiejętności obejmuje też zdolność do pozyskiwania pomocy z zewnątrz i uczenia się od ekspertów. Jeśli Developerzy potrafią zrobić prawie wszystko sami, a w niektórych obszarach wspierają się osobami spoza Zespołu, dowodzi to ich umiejętności wytwarzania Przyrostu. A tym samym i wszechstronności.
Wsparcie zewnętrznych ekspertów pozwala na radzenie sobie 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ść, a 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ść samozarządzania
Korzystanie z pomocy ekspertów (albo nawet innego Zespołu) nie jest sprzeczne z postulatem wszechstronności Zespołu, o ile organizatorem tego wsparcia są sami jego członkowie. 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 kierownictwa (bo pomoc eksperta może kosztować), Zespół zawnioskuje o zgodę i będzie miał 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 szeroko rozumianego kierownictwa organizacji, Zespół nie jest ani w pełni samozarządzający, ani wszechstronny.
Prywatnie uważam, że nie sposób rozdzielić tych dwóch cech Zespołu od siebie. Niezdolność do samozarządzania choćby w minimalnym zakresie w praktyce nie daje szans na wszechstronność. Umiejętność samozarządzania jest jedyną kompetencją, której nie da się uzyskać w formie zewnętrznego wsparcia, bo takie z definicji byłoby zaprzeczeniem tej idei.
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).
Tu drobna uwaga: jeśli to Scrum Master zawsze organizuje pomoc dla swojego Zespołu, to niekoniecznie dobrze świadczy o wszechstronności. Owszem, Scrum Master jest częścią Zespołu, ale nie oznacza to, że powinien zastępować Developerów lub Product Ownera w ich pracy, o ile nie jest to absolutnie konieczne. W szczególności powinien nauczyć ludzi w Zespole, w jaki sposób poszukiwać pomocy, jeśli jest ona niezbędna.
Charakter luk kompetencyjnych
Drugą krytyczną kwestią przy dyskusji o samodzielności jest rozmiar i charakter luk kompetencyjnych. Zespół musi być w stanie poradzić sobie z większością pracy, jaką trzeba wykonać, aby produkt zbudować (pracę tę wykonują głównie Developerzy, ale przecież Product Owner i Scrum Master też biorą udział w Sprincie). Inaczej mówiąc, wsparcie musi mieć charakter incydentalny.
Przykładowo, jeśli czasami (przy niektórych zmianach w produkcie, co dwa lub trzy Sprinty) potrzebujemy wsparcia prawnika, to brak znajomości przepisów i umiejętności pisania urzędowych pism 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 zbudować Przyrost.
Ciągłe doskonalenie
Na początku, tuż po powołaniu do istnienia, wiele Zespołów ma ograniczone zdolności korzystania z kompetencji wniesionych przez poszczególne osoby. Muszą nauczyć się samozarządzania, co wymaga zarówno czasu, jak i motywacji. Przydaje się też odwaga i otwartość, żeby zrobić coś inaczej, niż do tej pory, albo by podjąć się pracy nad zagadnieniami niekoniecznie ze swojej dziedziny.
Wszechstronność to zatem cecha Zespołu wynikająca z bieżących uwarunkowań i tego, jak na te uwarunkowania reagują poszczególne osoby. Większość Zespołów staje się coraz bardziej wszechstronna, a towarzyszy temu rosnąca umiejętność samozarządzania i zwiększająca się samodzielność. Lub też rosnące zdolności samozarządzania i samodzielność owocują wzrostem wszechstronności – sądzę, że oba stwierdzenia są prawdziwe.
Nie tylko Developerzy
Na koniec uwaga związana ze zmianami, jakie wprowadzone zostały do definicji Scruma w 2020. Usunięty został wtedy Zespół Developerski, który wcześniej stanowił część Zespołu Scrum. Teraz mowa jest o jednym Zespole, który stanowią Developerzy, Product Owner oraz Scrum Master.
Wszechstronność i samozarządzanie związane jest nie tylko z pracą Developerów (choć nie ma co ukrywać, że to ich kompetencje developerskie mają kluczowe znaczenie dla możliwości wytworzenia Przyrostu). Cały Zespół Scrum musi być wszechstronny i samozarządzający.
Nie oznacza to oczywiście, że Scrum Master czy Product Owner muszą zabrać się za development, bo wtedy staliby się jednocześnie Developerami. Natomiast muszą mieć umiejętności niezbędne do wywiązania się z odpowiedzialności, jaką na siebie wzięli.
Niekompetencja Product Ownera lub Scrum Mastera ograniczy możliwości Zespołu i uzależni go od osób z zewnątrz i jest takim samym objawem braku wszechstronności jak brak umiejętności technicznych u Developerów.
Brak decyzyjności Product Ownera (który jedynie ogłasza decyzje podjęte przez kogoś innego) lub dyrektywna postawa Scrum Mastera (który zarządza Zespołem niczym kierownik) jest tak samo szkodliwa dla zdolności samozarządzania, jak kurczowe trzymanie się przez Developerów „swoich” obszarów kompetencyjnych.
Działania Product Ownera i Scrum Mastera są pracą w Sprincie tak samo, jak jest nią praca Developerów, a za wykreowanie wartości i dostarczenie jej interesariuszom odpowiada cały Zespół. Nie wolno o tym zapominać, gdy dyskutuje się o wszechstronności i samozarządzaniu.