Czytałam wczoraj wpis na LI, w którym autor opisywał, czego to ekspertem (mastery) powinien być Scrum Master. Po pierwsze, ekspertem od technologii. Jak można pomagać inżynierom kodu, architektom, designerom, analitykom, testerom, jeśli nie masz technical mastery w każdej z tych dziedzin zespołu wytwórczego (lub nie wiesz, czym jest mastery w tych dziedzinach)? Po drugie, ekspertem od zarządzania produktem. Jak możesz pomagać Product Ownerowi, jeśli nie masz business mastery w jednym palcu (lub nie wiesz, czym jest mastery w tej dziedzinie)? Po trzecie, ekspertem od transformacji. Jak można wspierać zmianę w organizacji bez organizational transformational mastery zdobytej przez co najmniej dekadę wprowadzania zmian w organizacjach (lub nie wiesz, czym jest mastery w tej dziedzinie)? Patrząc na ten zakres na początku swojej drogi, dosłownie zakryłam się nogami, pytając siebie, po co w ogóle idę do tego IT.
Skoro pracuję w jakiejś roli i jestem postrzegana jako ekspert w danej dziedzinie, to nie powinnam popełniać błędów w tym zakresie. Jeśli popełnię błąd albo nie będę czegoś wiedziała, wyjdę na osobę niekompetentną. To samo jeśli po jakimś czasie zmienię zdanie na jakiś temat. Powinnam już na starcie wiedzieć wszystko i mieć wszystko przemyślane.
Problem z takim myśleniem wynikał z kilku czynników. Z jednej strony w roli scrum mastera nie istnieje jasna gradacja doświadczenia i na początku bardzo brakowało mi określenia „junior”, bez którego nakładałam na siebie ogromną presję posiadania wiedzy. W mojej głowie ta presja wykluczała możliwość popełnienia błędu. Nasze błędy i porażki nie są jednak tak wielkie w oczach innych, jak bywają w naszych własnych. Chwilę zajęło mi zrozumienie, że błąd lub niewiedza nie wieszczą końca świata. Każdy popełnia błędy. Każdy czegoś nie wie. Pod tym względem niczym się od siebie nie różnimy. No może nie każdy. Jak mówiła jedna moja szefowa: „Nie popełnia błędów tylko ten, kto nic nie robi”.
Scrum mastery
Jest też druga sprawa, która mnie niezmiennie intryguje w deklaracjach jak wyżej. Wychodząc od źródła, scrum master jest ekspertem od Scruma, a szerzej – pokazuje zespołowi i organizacji, w jaki sposób Scrum jako całość wspiera filozofię zwinną oraz w jaki sposób jego elementy pozwalają skutecznie dostarczać złożone produkty wysokiej jakości w postaci częstych (sprint) i systematycznych (iterative) paczek wartości (increment). Scrum master pokazuje zależności, ułatwia, aktywizuje. Umacnia zespół w rozumieniu i stosowaniu wartości i filarów Scruma. Nakierowuje na ciągłe uczenie się, zadawanie pytań, myślenie dywergencyjne, eliminowanie strat, usprawnianie procesu, podnoszenie kompetencji, skupienie na wartości bardziej niż na realizacji planu. Ale scrum master sam tych zmian nie wprowadza ani ich nie punktuje.
Mamy product ownera, którego obowiązkiem, poza maksymalizowaniem wartości, jest rozwijanie się w roli. Mamy inżynierów oprogramowania, którzy rozumieją swoje mastery, dyskutują o tym w swoim gronie, szukają rozwiązań i obszarów do poprawy. Oczywiście w każdym z tych obszarów scrum master może zachęcić do jakiejś praktyki (pair testing, testy jednostkowe czy integracyjne, hackaton, product discovery), zapytać o dług techniczny czy rodzaje przeprowadzanych testów, ale on nie jest ekspertem w każdym z tych obszarów.
Myślenie o scrum masterze jako o ekspercie w każdej z tych dziedzin stawia scrum mastera wyżej w hierarchii zespołu, a w Scrumie nie ma hierarchii. Scrum master to nie jest team leader, to nie jest tech lead, to nie jest business lead. To nie jest technical coach, business coach ani transformation coach.
Omnibus moriar
Co to w ogóle znaczy mastery? Wszystkie dziedziny tak szybko się rozwijają, że scrum master zamiast coś robić i aktywizować innych, musiałby dniami i nocami się kształcić, żeby za tym nadążyć. Kompletnie nie o to chodzi. Jesteśmy zespołem, wszyscy razem się UCZYMY. Scrum master aktywizuje ludzi do poszukiwań, usprawnień, podnoszenia jakości, ale nie wskazuje palcem ubytków, nie łata dziur, nie jest wszechmocny i wszechwiedzący, nie stoi ponad zespołem z całym swoim wachlarzem kompetencji. Umiejętność przyznania się do niewiedzy jest w porządku, to nie ujma na honorze. Jesteśmy razem właśnie po to, aby robić nowe rzeczy (wszyscy!), eksperymentować, popełniać błędy, wyciągać wnioski, próbować czegoś nowego, poszukiwać odpowiedzi. Scrum master to nie rola, która te wszystkie odpowiedzi zna. Dajmy sobie spokój z sensejami zwinności. Jeśli ktoś ma wykształcenie techniczne lub jest ekspertem w DevOpsach, doskonale, korzystaj z tego. Ale nie mów innym, że tylko twoja wizja tej roli jest jedyną słuszną, bo w tym nie ma za grosz zwinności.
Kiedyś zapytałam Kena Schwabera, czy scrum master w ogóle musi być techniczny.
Jak pomagać?
Developerom w zespole
Kiedy rozmawiamy o kompetencjach w zespole, pytam, czego członkom zespołu potrzeba, aby z większą pewnością siebie mogli realizować swoje zadania, i jak mogę ich w tym wesprzeć. Jeśli widzę, że mamy problem ze zrozumieniem, jak dług techniczny wpływa na biznes (w backlogu nie ma nic na ten temat), to za zgodą zespołu organizuję szkolenie lub zapraszam do poprowadzenia takiego spotkania innego scrum mastera biegłego w danej materii. Jeśli mamy problem z nagminnymi błędami w produkcie, to wspólnie zastanawiamy się, jak zwiększyć pulę automatycznych testów regresji lub szukamy innych rozwiązań, żeby zmniejszyć liczbę błędów w przyszłości. Sama tego nie wyszukuję, sama tego również nie naprawiam. Jeśli coś nie gra, to widzą to też inni a nie samotny jedyny wybraniec scrum master. W większości przypadków dojrzali software developerzy za każdym razem dają wskazówki tym mniej doświadczonym osobom i sami organizują się w ramach swojego accountability. Deweloperzy tłumaczą mi czasem zawiłości swojego mastery (np. one-click-deploymentów w CI/CD, czym jest kafka, dlaczego robimy design system itp.), ale słucham tego z ciekawości a nie z poczucia obowiązku, że muszę to wiedzieć.
Product Ownerowi w zespole
Więcej wsparcia potrzebuje product owner, bo jest to jednoosobowa rola (one person, not a committee). Kiedy widzę potencjał do product discovery w danym produkcie czy zespole, organizuję spotkanie z inną osobą, która już ten proces ma za sobą. Inspiruję swoją product ownerkę i wspólnie z zespołem decydujemy, czy sami chcemy spróbować. Nie stawiam się w pozycji eksperta od discovery, ale w tym procesie uczę się razem z nimi. Product owner jest liderem discovery i ma tu ownership, jest agentem zmiany w tym zakresie. A ja mu pomagam. Chodzę na wywiady zespołu z użytkownikami i – tak jak inni – zadaję pytania. Później, wraz z product ownerką, przygotowujemy prezentację na ogólnofirmowe spotkanie czy wewnętrzną konferencję, żeby docenić zespół i podsumować nasze odkrycia (i może zainspirować kogoś jeszcze). Uczę się procesu. Wszyscy zainteresowani podejmują aktywności związane z danym tematem. Wszyscy o tym rozmawiamy, a nie złoty scrum master przychodzi i oświeca swoją mądrością.
Kierownictwu w organizacji
Co do mastery w obszarze transformacji (czytam z tego wpisu):
A Scrum Master does not need to be able to understand the mechanics of the changes, that’s the job of Leadership. However, the Scrum Master must understand effective techniques and practices to help those leaders master their craft.
Jeśli pracuję z dyrektorem produktu danego portfolio, to nie wpadam do niego z „hello, widzę, że z ogarnianiem niezbyt, na szczęście, znam ja się i ci pomogę”, bo od razu mnie odetnie. Moje mastery zda się tutaj na nic. Jak będzie wyglądała sytuacja, w której product manager z 20-letnim stażem obecnie na stanowisku dyrektora będzie „nauczany” przez kogoś z mniejszym doświadczeniem? Czy moje mastery coś tu zmienia? Czy moja pozycja w tej relacji jest z nadania ekspercka, bo jestem agentem zmiany? Nie. On ma gdzieś moje „mastery”. Bo mnie nie zna i nie mamy relacji. Jeśli na starcie zacznę takiej osobie wskazywać niedociągnięcia lub podrzucać pomysły na usprawnienia, odbierze to jako wykazanie jej niekompetencji. A to ona jest ekspertem a nie ja. Czy to znaczy, że skoro jestem młodsza zupełnie nie mogę jej pomóc? Mogę. Tylko muszę zrobić to inaczej niż z naciskiem na „mastery”. Mastery tutaj tylko popsuje relację. Muszę człowieka wysłuchać, zapytać, czego potrzebuje. On tu steruje okrętem, a nie ja. Dopóki nie otworzy się z potrzebą i nie powie, że czegoś nie wie lub nie potrafi, nie wskóram zbyt wiele. A jeśli powie – poszukamy rozwiązania, wspólnie (a leader who serves). Nie będę mu dyktować, jak powinien wyglądać jego świat. Nie będę jego mentorem. Nawet jeśli wiem coś, czego on jeszcze nie wie.
Uczmy się wspólnie
Scrum wymaga dojrzałości wszystkich członków zespołu, nie tylko scrum mastera. Członkowie zespołu są odpowiedzialni za swój rozwój i podnoszenie kompetencji, odpowiedzialni są również za dostarczanie rozwiązań wysokiej jakości. Do analizy tego mamy przestrzeń podczas retrospektyw i przeglądów. To nie jest zadanie scrum mastera, żeby siedzieć na boku i spisywać braki, wyciągać wnioski i narzucać rozwiązania. Gramy zespołowo.
Mam nadzieję, że osoby, które stawiają wyżyłowane i niemożliwe do spełnienia przez więcej niż promil ludzi wymagania wobec roli scrum mastera, nikogo nie zniechęcą do tej roli. Nie musisz być ekspertem w tych wszystkich dziedzinach. A już na pewno nie od razu. Begin from the beginning. Dasz radę.