Historia pewnego zespołu

W poniższym wpisie pokażemy jak na przestrzeni kilku lat ewoluowała organizacja pracy zespołu Scrum Masterów w GetResponse. Firma rosła jak na drożdżach, więc konieczne było stawianie czoła coraz to nowym wyzwaniom.

Początki

Jako zespół Scrum Masterów, od samego początku mieliśmy pełne zaufanie organizacji. Praca, jaką trzeba było wykonać w związku z transformacją agile, nie była narzucona z góry. Samodzielnie identyfikowaliśmy pierwsze obszary usprawnień. Nasze obserwacje przekuwaliśmy na konkretne zadania, a te składały się na backlog naszego zespołu.

Zespół SMów „startował” w składzie dwuosobowym, a każdy z nas opiekował się dwoma zespołami. Spotykaliśmy się na bieżąco i doskonale wiedzieliśmy, jaki jest zakres danego zadania i jego status. Planowanie i dzielenie się pracą było dla nas niezwykle proste. Praca szła dobrze, również po pierwszych wzmocnieniach kadrowych (zespół dość szybko powiększył się o kolejne dwie osoby).

Pracowaliśmy w tygodniowych sprintach. Szybkie planowania, szybko pojawiające się rezultaty naszej pracy – szliśmy jak burza. Jeśli pojawiały się kłopoty z zadaniem, mieliśmy przestrzeń, aby się wzajemnie wesprzeć. 

Każdy ze Scrum Masterów pracował, rzecz jasna, zwinnie. Pojawiały się jednak drobne różnice w naszej codziennej pracy. Przykładowo, jedni Scrum Masterzy zapraszali Product Ownerów na Daily, podczas gdy inni absolutnie się na to nie zgadzali. Innym przykładem może być to, że część z nas – po ustaleniu tego z Product Ownerem – intensywnie pracowała z backlogiem danego zespołu i w początkowej fazie pracy zespołu dominowała na spotkaniach, a pozostali mieli inny, bardziej „wycofany”, obserwacyjny tryb pracy, zostawiający więcej przestrzeni dla Product Ownerów i zespołów. Obie „grupy” żyły w przekonaniu, że tak samo robią pozostali.

Jako Scrum Masterzy, od początku kładliśmy duży nacisk na wymianę informacji. Spotkania, podczas których to robiliśmy, zostały nazwane „Scrum Coffee”. Agenda była dość luźna, jednak zawsze rozpoczynaliśmy od przekazania wszystkich istotnych informacji na temat tego, co interesującego wydarzyło się w zespołach scrumowych i w organizacji. Pozwalało to nam na podjęcie działań usprawniających aspekty procesowe i organizacyjne w GetResponse. 

Komunikowaliśmy się nie tylko w ramach zespołu Scrum Masterów, ale też z Managementem IT. Spotykaliśmy się raz w tygodniu, więc mogliśmy szybko uzyskać informację zwrotną dotyczącą naszych działań. Pozwalało to na sprawne tworzenie planu działania i rozwiązywanie problemów na poziomie IT.

Każdy z nas przychodził do GetResponse z innym stażem i bagażem doświadczeń wyniesionym z różnych firm. W dodatku byliśmy zapalonymi fascynatami agile, byłoby więc wielką szkodą marnowanie takiego potencjału ;). Aby czerpać ze swoich doświadczeń, organizowaliśmy cykliczne, dość nieformalne spotkania (nazwaliśmy je „Konwentykielem”), podczas których poruszaliśmy zaplanowane wcześniej tematy, a dodatkowo każdy opowiadał o swoich doświadczeniach. Postanowiliśmy też, że wykorzystamy metodę shadowingu – każdy Scrum Master miał swój „cień”, który przyglądał się jego codziennej pracy i dawał mu feedback.

Krzewienie wiedzy na temat zwinnych metod pracy realizowaliśmy w GetResponse na kilka sposobów. Najprostszym z nich był specjalny kanał na Slacku, na którym publikowaliśmy materiały i linki do artykułów, które uznawaliśmy za wartościowe. Jego dodatkową zaletą było to, że mógł do niego dołączyć każdy pracownik organizacji. Kolejnym sposobem, była organizacja cyklicznych spotkań, podczas których w gronie Product Ownerów, Scrum Masterów i Managerów dyskutowaliśmy nad wybranym wcześniej tematem. 

