Kategorie
Praktyka

Zwinne praktyki dla zespołu HR. Scrum i Kanban – opis warsztatów

Agile zatacza coraz szersze kręgi. Zwinnych praktyk jest całe mnóstwo i mogą pasować do wielu inicjatyw – tam gdzie mamy do czynienia z projektami, z zespołową pracą, planowaniem itp. Już nie tylko zespoły typowo deweloperskie chcą być zwinne, ale także HR, marketing i inne. Razem z Agnieszką, mieliśmy okazję przeprowadzić szkolenie w firmie AirHelp, w której wówczas wspólnie pracowaliśmy, dla działu HR właśnie. W tym poście piszemy o tym jak takie szkolenie wyglądało i co wg naszych doświadczeń może przydać się takiemu zespołowi. 

Poniżej znajdziesz opis warsztatów i kilka naszych wniosków. 

Pod artykułem jest także sekcja komentarzy – dodaj swój! Chętnie poznamy Twoją opinię na temat wdrażania Scruma i nie tylko w zespołach niedeweloperskich. 

Teoria? Nie do końca!

Przed warsztatami, zrobiliśmy swoiste badanie potrzeb – dowiedzieliśmy się z jakimi problemami mierzą się pracownicy zespołu HR, jakim stanem wiedzy dysponują (na temat agile itp.). Na tej podstawie uznaliśmy, że zamiast przytaczać suchą teorię, omawiać wartości czy zasady, lepiej skupić się na pokazaniu wielu praktyk, które mogą adresować wybrane problemy – nie tylko dotyczące zwinności czy zarządzania projektami, ale także związane z produktywnością, komunikacją itp. 

W naszym podejściu skupiliśmy się na wyposażeniu zespołu HR w zestaw narzędzi i praktyk. Chcieliśmy, aby członkowie tego działu mogli wybrać samodzielnie, te które uznają za cenne, do swojej codziennej pracy w mniejszych grupach, projektach itp. 

Dla tych, którzy potrzebowali jeszcze zgłębienia tematu pozostawaliśmy do dyspozycji – tak też się stało, kilka osób skorzystało później z naszych indywidualnych konsultacji. 

Jakie praktyki i narzędzia zademonstrowaliśmy? Oto trzy przykłady, łącznie tego typu praktyk / narzędzi było kilkanaście:

  1. Wizualizacja – z przykładami jak wyglądają tablice zespołów scrumowych. Po co? Wiedzieliśmy, że zespół HR ma bardzo dużo tematów, które nierzadko dotyczą kilku osób, o których warto też informować pozostałych członków zespołu. Do tego czasu nie mieli zorganizowanej takiej tablicy czy backlogu, chociażby dla projektów wspólnych dla całego działu. 
  2. Retrospektywa z przykładami różnych formatów. Po co? Zespół wyraźnie potrzebował ustalić kilka spraw i procesów, a regularne retro to świetny sposób w takich sytuacjach!
  3. Technika pomodoro. Po co? W wyniku rozmów ustaliliśmy, że radzenie sobie z zarządzaniem codziennymi zadaniami w ich natłoku i przy dużej dynamice, to jest coś co może zainteresować tę grupę. Pomodoro to jedna z technik, które stanowiły nam za punkt wyjścia do rozmowy o tematyce zarządzania sobą w czasie itp. 

Praktyk było zdecydowanie więcej, ale zostawimy je jako sekret ;-) Na pewno rozumiecie teraz jaki charakter miała taka „prezentacja”. 

Praktyka? Bardzo dużo

Rzeczy, które wyjaśniliśmy w poprzedniej części warsztatów teoretycznie, trzeba sprawdzić także w praktyce. Podzieliliśmy uczestników na 4 zespoły. dwa z nich pracowały z wykorzystaniem Scruma, jeden z wykorzystaniem założeń podejścia kanbanowego. Czwarty zespół mógł zdecydować w jaki sposób chce pracować – mógł wybrać dowolny framework, wykorzystać dowolne praktyki i poskładać je na swój sposób.

Wszystkie zespoły miały to samo zadanie – zbudować fizyczną makietę biura, wykorzystując do tego klocki lego i różne materiały papiernicze. Oczywiście taki projekt był bardziej doprecyzowany: ile stanowisk potrzeba, przestrzenie między nimi itp. 

