Zuchmistrzowski sprint: sprawniejsza kadra
Autor: Kacper Borkowski
Dziś nie będzie o bieganiu. Więc o jakim sprincie mowa? Już tłumaczę.
Interesuję się sposobami ułatwiania i przyspieszania pracy swojej i moich zespołów, czytam o nich i stosuję różne rozwiązania. Na początku zeszłego roku, zatem jeszcze przed pandemią przeczytałem książkę „SCRUM. Czyli jak robić dwa razy więcej dwa razy szybciej” Jeffa Sutherlanda. Wielu z Was zapewne słyszało o metodzie pracy zwanej „Scrum”. Nie jestem znawcą w tym temacie, a najpewniej każdy początkujący programista wie więcej ode mnie. Jednakże cały temat zainteresował mnie do tego stopnia, że postanowiłem wykorzystać elementy metody Scrum w pracy swojej kadry, gdy jeszcze byłem wodzem gromady zuchów.
Czym jest Scrum?
Posłużę się definicją z Wikipedii:
„Scrum – iteracyjne i przyrostowe ramy postępowania (ang. framework) zgodne ze Scrum Guide[1]. Może mieć zastosowanie w realizacji projektów w oparciu o metodyki zwinne zgodne z manifestem Agile.
Rozwój produktu podzielony jest na trwające maksymalnie jeden miesiąc iteracje, zwane sprintami. Po każdym sprincie zespół powinien być w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny.”
[1] https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf – tutaj źródło, z którego czerpała Wikipedia, zainteresowanych zachęcam do zapoznania sięW skrócie: zespół planuje na dany okres (sprint) określoną ilość zadań. Każde zadanie oceniane jest pod kątem stopnia trudności, aby dostosować ich liczbę do długości sprintu, oraz żeby każdy sprint był na podobnym poziomie trudności (z czasem można ten poziom zwiększać). Na koniec każdego sprintu zespół powinien mieć gotowy „produkt”. Każdy sprint jest podsumowywany, wyciągane są wnioski, które uwzględnia się w planowaniu kolejnego sprintu (powtarzanie).
Ta metoda pracy może usprawnić nie tylko przygotowanie i realizację programu informatycznego lub projektu aplikacji mobilnej. Jak czytamy w książce, przy użyciu Scruma udało się zmienić sposób interakcji farmaceutów z pacjentami, wpłynąć na zmniejszenie ubóstwa w krajach Trzeciego Świata, a nawet pomóc ludziom planować wesela i wywiązywać się z weekendowych obowiązków. Dlaczego więc nie spróbować w kadrze gromady?
Scrum w gromadzie zuchów
Książkę Jeffa Sutherlanda przeczytałem na początku zeszłego roku, czyli tuż przed początkiem lockdownu. Był to idealny moment, ponieważ, jak wiemy, cała ta sytuacja zmusiła drużynowych do zmiany sposobu pracy. Na pewno niełatwo mieli zuchmistrzowie – najmłodsza grupa wiekowa, jaką są zuchy, jest wymagająca na żywo, a co dopiero przed komputerem. Jak zaciekawić ich zdalną zbiórką? Jak obejść problem, jakim jest nieumiejętność (lub niska umiejętność) obsługi komputera? Byłem w tym czasie wodzem 8 Szczecińskiej Gromady Zuchów „Rycerze Iskry” im. Zawiszaków, a mnie i mojej kadrze wyżej opisany problem wydał się ekstremalnie trudny. Sięgnęliśmy więc po Scruma.
Nasza kadra liczyła wtedy 4 osoby: wódz, dwóch przybocznych i obserwator – idealnie na Scrum Team. Tuż po ogłoszeniu lockdownu, podczas odprawy zrobiliśmy burzę mózgów: Jak uatrakcyjnić zbiórki online, które planowaliśmy robić na discordzie, aby nie były tylko kolejnym czasem spędzonym przed komputerem? W jej wyniku wpadliśmy na pomysł uzupełnienia zwykłych zbiórek o cykle konkursowe – konkursy wzorowane na sprawnościach, które wypełnią czas między zbiórkami różnymi zadaniami powiązanymi fabułą aktualnego cyklu. Zaplanowaliśmy zadania na pierwszy sprint. Jako że zbiórki gromady odbywały się w soboty, ustaliliśmy długość sprintu na tydzień z zakończeniem w piątek, aby mieć pewność, że wszystko jest gotowe. Naszymi odbiorcami (czyli klientami w nomenklaturze Scrum) nie były jedyne zuchy, ale także ich rodzice – zwiększyliśmy więc częstotliwość kontaktu, aby systematycznie zbierać od nich informacje zwrotne.
Tablica Scrum
Naszym produktem były koronakonkursy, ale mieliśmy też inne, pomniejsze zadania. Przygotowywaliśmy je na tablicy w aplikacji Trello. Ustaliliśmy w niej pięć kolumn – zamrażarka, do zrobienia, w trakcie, ukończone, archiwum. Każdy sprint miał swój kolor (etykietę). Wspólnie ustalaliśmy zadania do zrobienia w jego trakcie, które wrzucaliśmy do odpowiedniej kolumny. Indywidualnie ocenialiśmy trudność wykonania każdego zadania w skali od 1 do 10 – wyciągaliśmy z tego średnią i wpisywaliśmy na koniec nazwy zadania. Po rozpoczęciu danego zadania przez kogoś z kadry, osoba ta przenosiła kartę do kolejnej kolumny „w trakcie”, a po ukończeniu do kolumny „ukończone”. Prosta sprawa. Po zakończeniu sprintu przenosiliśmy wykonane zadania do archiwum, a to czego nie udało zrobić w tym sprincie, przenosiliśmy do kolejnego (dodawaliśmy kolejny kolor). W trakcie sprintu wpisywaliśmy do „zamrażarki” zadania, które musimy wykonać, aby później uwzględnić je przy planowaniu następnego sprintu.
Trello było dobrym narzędziem, jednak zdecydowaliśmy się przenieść do Plannera Microsoftu, ponieważ w Microsofcie mieliśmy resztę naszych plików.
Ze sprintu na sprint ulepszaliśmy nasz sposób pracy. Na koniec ocenialiśmy każdy sprint zgodnie z trzema pytaniami z metody Scrum: Dlaczego sprawy potoczyły się w taki sposób? Dlaczego o tym zapomnieliśmy? Dzięki czemu moglibyśmy być szybsi? Sumowaliśmy punkty z każdego sprintu, stąd wiedzieliśmy, jak poszło nam w tym sprincie – lepiej, czy gorzej niż w poprzednim. Na spotkaniu podsumowującym zakończony sprint, planowaliśmy od razu kolejny.
Po drugim sprincie dodaliśmy “Wtorkowy checkpoint” 5-minutowe motywacyjne spotkanie w środku sprintu, na którym zadawaliśmy sobie pytania: Co zrobiłeś od ostatniej rozmowy? Co zamierzasz zrobić do końca sprintu? Co Ci przeszkadza w zrealizowaniu zadania? Dawało nam to zastrzyk dodatkowej energii.
Nie do końca Scrum
Przy okazji pisania tego artykułu dokonałem analizy modelu pracy zastosowanego w naszej kadrze gromady zgodnie z wytycznymi z Przewodnika po Scrumie, który przywołałem wcześniej. Wychodzi na to, że zastosowaliśmy jedynie fragmenty metody Scrum, a nasz model ma kilka braków:
Nie mieliśmy Product Ownera – osoby porządkującej pracę potrzebną do rozwiązania złożonego problemu, tworząc Product Backlog. Jest to osoba odpowiedzialna za interes odbiorców.
W naszym przypadku substytuowaliśmy sobie ten brak zwiększonym kontaktem z rodzicami zuchów. Mimo tego obecność w zespole PO skupionego konkretnie na swoim zadaniu, znacząco podniosłaby jakość naszego Scruma.
Ciekawym pomysłem jest zaproszenie do zespołu swojego hufcowego w roli Product Ownera. Musiałby jednak znać się trochę na omawianym modelu pracy.
Nie zbieraliśmy zespołu z konkretnymi umiejętnościami specjalnie do pracy Scrumem – Scrum Team stanowiła nasza kadra gromady, a wódz pełnił rolę Scrum Mastera. Uczyliśmy się na bieżąco, dostosowując metodę pracy do naszych możliwości i potrzeb.
Nie nastawialiśmy się na Ukończenie (jednego konkretnego) Produktu na koniec każdego sprintu – owszem, naszym produktem były konkursy, ale największą wartością było dla nas wyznaczenie sobie zadań i realizacja ich w czasie. Finalizując dany sprint oprócz konkursu mieliśmy ukończone kilka innych “produktów” z różnych tematów – nowy cykl zbiórek, narzędzie kierunkujące rozwój kadry (“Sfery rozwoju”), czy szczegółowy plan sobotniej zbiórki, który musieliśmy zmodyfikować ze względu na pandemię.
Małą wagę przykładaliśmy do Celu Sprintu – zamiast jednego mieliśmy wyznaczonych kilka. Co do głównego celu (konkurs), tak jak wcześniej, nie był on dla nas najważniejszy. Ponownie pomocną byłaby tu praca Product Ownera, ponieważ to on powinien pilnować porządku w celach sprintów.
Deweloperzy (reszta kadry) nie komunikowali swoich potrzeb i przeszkód do usunięcia Scrum Masterowi – prawdopodobnie z powodu niezbyt dużej znajomości metody pracy i roli swojej oraz reszty zespołu.
Nie mieliśmy spotkań Daily Scrum – zamiast tego substytuowaliśmy się wtorkowymi checkpointami. Zapewne codzienne, 15-minutowe spotkania podniosłyby wartość naszej pracy, ale kto chciałby robić harcerstwo 7 dni w tygodniu? (PS. Wiadomo, że każdy.)
Mógłbym wypisać jeszcze kilka braków, ale na tym zakończę. Każdego, kto chce skorzystać z metody Scrum, zapraszam ponownie do przewodnika: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
Dlaczego Scrum to dobry pomysł
- widoczna poprawa zaangażowania i jakości pracy kadry i gromady
- możliwe szybkie nadążanie za potrzebami zuchów (szczególnie podczas lockdownu)
- regularne spotkania kadry
- umiejętność dzielenia odpraw na chillout i pracę zespołową (zrobiliśmy kilka odpraw kadry w Minecrafcie, założyliśmy też w Szczepie wspólny serwer)
Dlaczego Scrum to zły pomysł
– bardzo angażujący i wyczerpujący model pracy
– sprawdza się w projektach, a nie w regularnym działaniu
– w opisanej wyżej konfiguracji wykorzystania elementów metody Scrum sprowadza kadrę do błędnego podejścia – nastawienia na produkt zamiast wychowania
Podsumowanie
Scrum w Rycerzach Iskry:
– Zrealizowaliśmy 7 cykli konkursowych (koronakonkursy)
– Wpadliśmy na innowacyjny pomysł i dzieliliśmy się nim na forum (Baza Pomysłów ZHR, Aktywny ZHR, spotkania referentów z Wydziałem Zuchowym)
– Podnieśliśmy poziom pracy naszej kadry
– Nie zatrzymaliśmy się podczas pandemii, przeciwnie – przyspieszyliśmy i uderzyliśmy ze zdwojoną siłą.
Miejsce, gdzie dotarliśmy z pomocą Scruma w mojej opinii świadczy o skuteczności tej metody. Jestem zadowolony mimo tego, że po kilku sprintach produktywność spadła. Myślę, że powodem było zmęczenie formą online i tematem pandemii, a także szybkim tempem pracy.
Podsumowując: jak napisałem wcześniej – wychowanie nie jest projektem. Nie powinno się prowadzić drużyny/gromady z nastawieniem na produkt, bo w harcerstwie najważniejsze jest działanie przykładem własnym. Jednakże podejście projektowe dobre jest do planowania i realizacji poszczególnych akcji – np. biwaku, rajdu, czy obozu. W tych przypadkach stosowanie Scruma (całej metody, a nie fragmentu, jak w naszym przypadku, chociaż zastosowanie całości byłoby trudne) prawdopodobnie będzie bardzo dobrym pomysłem. Może warto spróbować?
Przez 4 lata wódz gromady, przez 3 lata referent ds. zuchów, przez 3 lata hufcowy „Roju” z Północnego-Zachodu, aktualnie komendant szkoły instruktorskiej. Inżynier architekt, tutor w liceum edukacji domowej i szczęśliwy mąż. Fan tabelek, koneser grafiki i azymuciarz.
