Rozumowanie, które do tego prowadzi jest następujące: „deweloperzy nie muszą się interesować procesem, Scrumem, organizacją pracy. To my, Scrum Masterzy i Agile Coache jesteśmy od tego! My im to zorganizujemy, poukładamy, a oni będą się mogli skupić na tym, w czym są dobrzy, na wykonywaniu pracy – kodowaniu”. Postawa taka jest dla mnie antytezą tego, czym agile jest – a może raczej miał być.

Uważam tak, bo istotnym elementem idei agile w ogólności, a Scruma w szczególności, jest założenie, żeby to ludzie wykonujący pracę sami ją sobie organizowali. W Scrumie organizacja narzuca być może strukturę, w tym właśnie Scrum, narzuca podział na zespoły (choć lepiej jeśli pozwoli się ludziom, aby sami się do nich przypisali lub choćby o tym współdecydowali), ale o całej reszcie ma decydować zespół. Ba! Cała następna fala nowatorskich metod zarządzania typu Holakracja idzie jeszcze dalej: pracownicy sami ustalają również struktury oraz podział odpowiedzialności i obowiązków, który jest przez nich dynamicznie dostosowywany zależnie od potrzeb.

Skąd ta idea się wzięła? Choćby z obserwacji, że to ludzie bezpośrednio wykonujący pracę mają najwięcej wiedzy na temat tego jak ona jest wykonywana, a zatem są w najlepszej pozycji do tego, żeby ją usprawnić, poprawić. A także z obserwacji, że jeśli ludzie mają wpływ na to jak pracują, to są bardziej zaangażowani w pracę – co powoduje, że jeszcze bardziej im zależy, żeby to dobrze działało. I tak mamy w organizacji – a przynajmniej w zespole – pozytywne sprzężenie zwrotne, które podnosi i jakość pracy, i zaangażowanie. Do tego właśnie służą w Scrumie retrospekcje – robiliśmy cały sprint, teraz pomyślmy jak tę pracę robiliśmy, abyśmy w przyszłości robili ją jeszcze lepiej, ponieważ nam na tym zależy.

Zresztą, Scrum wziął się stąd, że zaangażowani deweloperzy i współpracujący z nimi produktowcy oraz menedżerowie kombinowali, jak pracować lepiej. W skrócie, Scrum to jest coś co zespół robi, żeby lepiej działać (o czym pisałem szerzej w przywołanym już artykule, „Kryzys agile”, CRN Polska nr 12/2020). Mentalność „my wam to poustawiamy, nie musicie tego robić, wy macie kopać” jest z tym sprzeczna, wręcz szkodliwa. Obniża zaangażowanie, promuje postawę klasy „ja tu robię X od-do, a resztę mam w… głębokim poważaniu” albo „niech menedżer, to znaczy Scrum Master się tym zajmie, to nie moja sprawa”. To jest stawianie Scruma na głowie, powrót do biernych deweloperów zarządzanych przez menedżerów, którzy – jako ci starsi i mądrzejsi – poustawiają im świat. Czyli powrót dokładnie do tego, czemu przeciwstawił się cały ruch agile. Innymi słowy, takie myślenie to prosta droga do tego, żeby Scrum nie był czymś, co robią deweloperzy, aby lepiej działać, ale stał się czymś, co inni robią deweloperom. A to, jak już wiemy, nie działa. Właśnie między innymi dlatego, żeby walczyć z takimi pomysłami, w najnowszym „Scrum Guide” nie ma już ról. Są odpowiedzialności w zespole (Scrum Team). Cały zespół odpowiada za to, czy praca jest dobrze zorganizowana i czy jest wartościowa.

Jeśli to czytasz, a masz odpowiedzialność Scrum Mastera, apeluję: nie stawiaj Scruma na głowie! Nie próbuj we wszystkim zespołu wyręczyć. Pewnie, jeśli zespół jest mało doświadczony, w ogóle świeży to układania potrzebuje więcej. Ale z czasem ma być go coraz mniej. Nigdy nie stawiaj się ponad zespołem, nie myśl, że TY im poukładasz, a oni nie muszą o tym myśleć. Przeciwnie – powinni o tym myśleć. Jako SM dąż do tego, żeby każdy członek zespołu czuł się odpowiedzialny nie tylko za swoje od-do, ale za całość: całość tego, jaki produkt jest, jak wygląda zespół, jak wygląda organizacja, co można poprawić. Jeśli będzie inaczej, Twój zespół odrzuci Scruma, traktując go jako kolejny wymysł menedżerów wciskany im na siłę. A nie o to przecież chodzi.

Andy Brandt Andy Brandt  

jest założycielem i senior consultantem firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.