Pole do usprawnień… powiększa się

Idylla i samozadowolenie z wyżej przedstawionego sposobu pracy nie trwały długo. Wraz z pojawieniem się nowych osób w zespole Scrum Masterów i zwiększoną liczbą zespołów, które prowadziliśmy, zaczęły się pojawiać trudności wymagające interwencji. Zespół Scrum Masterów rozrósł się do 6 osób, które opiekowały się 13 zespołami. 

Natłok prac spowodowany prowadzeniem większej liczby zespołów i tematów, którymi trzeba się było zaopiekować w związku z rozwojem GetResponse powodował, że zaczął doskwierać nam chroniczny brak czasu. Miało to wpływ na jakość naszej pracy wykonywanej na potrzeby zespołu Scrum Masterów i organizacji. Można powiedzieć, że mocno się od siebie oddalaliśmy, skupiając się głównie na pracy z zespołami scrumowymi, które mieliśmy pod swoją opieką.

Miało to daleko idące konsekwencje:

• Brak czasu dla zespołu Scrum Masterów – mimowolnie zaczęliśmy uważać, że zespoły scrumowe były ważniejsze, szczególnie przy takim natłoku obowiązków.
• Konwentykiel zmienił się omawianie bieżących spraw, więc nie mieliśmy przestrzeni na wymianę swoich doświadczeń i rozwój.
• Brakowało otwartości w informowaniu o tym, co dzieje się w zespołach scrumowych, przez co straciliśmy poczucie, że zmierzamy w tym samym kierunku.
• Zaniechaliśmy shadowingu.
• Przestaliśmy rozliczać się z prac, które założyliśmy, że wykonamy w sprincie zespołu Scrum Masterów.

Dodatkowo, z biegiem czasu, przestaliśmy działać w sprintach. Zaczęliśmy pracować używając techniki „continuous flow” – nowe zadania, które znajdowały się na backlogu zespołu Scrum Masterów, były przez nas podejmowane dopiero wtedy, gdy kończyliśmy poprzednie. Niestety, zmiana organizacji pracy nie wpłynęła pozytywnie na nasze tempo. Brakowało nam samodyscypliny w realizacji zadań. 

Z czasem, drobne różnice w naszej pracy bardzo urosły, a brak pełnej wymiany informacji i wiedzy między nami powodował, że wiele zespołów popełniało te same błędy.

Na dokładkę, zespół nie posiadał lidera. Brakowało osoby, która w trudnych chwilach mogła wziąć odpowiedzialność i podjąć kluczowe decyzje.

Zaczęliśmy działać

Na szczęście, wyżej wymienione problemy dość szybko zaczęły nam przeszkadzać – postanowiliśmy więc zacząć działać. Zidentyfikowaliśmy obszary, które musimy usprawnić jako pierwsze.

Niezwykle pomocny w tym procesie był, wypracowany i przypieczętowany przez wszystkich członków zespołu Scrum Masterów, kontrakt drużynowy. Służył jako kompas – w każdej chwili mogliśmy na niego spojrzeć i upewnić się, czy działamy tak, jak się na to umawialiśmy. W kontrakcie zawarliśmy m.in. takie obszary jak:

• Współpraca – podkreślenie i przypomnienie, że potrzebny jest nam zespół – tylko wspólnymi siłami, zmienimy kulturę pracy na zwinną i nie da się tego zrobić, pracując indywidualnie.
• Inspiracja – musieliśmy przypomnieć sobie jak wiele dawała nam wymiana doświadczeń i wiedzy.

Na warsztat wzięliśmy planowanie prac zespołu Scrum Masterów. Przywróciliśmy sprinty i ustaliliśmy czas ich trwania na 2 tygodnie. Każdy ze Scrum Masterów wybiera zadania, które zamierza zrealizować – na sprincie nie ma zadań „niezaopiekowanych”.

Prace realizowane w ramach zespołu dzielimy na dwa rodzaje:

