Wprowadzanie scruma na siłę nie ma sensu. Jak na ironię, zespół który po ponad roku wspólnej pracy przestał mówić, że działa w scrumie zaczął o wiele bardziej zbliżać się do tego frameworku. Jak?
Jak zespół wyglądał kiedy do niego przyszłam
Zespół składa się z 12 kierowników, którzy mają pod sobą najczęściej od kilku do kilkunastu osób. Trzynastą osobą w zespole jest ich przełożony - dyrektor. Spotykają się ponieważ omawiają i współpracują przy tematach, które i tak byłyby im zlecone. Podczas próby dostosowania scruma do swojego zespołu, a raczej zespołu do scruma Product Ownerem został ich przełożony.
Mają wydarzenia scrumowe. Daily i planowanie pomagają im w szybszej komunikacji oraz doprecyzowaniu zakresu zadań i współpracy.
Retrospektywa jest przez nich często pomijana. Nie widzą w niej sensu. Nie ma z niej żadnych wniosków.
Review jest, czasami nawet bez interesariuszy. W takiej sytuacji referują wykonane lub niewykonane zadania swojemu przełożonemu. A pozostałe 11 osób słucha właściwie tego samego co na daily.
Mają sprinty i backlog sprintu. W backlogu “produktu” czasami pojawiają się tematy na kolejne sprinty, aczkolwiek bardziej na zasadzie, że w tym sprincie zespół już nic więcej nie da się zrobić, więc zadania zostają zaplanowane na kolejny sprint.
I przede wszystkim największy grzech zespołu - nie posiadanie produktu. Pracują nad zadaniami bieżącymi.
Kierownicy występujący w zespole związani są z produkcją fizycznego produktu, są to m.in. logistyka, magazyn, planowanie, technolodzy, montaż urządzeń, wydział mechaniczny i inne.
Wprowadzili scrum ze względu, że była to jedyna opcja pracy inna niż brak zasad jaką znali. W firmie przeprowadzana była transformacja agile. Wprowadzane były zwinne sposoby pracy. Zmiany rozpoczęły się od działów związanych z rozwojem produktów, jak programiści embedded. W związku z tym zarząd firmy mocno promował framework scrum. Niestety, przyczyniło się do lekkiego wypaczenia, w którym każdy chce mieć scrumowy zespół.
Jak znalazłam się w zespole
Jako scrum master w tej firmie zostałam poproszona o wskazówki, co mogą zrobić, aby nadać jakieś ramy swojej współpracy, które jednocześnie będą przynosić korzyści. Miałam dać informację zwrotną, co mogą lepiej zrobić, żeby ten scrum im wychodził. Jest to istotne, ponieważ nie był to mój kolejny zespół, któremu mogłam poświęcić swój cały czas. Współpraca z nimi miała nie wpływać na moją pracę z innymi zespołami, w których byłam scrum masterem.
Uczestniczyłam w jednym sprincie zespołu, aby zebrać dane o tym, jak działają, co nie do końca im służy, z jakich praktyk korzystają. Moje obserwacje zbierałam przez dwa tygodnie. To głównie w tym okresie dowiedziałam się jak zespół funkcjonuje i co się tam dzieje. Po tym czasie nastąpiła retrospektywa. Moją pierwszą informacją zwrotną do zespołu było „ To nie jest scrum”. Był to kubeł zimnej wody wylany na zespół. Niektórzy już od dłuższego czasu zdawali sobie sprawę, że coś tu nie gra, jednak nie wiedzieli co.
Cel
Podczas retrospektywy doszliśmy do konkluzji, że scrum nie jest dla nich świętym gralem, do którego muszą dążyć i go wdrożyć. Chcą lepiej funkcjonować jako zespół.
Najważniejsze cele jakie mamy osiągnąć z zespołem:
Zwiększenie zaangażowania w zespole
Nadanie ram pracy, które pozwolą utrzymać rytm pracy
Stworzenie współpracującego zespołu
Stała wymiana informacji między członkami zespołu
Podjęte działania
Pierwszym podjętym przeze mnie krokiem było pokazanie im innych opcji niż scrum. Zorganizowałam prawie 3 godzinny warsztat. Rozpoczęłam od części teoretycznej prezentując scrum, Kanban, scrumban (obecnie już nie przedstawiłabym tego jako oddzielny framework) oraz czwarty pomysł, czyli grupa zadaniowa z własnym zestawem reguł. O ile trzy pierwsze podejścia są powszechnie znane, tak czwarte było wskazaniem, że nie każdy musi pracować w opisanej już metodzie działania, a mogą sami spisać swoje ramy pracy.
Przedstawiając pomysł stworzenia własnych zasad wskazałam jakie obszary w pierwszej kolejności powinny być ustalone, aby ta współpraca działała, a nie była jedynie chaosem. Wybrałam:
jak będziecie się komunikować (np. f2f, czat na teams)?
jak przeprowadzicie inspekcję swoich działań (np. Daily, review)?
jak i kiedy będziecie się udoskonalać jako zespół (np. zostawienie retrospektyw, pytania na daily „co możemy zmienić?” lub „co było problemem w ciągu ostatniej doby?”)?
Następnie podzieliłam zespół na 4 grupy. Każda z nich musiała omówić jeden z tych sposobów pracy pod względem: plusów z wdrożenia, minusów z wdrożenia, znaków zapytania jakie widzą w danej metodzie, oraz inne czyli wszystko to, co przyjdzie im do głowy, a nie mieści się w tych trzech punktach.
Po 5-ciu minutach w każdej grupie zostawał tylko lider grupy, a pozostałe osoby zmieniały zespół, tak aby jak najwięcej osób miało możliwość omówienia każdej z opcji. Liderzy również mogli być zmieniani co rundę. Po czterech zmianach przeszliśmy do przedstawienia wyników pracy całej grupie.
Wnioskiem z warsztatów było, że grupa zmierza w stronę wytyczenia swoich własnych zasad, bazując na znanych frameworkach i modelach pracy. Jednak dopóki nowe zasady nie zostaną wytyczone, mieli funkcjonować tak jak do tej pory, wprowadzając ewolucyjnie zmiany. Głównym momentem na omówienie zmian miała być retrospektywa. A ja miałam przynosić na każdą kolejną retrospektywę flipcharty z wynikami pracy zespołu.
Kolejna retrospektywa to było przeczytanie minusów, jakie zespół widział w tym, jak pracują w scrumie. Był to brak wspólnego celu zespołu. Po dłuższej dyskusji nad wykonalnością tego oraz wartością dla firmy zdecydowali się podjąć jeden wspólny dla wszystkich cel szerzej omówiony na planowaniu. Tak też się stało i był to pierwszy krok do zmiany. Zespół przez kolejny dwutygodniowy sprint skupiał się na wspólnym celu. W trakcie dokonaliśmy również lekkiej korekty tego jak wygląda daily, tak aby nie trwało ono 30-40 minut i nie powtarzać codziennie tych samych informacji. Istotną zmianą w daily było to, że o zakończeniu zadania padała informacja tylko raz na daily, a nie jak wcześniej od momentu wykonania na każdym daily do końca sprintu.
Najważniejsze w pracy z zespołem było uświadomienie im jaki jest cel wydarzeń w scrumie, czyli „po co?” dane elementy są wykonywane. Zespół stał się bardziej otwarty na eksperymenty i po kilku tygodniach się ich nie boi. Każda retrospektywa kończy się jakimś eksperymentem i co najważniejsze, retrospektywy nie są pomijane. Ten zespół dopiero rozpoczął swoją drogę, ale jestem przekonana, że dostosują swój sposób pracy do siebie. Zasady spisują w dostępnej dla wszystkich bazie wiedzy. Wiedzą, że będą się one stale zmieniać, ponieważ pracują w zmieniającej się rzeczywistości.