Więcej Scruma z LeSS w PSI
07.01.2021 - Praca w PSI, Zarządzanie projektami IT, Case study
Dla zespołów tworzących nowe produkty w PSI Polska praca zwinna jest naturalnym wyborem. Framework Scrumowy, który nie zawsze jest możliwy do wdrożenia przy projektach klienckich, w przypadku pracy nad produktami jest rozwiązaniem pomagającym osiągnąć maximum wartości w minimalnym czasie, zorganizować pracę (szczególnie w dobie pandemii) i daje przestrzeń do szybkiego rozwiązywania ewentualnych problemów w procesach, technikaliach, czy relacjach międzyludzkich.
Ciągła rozbudowa zespołów powoduje, że zaczęliśmy szukać sposobów na skalowanie sprawdzonych procesów tak, by móc duży zespół podzielić na kilka mniejszych, a jednocześnie utrzymać korzyści wynikające z pracy zwinnej i nie rozbudowywać warstwy zarządczej (Product Owner, Development Manager, Scrum Master). Wybór padł na LeSS, który od kilku miesięcy zastępuje tradycyjnego Scruma i pozwalana dalszą optymalizację naszej pracy. Poniższy artykuł jest pisany z perspektywy Scrum Mastera wdrażającego LeSS w jednym z zespołów produktowych.
Skąd potrzeba zmian?
Z zespołem tworzącym produkt SCADA pracowałem jako Scrum Master od początku ich drogi do zwinności. Zaczęliśmy w sierpniu 2020 roku od wdrożenia podstawowych ram Scruma, tak by dać zespołowi jasną strukturę oraz przestrzeń zarówno na pracę jak i na rozmowy o bieżących wyzwaniach. Po kilku sprintach zauważyliśmy, że choć zespół docenił poprawę jakości swojej pracy, to większość spotkań zespołu nie jest tak efektywna jak zakładaliśmy - trudno było utrzymać wyznaczony wcześniej czas. Przyczyna była dość oczywista - rozmiar zespołu. Pomimo świetnej komunikacji, nastawienia na cel, rzeczowości wypowiedzi, ludzi uczestniczących w Scrumowych ceremoniach było po prostu za dużo by każdy chętny miał szansę się wypowiedzieć i wnieść coś wartościowego. Dodatkową trudnością okazało się planowanie sprintu i mierzenie jego wyników. Przy wielkości zespołu rzędu kilkunastu osób (trudno podać dokładną liczbę, dość często dołączały nowe osoby), tablica Scrumowa w Jira stałą się ogromną listą zadań do wykonania, trudną w utrzymaniu i problematyczną w codziennej pracy.
Scrum przewidziany jest na zespoły do 10 osób, więc rozwiązaniem było oczywiście podzielenie zespołu. Tylko jak?
Rozwiązanie i wdrożenie
W pierwszej kolejności rozważaliśmy rozwiązanie klonujące strukturę, tak by powstał drugi zespół, który miałby swojego Dev-Leadera i był osobnym bytem w strukturze firmy. Wiązało się to natomiast z potrzebą rekrutowania lub znalezienia wewnątrz firmy nowego przełożonego dla potencjalnego zespołu. Należało też uwzględnić kwestie związane z procesem: organizacja spotkań, podział uwagi Produck Ownera pomiędzy nowymi zespołami oraz planowanie prac. Na szczęście w PSI od niedawna inny zespół produktowy zmagał się z tym samym zagadnieniem i jako rozwiązanie wybrał framework LeSS, czyli Large Scale Scrum.
Framework ten został stworzony dokładnie po to, by umożliwić kilku zespołom scrumowym równoczesną pracę nad tym samym produktem, bez konieczności mnożenia struktur. W skrócie i dużym uproszczeniu: to Scrum poszerzony o spotkania koordynacyjne pomiędzy zespołami. Wydawał się więc idealnym rozwiązaniem dla zespołu, z którym pracuję. Po rozmowach z przedstawicielami zespołu korzystającego już z LeSS i przeczytaniu wszystkiego na less.works (przy okazji, to doskonała dokumentacja, czyta się świetnie) nadal jednak miałem wątpliwości, w jaki sposób prowadzone są spotkania i czym różni się organizacja pracy w takim frameworku. Przez dwa tygodnie uczestniczyłem więc w spotkaniach zespołu bardziej doświadczonego, robiąc notatki oraz przygotowując plan wdrożenia całości w zespole SCADA.
Efektem tej pracy jest lekko zmodyfikowany pod potrzeby zespołu framework (obrazek poniżej). Główną zmianą jest to, że zamiast PO pojawia się Business Team (PO jest wspomagany przez dwoje konsultantów, którzy z czasem coraz bardziej będą wchodzić w rolę PO). Do tego zachowaliśmy dotychczasowe godziny spotkań, by utrzymać rytm pracy zbliżony do wcześniejszego. Wspólnie z PO i Dev-Managerem (który jest przełożonym programistów w zespole) ustaliliśmy kryteria podziału i składy nowych zespołów. Rozstrzygnięty został też konkurs na nazwy nowych teamów (demokratycznie wygrały nazwy U mnie działa i Prawie gotowe :) ). Pomniejsze zmiany dotyczyły organizacji pracy w Jira (nowe filtry, flagowanie zadań), a wszystko spisaliśmy w bazie wiedzy na Confluence i przedstawiliśmy zespołowi pod koniec ostatniego "wspólnego" sprintu tak, by każda osoba miała jasność co się dzieje, oraz dostała możliwość zadawania pytań czy zgłoszenia wątpliwości.
Praca w LeSS
Już pierwszy sprint w metodyce LeSS pokazał, że kierunek zmian jest słuszny. Spotkania zaczęły być krótsze i bardziej treściwe, a tablica na Jira bardziej czytelna. Pierwsze retrospektywy w mniejszych zespołach pokazały, że teraz możemy bardziej precyzyjnie dobierać środki do organizacji pracy oraz testować je w mniejszej skali. Przykładowo, podczas retrospektywy jednego z zespołów pojawiła się potrzeba innej struktury daily. Zdecydowaliśmy się na "walk the board". Po tym, jak taka forma spotkań sprawdziła się, poszerzyliśmy ją na oba zespoły. Trochę jak w UXowych testach A/B, możemy na mniejszej próbce sprawdzić, czy dane rozwiązanie działa (oczywiście pamiętając o etyce Scrum Mastera i transparentnym komunikowaniu, że takie eksperymenty się odbywają). Z drugiej strony, początkowo zachwiany został rytm pracy oraz swobodna komunikacja istniejące w dużym zespole przed podziałem. Warto mieć na uwadze, że tak duża zmiana na pewno spowoduje przejście do faz rozwoju grupowego i wymusi więcej zachowań dyrektywnych ze strony Scrum Mastera. Dla samego procesu LeSS nie jest dużą zmianą, ale dla ludzi którzy muszą się odnaleźć w nowych zespołach - zmiana jest znacząca.
LeSS daje proste narzędzia pomagające skalować Scrum. Przy czym, podobnie też jak w samym Scrumie, wymagana jest dyscyplina, trzymanie się ustalonych reguł i dużo cierpliwości oraz świadomość, że wartościowe i działające usprawnienia wymagają czasu, a lepiej niż rewolucja, działa ewolucja.
Piotr Pilakowski
Quality Manager / Scrum Master
Humanista, ale od 10 lat związany z branżą IT. Od początku pracy w tej branży zajmował się przede wszystkim optymalizacją procesów i usprawnianiem komunikacji. Następnie zdobył doświadczenie w zarządzaniu zespołami zwinnymi, które obecnie wykorzystuje jako Quality Manager/Scrum Master w PSI do wspierania zespołów programistycznych i ich managerów podczas codziennej pracy. Nastawiony na jakość, przejrzystość i konstruktywną komunikację, ponieważ wierzy że nawet najbardziej złożone systemy informatyczne i tak zależne są od człowieka.