1. Zadania cykliczne. Jesteśmy odpowiedzialni za obszary gdzie możliwe było określenie częstotliwości prac:
   • Wpisy na firmowym blogu – widzimy dużą wartość w jego prowadzeniu, toteż umówiliśmy się, że jako zespół będziemy je regularnie przygotowywać. 
   • Lessons Learned – artykuły pisane na wewnętrzne potrzeby organizacji. Przyświeca nam idea pokazywania rzeczy, które moglibyśmy robić lepiej, jako lekcja na przyszłość.
   • Gazetka – w każdej firmowej kuchni wisi tablica, którą regularnie aktualizujemy. Zdarzają się treści edukacyjne, ale też informacyjne – ostatnio wywiesiliśmy plan najbliższych promocji (Black Friday, Cyber Monday itp.). Była to bardzo przydatna informacja z punktu widzenia organizacji wdrożeń na produkcję. 
   • Agile Intro w ramach procesu onboardingu – nasza organizacja stawia mocny nacisk na dobre wdrożenie każdego nowego pracownika. Jednym z aspektów jest właśnie “Agile Intro” – krótkie warsztaty prowadzone przez Scrum Masterów, podczas których opowiadamy, jakimi zasadami kierujemy się w naszej codziennej pracy.
2. Zadania związane z realizacją naszych długoterminowych (zazwyczaj kwartalnych) celów. Są w całości wypracowane przez nasz zespół i konsultowane z Zarządem. Określamy obszary, które chcemy usprawniać, a następnie rozpisujemy w backlogu zespołu Scrum Masterów zadania, które powinny zostać zrealizowane. W ostatnim czasie pracujemy nad:
   • Jednoznaczną rolą Scrum Mastera w GetResponse – zależało nam, aby rola i obowiązki Scrum Mastera były przez wszystkich rozumiane tak samo. Chcieliśmy, aby każdy wiedział, w jaki sposób możemy pomóc. Owocem naszych prac był dokument bardzo szczegółowo opisujący naszą rolę. Wymagało to od nas walidacji swojej wiedzy – zarówno domenowej (obszarów aplikacji, w których działają zespoły scrumowe, którymi się opiekujemy), ale też „zawodowej”.
   • Dobrze działające zespoły Scrumowe – zdefiniowaliśmy, w jaki sposób zespoły, które mamy pod swoją opieką powinny funkcjonować, abyśmy wszyscy mogli powiedzieć, że pracujemy skutecznie i efektywnie. Rozmawiamy ze swoimi zespołami Scrumowymi, aby określić, czy w danym zespole trzeba usprawnić niektóre procesy. I wiele, wiele innych 😉

Jak widać na powyższych przykładach, zadania trafiające na sprint i backlog zdecydowanie nie są luźnym zbiorem pomysłów na to, co można usprawnić w organizacji.  To była kolejna duża zmiana w naszym zespole. Kwartalne cele, które mieliśmy realizować, poddawaliśmy priorytetyzacji. Dzięki niej, mogliśmy skupić się na wybranych tematach.

Zaczęliśmy stawiać nacisk na wymianę wiedzy. Udało się nam powrócić do dobrych praktyk, ponownie organizując „Scrum Coffee” (ale tym razem w pełnym gronie), gdzie, jako zespół Scrum Masterów, wiedzieliśmy co dzieje się w całej organizacji oraz zespołach Scrumowych, którymi się opiekujemy.

Powróciliśmy do rozwoju zawodowego poprzez „Konwentykiel”. Przygotowujemy tematy, które mogą nas zaciekawić i zainspirować, a następnie je omawiamy.

Wracamy też do shadowingu – jednak tym razem chcemy zrobić to na mocnych podstawach. Przygotowujemy dokument dokładnie opisujący cały proces oraz obszary, które będziemy „shadowować” jako pierwsze.

Zespół ma też swojego lidera, co działa otrzeźwiająco w chwilach zwątpienia. 😉

Podsumowanie

Czego się nauczyliśmy? Na pewno tego, że zbudowanie mocnego zespołu Scrum Masterów to nie bułka z masłem ;). Siła zespołu to synergia naszych doświadczeń i kompetencji nakierowana tak, aby pomagać organizacji i zespołom Scrumowym. Aby ta przysłowiowa para nie szła w gwizdek, potrzebne jest jasne określenie kierunku, w którym idziemy oraz priorytetyzacja i koordynacja zadań, jakie należy zrealizować, aby dotrzeć do celu, jaki przed sobą stawiamy. Ważne jest również to, że Scrum Masterzy nie mogą pracować jako osobne byty w organizacji. W ramach zespołu Scrum Masterzy powinni uczyć się od siebie i wspierać nawzajem, wyznaczać kierunki usprawnień w organizacji. Muszą też wymagać i egzekwować od siebie realizację wspólnych ustaleń.