Zespół bez kierownika? – Herezja? Gwarancja chaosu? Niekoniecznie. Zwinne metodyki pracy (Agile) pomagają tworzyć dokładnie takie produkty, jakich oczekują klienci, a co więcej – na czas i w ramach założonego budżetu. Aby tak się stało, nie wystarczy zmienić hierarchię i przeprojektować procesy. Pozostaje znacznie trudniejsze zadanie – zrozumienie, po co w ogóle to robimy.
Niemal dokładnie 60 lat temu – w maju 1959 roku – magazyn „Scientific American” opisał historię australijskiego patrolu, który w 1946 roku dotarł do centralnych obszarów Nowej Gwinei. Na widok przybyszów miejscowa ludność wpadła w euforię, uznając, że wypełniło się proroctwo i oto zbliża się koniec świata. Z lin i bambusa zbudowała atrapy anten mających umożliwić otrzymanie nieznanych w tym rejonie świata dóbr. „Scientific American” odnotowuje, że był to tylko jeden z wielu zaobserwowanych przypadków praktykowania tzw. kultu cargo, utrwalonego też w popkulturze, np. w utworze Serge’a Gainsbourga „Cargo culte”. Legendarny francuski bard śpiewa w nim o „czarownikach przywołujących samoloty”, co faktycznie miało (i miewa do dziś, jak np. kult Johna Fruma w Republice Vanuatu) miejsce na niektórych wyspach Melanezji.
Co to jest kult cargo
Czym w ogóle jest kult cargo? Jego różne odmiany zaczęły rozwijać się w XIX wieku (chociaż szczyt ich popularności przypada na okres drugiej wojny światowej) na archipelagach Oceanu Spokojnego, gdzie przedstawiciele miejscowych kultur zauważyli, że pojawiający się od czasu do czasu przybysze z odległych rejonów świata budowali lądowiska dla samolotów czy nabrzeża dla statków, z których następnie wyładowywano nieznane przedmioty w rodzaju np. konserw z żywnością. Szybko zaczęli więc naśladować te zachowania w przekonaniu, że sama tylko obecność np. pasa startowego w magiczny sposób przywoła samoloty z jedzeniem czy zachodnią odzieżą. Zdaniem wyznawców kultu cargo, to bogowie kierowali samolotami, a latający nimi ludzie pełnią rolę pośredników. Zaimprowizowane lotniska czy nabrzeża pełniły natomiast rolę podobną do świątyń, mając stanowić narzędzie boskiej komunikacji.
Chociaż historia kultu cargo może wywoływać orientalistyczne i nieuzasadnione poczucie wyższości, podobne zachowania nie są wcale zarezerwowane dla mieszkańców Melanezji. Jak wskazują czasem trenerzy organizacyjnej zwinności, z łatwością można je dostrzec w firmach wdrażających u siebie zwinne metodyki, w tym np. Scrum. W kolejnych trzech akapitach omówimy w telegraficznym skrócie, na czym w ogóle polega Scrum. Jeśli znasz założenia tej metody pracy (dla uproszczenia będziemy tu używać tego określenia zamiennie z oficjalnie sugerowanym sformułowaniem „ramy postępowania”), spokojnie przewiń dalej. Jeśli po lekturze uznasz, że potrzebujesz dodatkowych wyjaśnień, przeczytaj ten tekst.
Co to jest Scrum: samoorganizujący się zespół
Scrum jest jedną z najpopularniejszych zwinnych metodyk pracy. Opiera się na założeniu, że nikt nie wie, jak wykonywać jakąś pracę lepiej od osoby, która faktycznie ją wykonuje. Ujmując sprawę prościej, wyobraźmy sobie Małgorzatę, która jest programistką. Jan jest dyrektorem zatrudniającej ją firmy. W ramach Scruma przyjmujemy, że to Małgorzata ma wiedzieć, jak napisać działającą aplikację, a Jan – chociaż jest przedstawicielem kadry zarządzającej – nie powinien wtrącać się w sposób, w jaki Małgorzata dostarczy produkt zamówiony przez klienta.
Dlatego zespoły realizujące jakieś zadanie organizują się same i również same decydują, czym w danej chwili się zajmą. Celem jest dostarczenie działającego produktu, a środki prowadzące do tego celu pozostają kwestią realizujących go osób. Jednocześnie dzięki serii regularnych inspekcji oraz cyklicznych poprawek do kolejnych wersji produktu (wprowadzanych w ramach tzw. sprintów) Scrum zapewnia, że finalny produkt będzie spełniał oczekiwania klienta, a także zostanie dostarczony w ramach założonego harmonogramu i budżetu. Ponadto uporządkowane wydarzenia wyznaczające rytm pracy nad produktem stanowią rodzaj bezpiecznika chroniącego zespół przed popadnięciem w chaos.
Jak działa Scrum
W ramach zespołu scrumowego przewidziane są tylko trzy równorzędne role: zespół deweloperski, właściciel produktu (który reprezentuje oczekiwania klienta i jest odpowiedzialny za zarządzanie listą cech i funkcji oczekiwanego produktu) oraz Scrum Master (który – podkreślmy na wstępie – nie jest kierownikiem ani jakimkolwiek innym przełożonym). W tym tekście skupimy się właśnie na tej ostatniej roli. Scrum nie jest metodyką w ścisłym znaczeniu tego słowa, co oznacza, że nie wskazuje dokładnie, co należy, a czego nie należy robić. Istnieje jednak pewien zestaw praktyk powszechnie realizowanych w różnych zespołach scrumowych.
Kult cargo w twojej firmie
Zadaniem Scrum Mastera jest dbanie, aby Scrum w organizacji był stosowany i rozumiany. Chodzi więc nie tylko o to, aby np. zespół scrumowy odbywał swoje cykliczne spotkania czy też aby deweloperzy pracowali w sprintach, ale również aby wszyscy rozumieli, po co w ogóle to robią. Scrum Master dba więc o to, aby Scrum nie sprowadzał się do bezrefleksyjnego przyklejania kolorowych karteczek z zadaniami do wykonania oraz odbywania porannych spotkań na stojąco (co jest częstą praktyką scrumowych zespołów). Innymi słowy, Scrum Master jest osobą pilnującą realizowania Scruma w sposób, w jaki został on opisany w oficjalnym przewodniku po tej metodzie pracy, ale także dbającą, aby wszystkie związane z nim praktyki nie zmieniły się w korporacyjną odmianę kultu cargo, w którym pracownicy uczestniczą w czymś, czego za grosz nie rozumieją.
Do najbardziej oczywistych obowiązków Scrum Mastera należy więc dopilnowywanie, aby odbywały się spotkania pozwalające na regularny przegląd postępu pracy, ale również usuwanie przeszkód mogących utrudniać zespołowi deweloperskiemu realizowanie zadania. W praktyce może to więc polegać na np. łagodzeniu konfliktów pomiędzy poszczególnymi członkami zespołu deweloperskiego czy też dopilnowywaniu, aby dobrze rozumieli oni powierzone im zadania.
W tym celu Scrum Master może zastosować cały szereg technik pozwalających zespołowi na oszacowanie złożoności danego zadania. Henrik Kniberg, znany praktyk Scruma, podpowiada, by zespół programistów ocenił ją za pomocą np. rozmiarów koszulek. Łatwe zadanie zostaje w ten sposób oznaczone literą S, trudne – L, a wyjątkowo skomplikowane – np. XXXL. Ta technika niesie z sobą dwie korzyści. Przede wszystkim pozwala z grubsza oszacować zakres pracy planowany w danym sprincie. Co również ważne, ta technika pozwala upewnić się, że wszyscy członkowie zespołu faktycznie wiedzą, co mają robić. Jeśli np. zauważymy, że poszczególni członkowie zespołu deweloperskiego przypisują danemu zadaniu kompletnie różną złożoność (dwie osoby oceniły zadanie jako S, dwie – jako XXL, a jedna – jako M), prawdopodobnie znaczy to, że nie wszyscy jednakowo rozumieją, co właściwie jest do zrobienia. Dzięki podobnym technikom planowania znacznie maleje ryzyko dostarczenia innego produktu niż zamówiony lub w ogóle niezrealizowania zadania. Scrum Master nie jest przełożonym zespołu deweloperskiego, ale raczej chodzącą skarbnicą podobnych metod, które pozwalają mu sprawnie wykonywać swoje zadania.
Jak wygląda praca Scrum Mastera?
Obowiązki Scrum Mastera nie ograniczają się jednak wyłącznie do wspierania zespołu deweloperskiego. Będąc odpowiedzialnym za właściwe stosowanie i rozumienie Scruma, Scrum Master jest w praktyce centralną osobą w tej metodzie pracy. Jego zadaniem jest równoległa praca z zespołem, właścicielem produktu i całym firmowym otoczeniem.
Scrum Master wspiera:
Właściciela produktu | Zespół deweloperski | Organizację |
zapewniając, że cele, zakres i domena produktowa są zrozumiałe dla wszystkich w zespole scrumowym, tak dobrze jak to tylko możliwe, | coachując zespół deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności, | przewodząc procesom wdrażania Scruma oraz prowadząc coaching osób w ten proces zaangażowanych, |
znajdując techniki efektywnego zarządzania backlogiem produktu, | pomagając zespołowi deweloperskiemu tworzyć produkty wysokiej wartości, | planując wykorzystanie Scruma wewnątrz organizacji, |
pomagając zespołowi scrumowemu zrozumieć potrzebę formułowania jasnych i zwięzłych elementów backlogu produktu, | usuwając przeszkody ograniczające postępy zespołu deweloperskiego, | wspierając pracowników i interesariuszy w zrozumieniu i stosowaniu Scruma oraz empirycznego podejścia do rozwoju produktu, |
w rozumieniu zasad planowania produktu w środowisku empirycznym, | wspomagając przebieg wydarzeń scrumowych, kiedy jest to konieczne lub kiedy jest o to proszony, | powodując zmiany prowadzące do zwiększania produktywności zespołu scrumowego, |
zapewniając, że właściciel produktu wie, jak porządkować backlog produktu, aby maksymalizować wartość, | coachując zespół deweloperski w zakresie sposobu wykonywania pracy w organizacjach, w których Scrum nie jest jeszcze w pełni przyjęty i rozumiany. | współpracując z innymi Scrum Masterami w celu zwiększenia efektywności wykorzystania Scruma w organizacji. |
w rozumieniu i praktykowaniu zwinności, wspomagając przebieg wydarzeń scrumowych, kiedy jest to konieczne lub kiedy jest o to proszony. |
Źródło: opracowanie własne na podstawie Scrum Guide
Jak widać, sprawne realizowanie obowiązków Scrum Mastera wymaga dużej czujności i zdolności wypatrywania potencjalnych zagrożeń z dużym wyprzedzeniem. W przypadku współpracy z właścicielem produktu może to oznaczać więc dbałość o to, aby umiał on odpowiednio określić, jakie funkcje oczekiwanego produktu są dla niego najważniejsze, dzięki czemu zespół deweloperski będzie mógł sprawniej zarządzać swoją pracą. W niektórych sytuacjach – zwłaszcza w przypadku dużych organizacji – lista wszystkich oczekiwanych funkcji produktu (backlog produktu) potrafi szybko się wydłużać. Zadaniem Scrum Mastera jest upewnienie się, że właściciel produktu wie, które z tych funkcji faktycznie są krytyczne dla powstania produktu (tzn. bez nich wytworzenie produktu nie ma sensu), które są ważne, a które po prostu stanowią ciekawy dodatek do całości.
Niekiedy najtrudniejszą częścią pracy Scrum Mastera może być praca z całą organizacją. A zwłaszcza z tymi jej pionami, w których Scrum nie został wdrożony. To Scrum Master musi więc zadbać o to, aby kontakty z osobami spoza zespołu scrumowego nie stanowiły dla jego członków przeszkody w pracy. Jeśli więc np. prezes lub inna ważna osoba w organizacji postanawia regularnie pokazywać się podczas porannego spotkania zespołu deweloperskiego (na potrzeby tego przykładu założyliśmy, że Daily Scrum odbywa się w godzinach porannych), to głowa Scrum Mastera w tym, aby obecność osoby spoza zespołu nie przeszkodziła w odbyciu spotkania w czasie nie dłuższym niż 15 minut oraz by nie utrudniała członkom zespołu deweloperskiego planowania pracy na nadchodzący dzień.
Bywają też wyzwania związane z postrzeganiem przez poszczególne osoby ich roli w firmie. Szczególnie w firmach, w których Scrum jest dopiero wdrażany, wielu osobom trudność może sprawiać zrozumienie, że nie mogą tak po prostu pójść do zespołu deweloperskiego i zlecić im szybkiego wykonania (mniej lub bardziej) drobnego zadania. To Scrum Master musi zadbać o to, aby odtąd podobne potrzeby zgłaszać właścicielowi produktu.
Gra w szachy
Różnorodność sytuacji, z jakimi przychodzi się mierzyć Scrum Masterowi, jest tak duża, że praktycznie nie da się odgórnie sporządzić kompletnej listy cech, jakimi powinien się on odznaczać. Niektóre – jak łatwość nawiązywania kontaktów – przydadzą mu się zapewne w każdej sytuacji, a inne mogą zależeć od konkretnych wyzwań. Scrum, stanowiący wyłącznie ogólne ramy postępowania, pozostawia znaczną swobodę dostosowywania konkretnych metod do konkretnych sytuacji. Twórcy Scruma – Jeff Sutherland i Ken Schwaber – porównują go do gry w szachy, w której określone są tylko możliwe ruchy poszczególnych figur, ale nikt nie każe graczowi wykonywać tego czy innego posunięcia w danej sytuacji. Trzymając się tej samej metafory, warto zauważyć, że gdy w organizacji zatrudniany jest nowy Scrum Master, musi on kontynuować partię, w której kilka pierwszych ruchów na szachownicy zostało już wykonanych: w firmie istnieją określone zależności, metody pracy, klienci czy osobiste relacje pomiędzy poszczególnymi pracownikami. To, w jaki sposób Scrum Master będzie kontynuować rozgrywkę, zależy tylko od jego wiedzy, umiejętności i wyczucia.
Mateusz Żurawik, redaktor „MIT Sloan Management Review Polska” i certyfikowany Scrum Master (PSM I)