Jak myślisz, który zespół pracował najbardziej efektywnie? W którym zespole praca była najlepiej zorganizowana, dobra pod kątem komunikacji i zadowolenia interesariuszy (nas, jako tych, którzy oceniali dostarczany produkt – przestrzeń biurową)? Były to oba zespoły scrumowe. Dlaczego?

Gdzieś po cichu liczyłem na to, że zespół, pracujący w Kanbanie będzie przodował, ale stało się jednak inaczej. Liczyłem na to, że zespół wykorzysta potencjał zasad kanbanowych i doszlifuje swój proces, z każdym kolejnym krokiem i wykonanym zadaniem, stając się lepszym. Problem w tym, że nie jest to wcale takie proste. Zresztą to dość logiczne. Ciężko jest, pod wpływem presji czasu: dogadać się z kolegami i koleżankami, stworzyć projekt i jeszcze ogarnąć sobie proces. Do tego zadowolić klientów. Szczególnie, gdy dopiero uczymy się tego całego edżajla. Na początek lepsze okazują się nieco sztywniejsze ramy, które proponuje Scrum. Zespoły scrumowe miały regularne Przeglądy Sprintu i Planowanie, które zapewniały im pętlę zwrotną i kontrolę postępu prac, podział zadań. Od iteracji do iteracji, makiety wyglądały coraz lepiej.

Zespół, który mógł zdecydować o wszystkim samodzielnie dostarczył projekt najszybciej. Jednak zabrakło mu pętli zwrotnej, skupili się na wykonaniu, a nie walidacji pomysłów, przez co makieta okazała się rozjeżdżać z wyobrażeniami klientów przez co efekty pracy były najgorsze. 

Dyskusja? Zdecydowanie

Warsztat nie byłby pełny bez szansy na dyskusję – rozmawialiśmy zatem o tym czego przed chwilą doświadczyliśmy, propozycjach praktyk i narzędzi z pierwszej części warsztatu i co można z tym wszystkim zrobić w codziennym życiu, w pracy. 

Tę część lubię najbardziej. Z dwóch powodów. Pierwszy – jest to pewnego rodzaju walidacja czy wykonaliśmy dobrą pracę, czy warsztat był sensowny. Jeśli tak, to energia przekuwa się na późniejszą dyskusję. Tak też było w tym wypadku – pomysłów i refleksji było dużo. Drugi powód – otwarta dyskusja to świetny sposób na to, aby uczestnicy nauczyli się czegoś od siebie nawzajem (jak zrozumieli dane praktyki itp.), to więcej perspektyw, to szansa na pogłębienie jakiegoś tematu (jego lepsze wyjaśnienie lub dotarcie do szczegółów, o których wcześniej nie pomyśleliśmy). 

Podsumowanie

Na koniec poprosiliśmy wszystkich o wskazanie minimum jednej rzeczy, której chcieliby spróbować w swojej codziennej pracy – indywidualnie lub w podgrupach, w których codziennie pracują. Pomysłów było sporo i w kilka dni potem zaczęliśmy obserwować wzmożone zainteresowanie tematami Daily, retrospektywy, pomagać przy ogarnianiu projektów HRowych itd. 

Logistycznie wyglądało to tak:

Czas trwania: około 5h
Liczba osób: 18
Co wykorzystaliśmy:  

  • Prezentacja Power Point, na której zawarliśmy wybrane praktyki
  • Wydrukowane zasady gry dla zespołów
  • Materiały biurowe potrzebne do wykonania produktu przez zespoły (nożyczki, arkusze papieru, klocki lego etc.) 
  • Klasyczny Timer
  • Wyrysowane ręcznie tablice dla zespołu Scrum i Kanban 

Wiele praktyk, które wykorzystują zespoły IT to praktyki, które fajnie działają i można z powodzeniem przenieść na grunt inny, np. HR. Wizualizacja projektów, retrospektywy, planowanie adaptacyjne to tylko wybrane z nich. Świetnie się bawiliśmy i przy okazji udało się zespół zachęcić do zanurzenia się w ten zwinny temat. Polecamy też Wam – jeśli chcecie spróbować wyjść poza świat IT, to czasem można bardzo łatwo się o tym przekonać, że warto.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *