Przez 8 lat mojego doświadczenia zawodowego w zespołach programistycznych na temat Scruma zdążyłem usłyszeć już wszystko, co najgorsze. Przez dokładnie te same 8 lat każdy zespół, w którym pracowałem, dryfował samorzutnie w stronę Scruma. Czyżby syndrom sztokholmski? A może Scrum jest budowany na filarach z żelek?
Inspiracją do refleksji nad Scrumem było zadanie na studiach, którym było napisanie eseju na temat książki „Pięć dysfunkcji pracy zespołowej. Opowieść o przywództwie” P. Lencioniego z 2016-go roku (polecam, fajnie się czyta chociaż jest w niej mało mięsa – typowo amerykański styl książek o przywództwie). Odkrywając kolejne problemy zespołu książkowej Kathryn łączyły mi się w głowie rzeczy, które mają w zwyczaju w Scrumie nie działać z dysfunkcjami zespołów, na których ten Scrum był budowany.
Brak zaufania / niezależność
Wyobraźmy sobie Martina, który jest tą osobą w zespole, która wywłaszcza najwięcej czasu na daily. Dzięki niemu te krótkie spotkania synchronizacyjne wykraczają poza swojego timeboxa, a nawet są tworzone followupy i followupy followupów. Martin ma tendencję również do szczegółowego opisywania swoich czynności, które zajęły mu cały dzień.
Można rzec, że przeciwieństwem Martina jest Patrick. Patrick nie potrzebuje tego spotkania – 15 minut tego spotkania traktuje jako okazję do regeneracyjnej drzemki.
Czasami nie osiągamy celów
- Martin na spotkaniach owszem, opowiadał o swoich zadaniach, ale mimo wszystko nie dotyczyły one celów zespołu, tylko rzeczy nieskładających się na cel
- Patrick nie wspomniał, że od trzech dni czeka na taska
Życie w korporacyjnej dżungli sprawia wrażenie, że każde przyznanie się do niepowodzenia jest okazaniem słabości. W wyniku tego pokazujemy swoją niezależność poprzez apologie uzasadniające brak związku naszej pracy z celem zespołu, albo przemilczamy nasze problemy, które uniemożliwiają nam pracę.
Brak zaufania do zespołu sprawia, że potencjalne ryzyka projektu są ukrywane i zamiatane pod dywan.
Brak dbałości o wyniki / status i ego
Dorian jest managerem projektu. W kontakcie z klientem zawsze wygrywa swoją postawą can-do. Nie ma rzeczy niewykonalnych (o ile klient za to zapłaci).
Team Product Owner. Jego specjalnością jest praca pod presją i rozkładanie jej po wszystkich członkach zespołu – jeżeli tylko da się zrobić coś w terminie oczekiwanym przez klienta, to zostanie to odpowiednio zaplanowane. Albo dojdzie do zmiany planu. Entuzjasta pair programmingu i przekładania story-pointów na man-daye.
Twarz Scruma, czyli Scrum Master. Na swoje stanowisko nie trafił z przypadku. Swoją karierę zaczynał jako QA i w ramach awansu zawodowego po kursie na Scrum Mastera przyjął rolę przywódcy zespołu scrumowego. Jego podłoże techniczne w zespole inżynierów pozwala mu na lepszą pomoc zespołowi.
Zespół nie jest od realizacji celów jednostki
- Dorian na spotkaniach z zarządem za wszelką cenę próbuje pokazać swoje kompetencje kosztem zespołu, który nie ma zasobów lub możliwości wykonania wyznaczonych przez niego zadań
- Nick pominął kurs asertywności i nie potrafi przekazać klientowi, że rzeczy zajmują czas i zmusza zespół do przyjęcia sztywnego planu nieoddającego jego możliwości
- David ze swoją naturą skupioną wokół jakości oprogramowania będzie kierował zasoby zespołu w stronę poprawy jakości i kładzenia nacisku na testowanie pomimo, że zespół realizuje małą część swoich celów o ile w ogóle
Każdy z nas potrzebuje sukcesu i stara się w jakiś sposób podnieść swój status albo nasycić swoje ego. W zespole jest to możliwe, o ile nie zaniedbujemy w ten sposób jego celów. Jeżeli obieca się klientowi nową funkcję i zespół dowiezie to bez pozostałych funkcjonalności nie staniemy się przez to dobrym managerem złego zespołu.
Skupienie na realizacji indywidualnych celów pracą całego zespołu prowadzi do braku dbałości o wyniki.
Obawa przed konfliktem / sztuczna harmonia
Bezkonfliktowy na każdym spotkaniu, daje każdemu dojść do głosu. Czasami widzi problemy w projekcie, ale nie zabiera głosu wtedy, kiedy zadanie wychodzi poza jego zakres obowiązków. Poza tym jeżeli zadanie dotyczy kogoś innego – czemu ma się wtrącać?
Podstawą pracy zespołowej jest komunikacja
- Bart omawiając przyszłe zadania przemilczał kilka ważnych kwestii, które uniemożliwią ich wykonanie, żeby nie musiał argumentować swoich racji
Sztuczna harmonia w zespole jest zazwyczaj atutem dla osób, które czują potrzebę zaistnienia w zespole. W tej sytuacji osoby, które lubią sobie dużo pogadać nie są skrępowane żadną rzeczową dyskusją.
Jednak obawa przed konfliktem powoduje, że korzyść płynąca z posiadania wielu specjalistów na spotkaniu nie istnieje. Aby decyzje podejmowane w zespole były jak najlepsze trzeba być zawsze gotowym na kreatywny konflikt.
Brak zaangażowania / niepewność
To są jego pierwsze tygodnie w projekcie. Podczas spotkań ufa doświadczeniu zespołu, a sam nie dopytuje na nich o szczegóły. W każdej chwili może liczyć na pomoc zespołu, gdyby miał z czymś problem.
Świeże spojrzenie też jest ważne
- Jimmy niepewny swojego gruntu nie angażuje się w dyskusje zespołowe przez co zespół, który już przywykł do projektu, nie ma komunikatu zwrotnego o tym jak ten projekt wygląda dla osób z zewnątrz
Przytłaczające doświadczenie ludzi w zespole może powodować zrozumiałą niepewność u nowej osoby. Pojawiają się u niej pytania, zastanawiają się, czy omawiane zespołowe „oczywiste oczywistości” powinny być dla niej także oczywistością i nie chce okazać niekompetencji gradem pytań „Dlaczego coś?”.
Kwestionowanie niektórych decyzje zespołowych przez świeżą osobę pozwala na powrót do niektórych decyzji i ocenę ich zasadności i aktualności. Brak zaangażowania ze strony osoby, która dopiero wchodzi w projekt, sprzyja zwiększeniu długu projektowego.
Unikanie odpowiedzialności / niskie standardy
Jest sumienny, udaje mu się zawsze dowieźć rzeczy, do których dowiezienia się zadeklarował. Nawet wtedy, kiedy zespołowi nie udaje się osiągnąć celu może powiedzieć, że przynajmniej zrobił swoją część roboty.
Klient widzi ogół, a nie szczegół
- Robert wykonał wszystkie swoje zadania jeszcze w pierwszym tygodniu sprintu, ale nie zaangażował się we wsparcie pozostałych, od których pracy zależała widoczność jego pracy
Odpowiedzialność zespołu spoczywa na wszystkich jego członkach, ale dla niektórych to też okazja do uniknięcia odpowiedzialności właśnie pod pretekstem… odpowiedzialności całego zespołu.
Przerzucanie odpowiedzialności za porażkę zespołu częściej wpływa na niskie standardy produktu, niż na pozbycie się problemu.
Problemy dla Scruma
Pięć dysfunkcji pracy zespołowej (w Scrumie) naprowadziły mnie na trzy problemy, nad którymi warto się pochylić.
Samoocena
- Łatwo zauważyć przytoczone dysfunkcje u naszego Scrum Mastera, kolegi/koleżanki z zespołu czy przerysowanej postaci, którą wymyśliłem
- Trudno jest zauważyć takie dysfunkcyjne objawy u siebie
- Bardzo chcielibyśmy nie być którąkolwiek z tych postaci, ale każdy z nas czasami jest którąś z tych postaci
Refleksja nad naszymi zdolnościami w pracy zespołowej czasami może być trudna, bo wszyscy chcemy mieć o sobie jak najlepsze zdanie. Warto poza tym zwiększać w zespole otwartość, aby przekazywać sobie takie komunikaty sprawniej.
Nie nasze środowisko i nie nasze czasy
- Manifest Agile powstał w 2001 roku
- Jego autorami są eksperci w swojej dziedzinie
- Rzeczy oczywiste dla autorów Agile czy Scruma nie są oczywiste dla nas, końcowych użytkowników
Nieznajomość Scruma szkodzi i zdecydowanie korzystanie z niego nie jest tak proste jak przeczytanie jednego poradnika. Nie skłaniałbym się tutaj od razu do wysyłania wszystkich na certyfikację Scruma, ale warto w zespole okresowo przypominać sobie dlaczego w określony sposób rzeczy się dzieją. Dobry Scrum Master również powinien wyczuwać momenty, w których zespół nie potrafi korzystać z tej metodyki.
Nieżyciowość
- Klient zawsze będzie chciał funkcjonalności tu i teraz
- Rzeczywista uśredniona produktywność programisty to 2h 57m dziennie
- Programista zazwyczaj jest bezużyteczny 15 minut przed i po każdym spotkaniu
Agile i Scrum mają swoje wymagania, które nie zawsze idą na rękę klientowi albo zespołowi, dlatego z biegiem czasu do tych słów zaczęto doczepiać słowo „Framework” tłumacząc, że nie są to gotowe rozwiązania, ale swojego rodzaju szablon. Wychowanie sobie klienta, który by respektował długości sprintów i nierealność niektórych pomysłów, wydaje się małomożliwe w większości przypadków. Tutaj bardzo ważna jest rozwaga ile Scruma w Scrumie zostawimy idąc na kompromis i jak możemy się zaadaptować do sytuacji.
Kubeł zimnej wody
Scrum jest narzędziem, a nie rozwiązaniem. Wiele zależy od tego, jak zespoły korzystają ze Scruma, jak sobie go zaimplementują do swoich możliwości i potrzeb. Metodyka pracy powinna wychodzić z zespołu i specyfiki projektu, a nie widzimisię managera. Sukces tej metodyki pochodzi od kompetencji zespołu do jej stosowania, a realizowanie Scruma na 200% nie jest dla zespołu ani celem per se ani wykonalne de facto.
Powinniśmy dążyć do dobrze działającego Scrum-isha zamiast skupiać się na w 100% czystym Scrumie.
Użyta grafika:
- Główna: Work illustrations by Storyset
- Zdjęcia twarzy osób zostały wygenerowane za pomocą sztucznej inteligencji – przedstawiają osoby nieistniejące.
Dodaj komentarz