https://leadership-center.pl/blog/zarzadzanie-projektami/Czy to coś nikomu niepotrzebne? Po co w ogóle wartości dla zespołu skoro my mówimy o biznesie? Czym jest Scrum Team? Kto tam faktycznie jest? Co to jest ten samoorganizujący się zespół? Dziś o tym porozmawiamy. Serdecznie zapraszam.
Kolejny wpis naszej serii o Scrumie, Scrum Guide w serii Agile, żeby popatrzeć pod spodem, jak można czytać różne fajne mądrości ukryte w materiałach. Skupimy się na wartościach Scruma i na Scrum Teamie.
Część osób się zastanawia “Ty, ale po co jakieś wartości, to jest jakieś pierdololo absolutne, czemu my o wartościach mówimy? Po co to komu?”. Ciężko jest bez wartości w pewnym momencie zarządzać i zachować spójność pracy zespołu albo pracy firmy.
Case Enronu, być może kojarzycie, była taka firma, m.in. energetyką się zajmowała. W pewnym momencie do starej ekipy dokooptowali nowych ludzi, którzy byli odpowiedzialni za sprzedaż. Oni nie mieli wartości. Tam główną wartością było wygenerowanie wyniku. Mniejszą wartością było to, żeby solidnie dowozić rzetelnie wyniki, które doprowadziły do sukcesu Enrona. Na koniec, ta firma upadła, bo po wyjęciu bezpieczników związanych z wartościami po prostu to przestało działać. Wartości o tyle są ważne, że są tutaj nakreślone, bo jeżeli wywalisz je stąd i weźmiesz tylko i wyłącznie część technik to wyłączasz bezpieczniki. Teraz to jest kompas, który pozwala nam orientować się w czasie problemów na to, jak rozwiązywać pewne sytuacje. W razie pożaru zbić szybkę i sięgnąć po wartości. Jak masz problem gdzie w Scrumie albo w zespole, to tym wartościom się przyjrzyj.
5 wartości, którym warto się przyjrzeć
Tych wartości jest 5: zaangażowanie, skupienie, otwartość, szacunek, odwaga. Różnie możemy definiować, różnie możemy temu się przyglądać, bo wartości trzeba redefiniować.
Zaangażowanie będzie znaczyło co innego w zależności od tego, jaki zespół nad tym pracuje, ale intuicyjnie całkiem nieźle jesteś w stanie wyłapać, co znaczy zaangażowanie, to znaczy skupienie, otwartość i tak dalej. Poza tym, że chcemy coś dowieść, co jest produktem, to jeszcze trzeba dużo pracować nad sobą.
Skupienie, skupienie wynikające z tego, że Scrum Teamy powinny być dedykowane jednemu produktowi, pracujemy na jednej rzeczy, skupiamy się, chcemy dobić do celu.
Otwartość na zmianę, na nowe rzeczy.
Szacunek, no bez tego ciężko się rozmawia tak naprawdę.
Odwaga. I teraz: członkowie Team Scrum Teamu mają odwagę robić to, co należy i mierzyć się z trudnymi problemami. No i tu jest podsumowanie tego, czy Scrum zadziała, czy nie. Jeżeli zastanawiasz się, czy Scrum zadziała u Ciebie w organizacji, czy nie zadziała u Ciebie w organizacji, to zacznij od tego punktu: czy ludzie będą mieli odwagę do tego, żeby zmierzyć się z trudnymi sytuacjami? No i zobacz, jak to wygląda w zespole. Jeżeli nie, no to po prostu trzeba nad tym popracować. Jest też fajne powiedzenie, że strach to reakcja, a odwaga to decyzja. I nie jest tak prosto, że nagle masz samych odważnych ludzi wokół siebie, gotowych po prostu postawić na szali wszystko.
O wartościach tyle, nie będę wnikał, to jest kluczowa rzecz, którą sobie zanotowałem. Natomiast popatrzmy przez Scrum Team, co tam się kryje pod spodem.
Scrum Team, co kryje się pod spodem
Podstawowym elementem Scruma jest niewielki zespół. Okej, no i tutaj jest ograniczenie. To nie znaczy, że to jest wada, nie znaczy, że to jest słaby punkt, to jest ograniczenie. Dlaczego? Bo przy większym zespole reguły się zmieniają: jeżeli masz więcej niż te 10 czy 12 osób wokół Scruma, inny proces działa, inaczej przepływa komunikacja i to sprawia, że ten model najprawdopodobniej nie zadziała. Czy to znaczy, że tylko takie zespoły można robić? Nie, niekoniecznie, ale jest pewna logika, którą np. armia, która od zawsze się mówi, że jest bez sensu, bo jest betonem, rozkminiła bardzo dawno. Zobaczcie, jak oni sobie organizują zespoły i dlaczego tak.
Scrum Team nie dzieli się na podzespoły, nie obowiązuje w nim hierarchia. “A, czyli zrezygnujmy z hierarchii całkiem?” Nie, to nie znaczy, że hierarchia nie istnieje równolegle. Praca w takim zespole Scrumowym, czy praca w zespole projektowym to jest wyzwanie dla świadomego przywództwa. Jeżeli oddelegowałeś swojego człowieka do zespołu i on tam pełni jakąś rolę, Ty jesteś jego przełożonym na bieżąco, nie wpierdzielasz się w to, co on tam robi. Hierarchia może istnieć, może funkcjonować, ale akurat w Scrum Teamie znika. To jest trochę jak komandosi: to, czy jesteś porucznikiem, sierżantem czy kapralem nie ma znaczenia, jesteście razem w zespole do organizacji zadań. To nie znaczy, że tamte funkcje zniknęły, te stopnie wojskowe, też istnieją i trzeba o tym pamiętać i nie ma co negować rzeczywistości. Negowanie rzeczywistości “o, teraz bez hierarchii będziemy działać” jest naiwne.
Ważne jest, że Scrum Team to spójna grupa profesjonalistów skupionych na pojedynczym celu, określonym jako cel produktu. Naprawdę inaczej się pracuje z kimś, kto jest zawodowcem i wie dokąd idzie, inaczej się działa z amatorami, wiecie o tym. I skupienie na celu. Moje ulubione pytania: “dlaczego?” i “po co?” one przez Scrum Guide się pojawiają dosyć często. Wiemy, po co tu jesteśmy, wiemy, dlaczego się tu znaleźliśmy, wiemy, co robimy, znamy swoją wartość i wiemy, gdzie chcemy dojść, nie? Warto sobie te pytania, które przed chwilą wrzuciłem sprawdzić, czy na nie odpowiadacie “tak” w zespole. Jak nie, no to być może to jest pewna bariera przed wdrażaniem Scrum.
Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności potrzebne do wytworzenia wartości co sprint. No i to jest kolejne ograniczenie. A co, jeśli masz zespół, który tego nie ma? Bo masz zespół, który w 100% nie jest w stanie być samowystarczalny, a często tak jest, że mamy tutaj ekipę, a polegamy na pracy ludzi z zewnątrz. No ale czy to oznacza, że całkiem nie zastosujemy Scruma? No nie zastosujemy Scruma. Czy można wyciągnąć pewne elementy stąd? Można, też na to spojrzymy. Natomiast tutaj też zwracam Waszą uwagę na te ograniczenia, żebyście wiedzieli po prostu, że one istnieją, one nie negują całkiem Scruma, ale są i tyle.
Scrum Teamy są zespołami samozarządzającymi się, co oznacza, że samodzielnie podejmują decyzje o tym, kto będzie wykonywał określone zadania, kiedy i jak. Dla mnie jest poważna różnica pomiędzy zespołem samozarządzającym, a bezhołowiem, bo nie oznacza, że np. zespół uzna “słuchajcie, będziemy mieć kogoś, kto rozdziela pracę”. Przykład, który ja często podaję pod kątem takiej pracy samozarządzającego się zespołu, to ekipy z CQB. Znowu wracamy do specjalsów i do military, gdzie na różne sposoby to można robić. Teoretycznie wchodzi ekipa i każdy decyduje, co, jak działa w budynku, ekipa komandosów stoi przed budynkiem, wchodzi do budynku i później sytuacja jest dosyć dynamiczna. Można to robić na różne sposoby, najczęściej jest tak, że prowadzi ta osoba, która jest pierwsza, ale czasem jest tak, że lepiej działa jak ktoś faktycznie pełni tą funkcję dowódcy i rozdziela zadania. Szkoły są różne z praktyki, które słyszałem, bazowa jest taka, że zespół samo się zarządza, ale może zdecydować “słuchajcie, niech on rozdziela zadania”. I tak samo zespół Scumowy może powiedzieć “dobra, nam pasuje tak, że ułożymy sobie w ten sposób, bo to jest najbardziej skuteczne, jesteś najbardziej doświadczony, Ty porozdzielaj zadania i przez pewien czas tak będziemy działać, nie musimy uczestniczyć we wszystkim”. Okej, spoko dlaczego by nie.
Scrum Team jest wystarczająco niewielki, zwykle składa się z 10 osób lub mniej. Jak wynika z naszego doświadczenia: mniejsze zespoły na ogół lepiej się komunikują i są bardziej produktywne. Ciekawe dlaczego? Dlaczego mniejsze zespoły mogą być bardziej produktywne? Jest taki ciekawy wzór, ja się uczyłem jak zdawałem egzamin na PMP: n razy n-1 dzielone przez dwa: to jest wzór na ilość kanałów komunikacyjnych w zespole. Jak n jest ilością ludzi w zespole, wpiszcie sobie, ile będzie kanałów komunikacyjnych przy 10 osobach, 15, 20, ile przy 3. Generalnie załamuje się komunikacja, załamują się zasady, inaczej trzeba pracować i overhead, związany z koordynacją zespołu, może być za duży. Jeżeli są te zespoły za duże: sugestia jest taka, żeby je przeorganizować w mniejsze zespoły, to też może działać. Różne opcje skalowania istnieją i tu trzeba się by było zastanowić.
Scrum Teamy powinny mieć wspólny cel produktu, product backlog oraz tego samego product ownera. I to jest ważna wskazówka do skalowania czegokolwiek, bo jak się zastanowicie trochę, to podobnie działa to, jak działamy na programie, czyli mamy zbiór projektów zmierzających do wspólnego końca, do wspólnego celu, no to musi być wspólny cel, mamy kogoś, kto decyduje. Firma działa podobnie, zespół działa podobnie, musi być ktoś, kto po prostu powie “dobra, tak, w tamtą stronę chcę iść”. Taka sama zasada działa w firmie, czyli mam misje, wizje, strategie, cele. Brzmi znajomo? To jest dokładnie to, to jest mega ciekawostka, bo Scrum i jego rozumienie, to jest takie dziwne połączenie mega demokracji absolutnej, samoorganizacji, z dosyć absolutnym podejściem kogoś, kto wie “tam chcemy pójść”, nie? Gdzie mamy product ownera. To jest trochę uproszczenie. Wiem, że za to stwierdzenie mi się oberwie, ale to jest tak, że musimy się dogadać, w którą stronę idziemy i musimy mieć z tego kogoś jednego albo kilka osób, które powiedzą “tam działam”.
Scrum Team ponosi odpowiedzialność. Scrum Team ponosi odpowiedzialność za wszystkie działania związane z produktem, obejmujące współpracę z interesariuszami, weryfikację, utrzymanie, obsługę, eksperymentowanie, badanie i rozwój oraz wszelkie inne działania, które mogą okazać się konieczne. Spory zakres ma ten biedny zespół, bo trzeba by ułożyć, połączyć produkt i podłączyć go do wszechświata i w zależności od kontekstu dobrać narzędzia i techniki i zwróćcie na to uwagę. To być może nie wybrzmiało wprost: to nie jest tylko “stukamy naszą robotę”, my musimy zorganizować sobie rzeczywistość tak, żebyśmy mogli nad tym działać i poza Scrumem będzie cała masa różnych technik, możliwości działania. Dlatego wracamy do tego, że potrzebujemy profesjonalistów, bo będzie łatwiej to ogarnąć. Roboty jest sporo i ona też zwraca uwagę, że to nie tylko sam produkt tworzymy, żeby wytworzyć ten produkt te wszystkie rzeczy pod spodem muszą zadziałać. Zespół ma odpowiednią strukturę oraz uprawnienia nadane mu przez organizację by móc zarządzać własną pracą. Tak samo, jak w projekcie, dokładnie tak to wygląda. Struktura taka, jak trzeba, ale bez hierarchii, bo jest za mało. W 10 osobach jaką hierarchię chcecie budować? I to jest uwaga bardzo ważna, bo w zarządzaniu projektami project manager też nie jest wyżej w hierarchii, to jest błąd: postrzeganie, że jest project manager, potem jest zespół, to jest jedna ekipa w różnych rolach. O tym też dosyć często mówiłem, bardzo spójne ze Scrumem, nie kłócimy się. I równomierne tempo pracy w sprintach korzystnie wpływa na skupienie i przewidywalność zespołu. To też jest ogromnie ważne, bo minimalizacja zmienności sprawia, że łatwiej jest sprawdzać, jak się dzieje.
Z zasad Agile w ogóle podejście to jest stabilne środowisko, które sprzyja dostarczaniu dobrych wyników, łatwiej jest zaobserwować, co nie działa, jeżeli tempo jest równomierne. Cały Scrum Team ponosi odpowiedzialność za wytworzenie wartościowego, użytecznego inkrementu. Sprint działa, gdy wszyscy czują, że to jest ich temat. Jeżeli ktoś się wypina, to działa tak sobie i znowu wracamy do wojska: jeżeli w wojsku ktoś skopie, to pompuje cały oddział, wszyscy robią pompki jak ktoś skopie. Dlaczego? Bo na polu walki jak skopie jedna osoba, to konsekwencje poniosą najprawdopodobniej inni. Pytanie: jak jest w biznesie? Jeżeli nie ma takiej sytuacji odnośnie poczucia odpowiedzialności, razem coś robimy, to po prostu nie zadziała i trzeba się temu przyjrzeć.
3 konkretne zakresy odpowiedzialności w ramach Scrum Teamu: deweloperów, product ownera oraz Scrum Mastera. To nie znaczy, że znikają odpowiedzialności funkcyjne, nadal istnieją menedżerowie, podwładni i tak dalej. I to nie oznacza, że nagle wszyscy stają się klonami, nagle są deweloperami, nie. To znaczy, że mamy różne umiejętności, te interdyscyplinarne, które sprawiły, że w tym zespole mamy pracować, żeby dowieść wartość i można podzielić to na deweloperów, testerów i tak dalej, tylko nie jest to esencją Scruma, żeby zrobić jakąś strukturę i przerzucać się gorącym kartoflem, tylko żeby wszyscy byli odpowiedzialni za to, co powstanie. To, co tutaj jest opisane, stara się doprowadzić do takiej sytuacji, w której nie ma przerzucania gorącego kartofla, że analityk dobrze przeanalizował, przewalił dalej i już go interesuje, później projektant zaprojektował, przerzuca do dewelopera, to go nie interesuje, deweloper przerzuca do testera, to go nie interesuje, co często potrafi mieć miejsce: wywaliłem za płot, nie moje. Chodzi o to, że cały zespół jest odpowiedzialny i jako deweloperzy dowozimy ten temat.
To tyle na dzisiaj tak, żeby utrzymać spójność całości. Dajcie znać w komentarzu, czy Wam się podobało i powodzenia z projektami. Samo się nie zrobi.
VIDEO