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.

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.

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.