1 lipca 2020

Lider w zespole Scrum Masterów

Prolegomena

Jak wiecie, na naszym blogu nie ma tematów tabu, więc tym wpisem zamierzam włożyć kij w mrowisko. Na młyn wrzucam tematy związane z organizacją i środowiskiem  pracy w zespole… scrummasterskim, czyli zespole Scrum Masterów, pracujących razem nad zwinną transformacją firmy. Wydaje się – o czym tu pisać, gdzie tu problem – w końcu ci ludzie zjadają samoorganizację na śniadanie i przegryzają ją dużą ilością usprawnień, bazujących na świetnie zorganizowanych retrospektywach, wiedzą wszystko o backlogach i ich porządkowaniu, są systematyczni, metodyczni, znakomicie się komunikują i współdziałają, wystarczy pozostawić ich samych, a zorganizują wszystko jak trzeba… 

Czyżby? Czy faktycznie praca jako Scrum Master w takowym zespole to przysłowiowa bułka z masłem, bądź (bardziej po korporacyjnemu) easy peasy lemon squeezy? Czy faktycznie z punktu widzenia organizacji wystarczy zatrudnić kilku Scrum Masterów, przekazać im wizję i oczekiwania, a następnie zostawić samych sobie, oczekując na wyniki? Co może pójść nie tak? 

Problemy z rolą Scrum Mastera

Zanim jednak o samej pracy w zespole scrummasterskim, chciałbym zwrócić waszą uwagę na to, skąd najczęściej biorą się różnice w podejściu do roli Scrum Mastera i określeniu jakie działania powinien wykonywać. To bardzo ważne, gdyż zdając sobie z nich sprawę, jaśniejsze stanie się, co doprowadziło mnie do poniższych przemyśleń.

Pierwszym źródłem różnorodności może być inna interpretacja tej roli. Nie ma bowiem klarownych, jednoznacznych wytycznych dotyczących pracy Scrum Mastera. Przewodnik po Scrumie daje bardzo ogólne wytyczne, które można sprowadzić do pracy z:

  • Zespołem Deweloperskim,
  • Product Ownerem,
  • organizacją.

W ramach każdego z tych punktów – jak to we frameworku – mamy ogólne wytyczne, a nie konkretne rzeczy, które punkt po punkcie musimy realizować. Scrum pozostawia tu ogromną dowolność. Czytając to, pewnie się Wam nasuwa: moment, co ten Michno pisze – przecież jak byk są w Przewodniku po Scrumie, przy każdym z tych trzech obszarów, wylistowane konkrety, co należy robić w każdym z nich! I tak, mamy przykładowo napisane, między innymi, że Scrum Master ma wspierać Product Ownera w znajdowaniu efektywnych technik zarządzania Backlogiem Produktu, Zespół Deweloperski w usuwaniu przeszkód, a organizację w zrozumieniu o co chodzi z tym całym Scrumem. 

Niby opisane, ale jak to robić w praktyce? Każdy, kto choć chwilę miał okazję pracować jako Scrum Master, wie, że pięknie to wygląda na papierze, ale gdy przychodzi do realizacji tych zadań, rozpoczyna się mętlik. Niedoświadczony Scrum Master na własną rękę stara się to zrozumieć, interpretować, eksperymentować i wdrażać to, co mu się wydaje słuszne, aby dobrze pracować w tej roli.

Drugim źródłem niejednorodności może być to, że do roli Scrum Mastera nie prowadzi jedyna słuszna droga. Jest ich wiele. Jedni, nie mając żadnego doświadczenia, a patrząc na ilość ogłoszeń o pracę, rzucą się na certyfikację, po czym szukają zatrudnienia, inni dojrzewają długie lata, zbierają doświadczenia z różnych stanowisk związanych z wytwarzaniem oprogramowania. Dzięki temu, że do pracy w tej roli nie trzeba nie wiadomo jakiego doświadczenia, powstaje mieszanka wybuchowa – mamy wśród nas ludzi po psychologii, socjologii, zarządzaniu, informatyce, byłych: testerów, deweloperów, architektów, analityków, ludzi od wsparcia klienta, managerów, Project Managerów, a czasami nawet “nominowanych z przypadku”, bo od dziś w firmie gości Scrum, a w Przewodniku po Scrumie jest napisane, że potrzebny jest Scrum Master. 

Różne doświadczenia prowadzą do różnych stylów pracy, dla każdego Scrum Mastera inne rzeczy mogą być ważne – jeden będzie skupiony na zespole, inny będzie świetnie radził sobie na forum firmy, a kolejny świetnie będzie spinał te dwie rzeczy. 

Trzecim – i w mojej ocenie najważniejszym – źródłem różnorodności może być różne postrzeganie i oczekiwania wobec Scrum Masterów w organizacji, która ich poszukuje. Tak, jak wątpliwości i różne interpretacje istnieją po stronie Scrum Masterów, tak różne są oczekiwania firm, które takiego Scrum Mastera zatrudniają. 

W znaczącej większości przypadków firmy oczekują od Scrum Masterów przede wszystkim pracy z zespołami wytwarzającymi oprogramowanie. Scrum Master ma siedzieć z deweloperami, słuchać, obserwować, szukać przeszkód, rozprawiać się z nimi. Czy to wszystko, co powinien robić? Tak, jak wspomniałem już wcześniej, wiele organizacji nie oczekuje niczego więcej, a taki model zdecydowanie jest daleki od pierwotnych założeń tej roli. 

Co więcej, patrząc na oferty pracy, wyraźnie widać, że mało kto wie jak napisać dobre ogłoszenie na Scrum Mastera. Nawet tak górnolotne  hasła jak ewangelizacja organizacji (swoją droga, strasznie nie lubię tego określenia) nierzadko kryją pod sobą raportowanie czy pełnienie roli liniowego kierownika, często wmiksowana jest w to rola Project Managera czy administratora Jiry. Te antywzorce tworzą firmy, które chcą z różnych względów posiadać Scrum Masterów, ale nie do końca wiedzą jak wykorzystać ich kompetencje. W organizacji, która sumiennie odrobiła lekcje i wymaga dokładnie tego, czym powinien się zajmował Scrum Master nie ma miejsca na tego typu “patologie”. Wszelkie odchylenia będą wyłapywane przez innych Scrum Masterów i od razu prostowane.

Mamy zatem trzy źródła potencjalnego problemu. Różne doświadczenia, różny styl pracy Scrum Masterów, niesprecyzowane/błędne oczekiwanie wobec roli i to, że można jej założenia realizować w niemalże dowolny sposób. To wszystko może powodować, że w mając kilku Scrum Masterów w firmie i pozostawiając ich samych sobie, w którymś momencie może okazać się, że każdy wykonuje swoją pracę  inaczej i każdy z nich może uważać, że to jest ok. Pół biedy, kiedy te różnice mamy na poziomie zespołów, problem zaczyna się kiedy chcemy zmieniać całą firmę… Zaczynają się kłótnie, niesnaski. 

Na czym powinna polegać praca Scrum Mastera 

Wróćmy zatem do podstaw. Kim właściwie jest Scrum Master i czym powinien zajmować się w firmie? Trzeba dobrze wytłumaczyć tę rolę w momencie wprowadzania jej w organizacji, szczególnie Product Ownerom i zespołom deweloperskim. Gdy tego nie zrobimy, to jak już wspomniałem, prędzej czy później pojawi się sytuacja, gdzie każdy ze Scrum Masterów będzie pracował zupełnie inaczej z zespołem deweloperskim (co jest normalne i dopuszczalne, ale równie dobrze może być antywzorcem z którego biorą się potem nieporozumienia), nie będzie także żadnego miejsca wspólnego co do oczekiwań, które może mogą mieć Product Owner bądź deweloperzy. Szczególnie dotyczy to zagadnień, które Scrum Masterzy biorą na siebie mimo, aby uzyskać określony efekt, mimo że nie należy to do ich nominalnych zadań (np. przeprowadzenie Przeglądu Sprintu, aby zespół miał wzór jak to powinno wyglądać). Często pracując w tej roli trzeba wychodzić poza jej ramy, po to, aby pokazać jak coś powinno być wykonane, bądź udowodnić zalety jakiegoś podejścia. Mówiąc prosto – przetrzeć szlak i pokazać jakie coś daje profity. Kiedy jednak, jeden Scrum Master będzie takie rzeczy wykonywać, a drugi nie, wniosek dla osób nieznających dobrze zwinnych praktyk będzie taki, że ten drugi po prostu się obija.

Aby zatem uniknąć tych wszystkich problemów należy na samym początku wypracować standardy, w których spisane będzie co od Scrum Mastera jest wymagane i egzekwować je na różnych poziomach (od organizacji przez Product Ownera na Zespole Deweloperskim kończąc).  Potrzebne są bezwzględnie: jednolite, spójne określenie roli i zadań Scrum Masterów,  wizji, jaka ma przyświecać ich pracy oraz zapewnienie poprzez odgórne wsparcie, aby znalazło to swoje odzwierciedlenie w praktyce. Spowoduje to, że przy zmianie Scrum Mastera w Zespole Scrumowym, nie będzie dysonansu, że Łukasz wspierał nas w jakiejś rzeczy, a przyszedł Maciek i stwierdził, że to kompletna bzdura.

Dbając o jednolitość, nie można jednak wylać dziecka z kąpielą. Pamiętajmy, że różnorodność doświadczeń w zespole to jego OGROMNY ATUT! Gdy jest to dobrze przemyślane na etapie rekrutacji, zespół taki powinien się uzupełniać i sumarycznie posiadać szeroką wiedzę z różnych dziedzin.

Mając wypracowany standard roli Scrum Mastera, czas przyjrzeć się jak moim zdaniem, powinna wyglądać modelowa współpraca w zespole scrumasterskim.

Chief Scrum Master/Lider zespołu Scrum Masterów

Posiadając szerszy kontekst, powróćmy do moich pytań z początku artykułu. 

Czy wprowadzając w firmie zespół Scrum Masterów i zatrudniając odpowiednie osoby na to stanowisko, możemy zostawić je same? Liczyć na to, że Scrum Masterzy nie tylko zajmą się indywidualnymi zadaniami, ale utworzą zespół i zgodnie z regułami samoorganizacji wypracują wspólne standardy, a także plan na działanie z organizacją i Product Ownerami, a także solidarnie podzielą się pracą?

Oczywiście, że tak, natomiast jest to bardzo trudne i musielibyśmy mieć dużo szczęścia, żeby zebrać tak zgodną grupę Scrum Masterów.

Dlatego – z mojego doświadczenia –  wynika, że w takim zespole najlepiej sprawdzi się jedna osoba, która będzie potrafiła spojrzeć na jego pracę z przysłowiowego lotu ptaka. W tym miejscu wyłania nam się rola Chief Scrum Mastera, bądź Lidera zespołu Scrum Masterów – jak go nie nazwiemy, chodzi o osobę, która będzie całkowicie skupiona na pracy strategicznej i koordynowaniu działań prac zespołu scrummasterskiego i nie będzie pracować bezpośrednio z zespołami scrumowymi. Najczęściej sprowadza się to do wspierania Scrum Masterów poprzez pomoc w definiowaniu ich celów, coaching, mentoring, wsparcie w rozwoju i ewaluację pracy. 

Tak jak w przypadku Scrum Mastera, tak Chief Scrum Master/Agile Coach, to praca na cały etat, a czasami i więcej. Taka rola jest niezbędna zarówno w świeżym, jak i dojrzałym zespole. Im dłużej zwlekamy z jej wprowadzeniem, tym będzie trudniej. Im dłużej zespół pracuje razem, tym trudniej będzie mu zaakceptować, że w pewnym momencie ktoś spośród nich lub z zewnątrz może zostać wybrany na “przewodnika stada” i zyska większą decyzyjność niż pozostali. 

Pozostawienie zespołu Scrum Masterów bez wsparcia Lidera/Chief Scrum Mastera może doprowadzić do wielu konfliktów, mimo dobrych chęci Scrum Masterów. Od różnic w sposobie rozwiązania jakiejś sytuacji po problemy personalne, ego, niezdrową rywalizację bądź odrzucanie pomocy, bo w sumie kim jest drugi Scrum Master, żeby mówić mi jak ja mam pracować. 

Kto najlepiej sprawdzi się w takiej roli?

Agile to nie jest czarno-biały, zerojedynkowy świat. To mnogość rozwiązań i dróg, różne oczekiwania firm oraz nasz ulubiony framework, czyli Scrum, który nie pokazuje wprost jak pracować. Wszystko to powoduje, że nie ma jedynie słusznych decyzji. Potrzebna jest osoba, która weźmie na siebie odpowiedzialność i je podejmie, mimo różnic zdań w zespole. W momencie gdy mamy zespół pozostawiony sam sobie taka sytuacja może pozostać nierozwiązana i ciężko będzie o konsensus. 

Dodatkowo, osoba w roli lidera zespołu scrummasterskiego powinna posiadać wysoko rozwinięte umiejętności pracy z senior managementem, szczeblem dyrektorskim czy w końcu z zarządem. Potrzebne jest myślenie długoterminowe, dobre zdefiniowanie celów dla Scrum Masterów, które spełnią oczekiwania pokładane w transformacji agile. Niezbędne są także silne umiejętności negocjacyjne, a wręcz dyplomatyczne, aby być w stanie przekonać te osoby do pewnych racji. 

Szczególną troską lider zespołu Scrum Masterów powinien otoczyć osoby z niewielkim stażem w tej roli. Tutaj szczególnie ważne jest, aby weryfikować postępy takich osób i wspierać, aby taki Scrum Master jak najszybciej wypracował sobie dobre nawyki i jak najszybciej się usamodzielnił, a potem stał wsparciem dla całego zespołu. Nie wolno jednak zapominać o “starych wyjadaczach”. W mojej opinii powinno się dążyć do tego, aby nikt nie zdążył sobie “uwić gniazda” w zespole Scrumowym. Trzeba dążyć do tego, że Scrum Master w tymże zespole jest tylko na “chwilę” i docelowo powinien przenieść ciężar pracy z zespołu Scrumowego na organizację. To wymaga nieustannej obserwacji poczynań i stawiania wyzwań, nawet tym najbardziej dojrzałym Scrum Masterom. 

Celem pracy takiego lidera jest też doprowadzenie do sytuacji, że praca w tym zespole jest tak poukładana i transparentna, że staje się przykładem za którym chcą iść zespoły Scrumowe. To zwiększa autorytet nas wszystkich, pokazując, że sami pracujemy zgodnie z wartościami, których uczymy i wymagamy od innych.

Spoiwo

Dużym wyzwaniem będzie zapewnienie spójności działań w zespołach Scrumowych, przy zachowaniu swobody oraz różnych sposobów pracy z zespołami. Po co to robić? Obserwowałem firmy, gdzie było kilku Product Ownerów, kilku Scrum Masterów oraz kilkanaście zespołów deweloperskich. Praca w takim środowisku to olbrzymie wyzwanie i bardzo ważne jest, aby zachować wspólne standardy pomiędzy zespołami Scrumowymi. Brak spójności może być szczególnie widoczny w momencie zmiany Product Ownera/Scrum Mastera w zespole, bądź podczas realizacji projektów w których zaangażowanych jest wiele zespołów. Przykładem rzeczy, która powinna być ogólnofirmowym standardem są mierniki (którym poświęcimy wkrótce dedykowany wpis) Zespołów Scrumowych. 

Zespół scrummasterski powinien zainwestować czas i określić co będzie częścią wspólną dla wszystkich zespołów Scrumowych, tak, aby przy wyżej wymienionych zmianach nie było zdziwienia. Wiadomo, że każdy z Zespołów działa w określonym kontekście i różnice w ich pracy nie muszą od razu oznaczać coś złego. Warto rozmawiać o różnicach i ustalać co gdzie powinna być przestrzeń do decyzji poszczególnego Scrum Mastera, a co powinno być standardem.

Przykładowo, w jednym zespole będzie potrzebne i dające wartość, aby Product Owner brał udział w Daily, w drugim nie będzie to możliwe, bo doprowadzi do rozliczania Zespołu Deweloperskiego z zadań i prób mikromenedżmentu. Natomiast standardem powinno być to, że nie ma wyjątków i we wszystkich zespołach odbywa się Daily Scrum i przynosi on wartość, bo każdy rozumie do czego to spotkanie jest potrzebne. 

Każdy ze Scrum Masterów może zaproponować rzecz, która wejdzie do kanonu, ale Chief Scrum Master/Agile Coach powinien ocenić czy przyniesie ona wszystkim wartość i podjąć decyzję w którym kierunku podążać.

Żeby dobrze wspierać taki zespół, samemu najlepiej mieć doświadczenie jako Scrum Master/Agile Coach.  Trzeba być obiektywnym i patrzeć na proces zmian z szerokiej perspektywy, a nie tylko perspektywy działu w którym jest się zatrudnionym. Tylko wtedy jest się w stanie zrozumieć problemy i wyzwania zespołu… Dodatkowo, prowadzenie takiego zespołu wymaga skupienia praktycznie tylko na tym kierunku.

Powinna to rola wspierająca, ale posiadająca prawo podjęcia ostatecznej decyzji. Osoba w niej pracująca powinna zapewnić szeroki kąt widzenia wszystkim Scrum Masterom w zespole. Dbać o wypracowywanie standardów, ale i o autonomiczność decyzji Scrum Masterów. 

Głównym zadaniem  jest coaching, mentoring, zapewnienie spójności, planowanie i koordynacja wdrożenia agile na szczeblu firmy, zapewnienie zrozumienia dla roli Scrum Mastera, weryfikacja realizacji celów, rekrutowanie nowych Scrum Masterów. W razie większych problemów i braku postępów prac w Zespole Scrumowym osoba taka powinna też móc obserwować Scrum Mastera podczas prac z Zespołem, ale zdecydowanie w formie “cienia” (obserwacja, informacja zwrotna, wsparcie). Nie powininna go strofować, poprawiać w trakcie działań, a udzielać informacji zwrotnej w cztery oczy.

Praca operacyjna w zespole scrummasterskim

Omówiliśmy kwestię standardów, przełożonego, na koniec zastanówmy się jak zorganizować prace zespołu scrummasterskiego?  Zacznijmy od tego co sprzyja budowie zespołów, czyli wspólnego miejsca, gdzie zespół może z sobą pracować. To jest bardzo ważne, prawdopodobnie dużo ważniejsze niż się wydaje. Większość dnia Scrum Masterzy spędzają z Zespołami Deweloperskimi, wspierają Product Ownerów, weryfikują mierniki, pchają projekty do przodu. Potrzebny jest także czas na rozmowę w “macierzystym” zespole. 

Dlaczego? Po pierwsze umożliwia to budowanie wspólnego frontu i komunikacji na zewnątrz zespołu. Rzucone czasami mimochodem, A wiecie, był u mnie dziś Janek, wiecie, ten Team Leader i próbuje mnie urobić na skrócenie czasu trwania Sprintu w zespole, potrafi się okazać kawałkiem ważnej układanki, bo okazuje się, że Janek był już u wszystkich i próbuje znaleźć najsłabsze ogniwo w zespole i przez nie przepychać swoje widzimisię poza plecami wszystkich. 

Nie ma też nic trudniejszego niż zespół, w którym w zależności od tego do kogo pójdziesz z tym samym pytaniem, usłyszysz różne (wręcz sprzeczne!) odpowiedzi (analogicznie można od razu, na przykład, przywołać zespół architektów oprogramowania). Szczególnie jak o pewne rzeczy pyta mityczny zarząd. Nie chodzi o to, aby recytować te same formułki. Zespół scrummasterski, mimo różnic w podejściu do niektórych rzeczy, na zewnątrz musi głosić wspólną, spójną wersję. Musi być jednością, silny jak skała, przekonywujący.

W swoich obserwacjach zauważyłem, że zespół scrummasterski, który nie ma wspólnej przestrzeni, często stara się wykorzystać każdy moment razem (np. spotkanie, gdzie wszyscy się zbierają) i ma tendencję do odchodzenia od tematu spotkań, po to, aby nadrobić wymianę informacji. 

Dodatkowo, z racji pracy, która po prostu często jest po ludzku, trudna, wyczerpująca, frustrująca, potrzebny jest jakiś wentyl, umożliwiający ujście emocjom. Ciągła walka o podnoszenie poprzeczki, próba przełamania niezrozumienia/oporu odciska piętno, powoduje poczucie, że myslimy, że “wariujemy” lub mamy poczucie, że tylko u nas “nie idzie”.  Nic lepiej wtedy nie podziała jak rozmowa z innym Scrum Masterem, który ma niewiele łatwiej. Nie piszę tu o wspólnym narzekactwie, mówię o wsparciu i wzajemnym rozumieniu, takim agile’owym odpowiednikiem programistycznej kaczuszki, kimś kto pomoże przetrwać, a może i nawet rozwiązać trudną sytuację. 

Wydawałoby się to oczywiste, ale zespół Scrum Masterski powinien pracować… zwinnie! Uwierzcie mi, to wcale nie takie proste. Część rzeczy, które robiłem przez szereg lat pracy na stanowisku Scrum Mastera była:

  • trudna do pokazania (masę czasu włożonych w rozmowy, feedback z których ciężko pokazać coś konkretnego),
  • niejawna (rozmowy z zarządem, top managementem, konsultantami),
  • nieinteresująca nikogo poza Scrum Masterami (niestety, tę gorzką pigułkę prawdy też trzeba przegryźć).

Mimo wszystko, trzeba dążyć do tego żeby pokazywać organizacji pracę jaką wykonują Scrum Masterzy możliwie często. To pomaga zbudować zrozumienie, że Scrum Master nie pracuje tylko i wyłącznie z Zespołami Scrumowymi i wyjaśnia zespołom czemu tak często znika z pokoju. Po drugie, pokazuje, że praca w zwinnym podejściu jest możliwa i sprawdza się nie tylko na styku IT i biznesu. Po trzecie, daje przykładem dla innych. Ciężko uczyć innych wartości, jeśli samemu nie potrafi się tak pracować. 

Dobrze, zapytacie pewnie,  ale skąd biorą się zadania nad którymi pracują Scrum Masterzy? Ano – z Backlogu tegoż zespołu. Jest to bardzo popularna praktyka, że analogicznie jak Zespoły Scrumowe, Scrum Masterzy mają backlog z zadaniami, które realizują. Powinno się tam znaleźć wszystko czym się zajmują i być odbiciem rzeczywistości. A co tam może trafić? Na przykład rzeczy związane ze standardami pracy (opracowanie Defintion of Ready, Definition of Done), zaplanowane szkolenia/warsztaty cykliczne, zadania związane z usprawnieniem procesu, odzwierciedlenie w zadaniach celów postawionych przed zespołem na kwartał, wnioski z retrospektyw scrummasterskich przeredagowane na konkretne zadania do wykonania. Wizualizuje nam to miejsce, w którym jesteśmy jako zespół, co zrobiliśmy, co przed nami, uwidacznia podział prac w zespole, kto, czym i kiedy się zajmuje. Aby propagować wiedzę, co się dzieje aktualnie w danym Zespole Scrumowym wśród Scrum Masterów, powinny tam także trafiać zadania, które realizują pojedynczy Scrum Masterzy  w tychże zespołach. Na przykład prace nad poprawą przewidywalności Zespołu, poprawą jakości wymagań, przypilnowanie porządków na Backlogach.

Olbrzymia rola tu Chief Scrum Mastera/Agile Coacha, aby się upewniał, że rzeczy, które bierze na siebie zespół dzieją się i nie utykają w poszczególnych statusach. Powinien interesować się pracą swojego zespołu, odbierać zlecone zadania (co działa motywująco), wspierać w razie potrzeby w realizacji, pilnować terminów do których zobowiązali się Scrum Masterzy.

Wymiana wiedzy

Nie ma empirycznego środowiska pracy bez dzielenia się wiedzą. Dotyczy to nie tylko deweloperów, ale także Scrum Masterów. 

Często wraz z Maćkiem walczyliśmy o/wspieraliśmy/tworzyliśmy takie miejsca, gdzie deweloperzy mogli się wymieniać wiedzą, rozmawiać o zmianach, sukcesach, porażkach, wszystko po to, by następny projekt był lepszy, bardziej przewidywalny, bardziej poukładany. 

To samo dotyczy Scrum Masterów. Nie można sobie pozwolić na brak rozwoju – to harakiri. Środowisko nas otaczające bardzo szybko się zmienia, proces, który działał rok temu może zupełnie nie pasować do miejsca, w którym organizacja się znajduje w danym momencie. 

Warto zagwarantować czas na wymianę wiedzy. To nie może być jedno spotkanie raz na jakiś czas, ono musi być nawykiem i być pielęgnowane. Ważne jest to, aby propagować wiedzę co i w którym zespole się dzieje, tak, aby nie utykała ona na linii Chief Scrum Master/lider SM – Scrum Master, bądź, co gorsza, na linii Scrum Master – Zespół Deweloperski/PO. Od czasu do czasu warto przedyskutować jak wyglądają poszczególne spotkania scrumowe w zespołach, zweryfikować czy trzymamy się standardów, czy nie wkradają się jakieś złe praktyki, których z racji długiego stażu w którymś zespołów nie zauważamy, ale przede wszystkim czy nie da się czegoś usprawnić. Pamiętajmy, że takie spotkania nie mają na celu kontroli, a empiryczne doskonalenie procesu, wzajemną pomoc. Rozmawiajcie z sobą, dzielcie się wiedzą, szukajcie miejsc do usprawnień. Jeśli ktoś zakwestionuje Wasze poczynania – nie obrażajcie się (choć trudny feedback też trzeba umieć przekazać w odpowiedni sposób). Zastanówcie się chwilę nad odpowiedzią i spróbujcie “wyjść” ze swoich butów, zamiast z automatu odpowiadać “nie da się”, “nie zrozumiesz”. 

Warto zastanowić się nad jakimś miejscem, gdzie nie tylko Scrum Masterzy, ale i wszyscy pracownicy zainteresowani agile będą mogli porozmawiać. Na naszych łamach pisaliśmy już o tym, jak sprawnie zorganizować firmowe Agile Community of Practice – przestrzeni na rozmowy o ciekawych wystąpieniach, TEDexach, książkach czy trendach na rynku. Zorganizowanie i rozkręcenie tego to robota dla nikogo innego, jak Scrum Masterów. 

Oprócz rozmów i spotkań, dobrym sposobem na propagację wiedzy jest działalność piśmiennicza. Warto sobie ustalić, co, po co, gdzie i kiedy publikujemy. Może to być firmowa WIKI/Confluence, blog czy nawet posty na komunikatorze. Ważne, aby przy każdej możliwej okazji starać się przekazać jak najwięcej przydatnej wiedzy.

Przykładowo – co jakiś czas publikujemy duży tekst na zewnętrznego bloga firmowego. Jeżeli robimy to dobrze, to wzmacniamy markę pracodawcy, pokazujemy jak można u nas fajne pracować, po drugie przyczyniamy się środowisku praktyków agile i dokładamy cegiełkę, a nuż komuś nasza opowieść coś nasunie/zainspiruje. 

Drugą aktywnością jest ta wewnątrzfirmowa, na przykład raz na dwa tygodnie publikujemy mniejszy artykuł, ale za to z opowieściami prosto z frontu firmowych projektów – tam już możemy pisać o konkretnych sytuacjach z których odrobiliśmy lekcję i dzięki nim usprawniliśmy proces. Mogą znaleźć się tam przemyślenia z retrospektyw, porady jak przeprowadzić efektywnie spotkanie, czemu programowanie w parach jest wartościowe itp.

Kolejnym miejscem na propagację wiedzy przez Scrum Masterów są wszelakie, cykliczne spotkania na których pojawia się biznes oraz IT (coś a’la spotkania synchronizacyjne), gdzie można już bardziej w formie zwięzłych komunikatów ogłaszać zmiany. Na przykład wprowadzenie nowego procesu, aktualizacja Definition of Done, przypomnienie o tym, że ciągle obowiązuje jakiś zakurzony dokument.

Reasumując tę część – wykorzystujcie każdy możliwy moment, aby pokazywać dobre przypadki, propagować prawidłowe zachowania, ale i pokazywać wyciągnięte wnioski z porażek. Rozmawiajcie jak najwięcej w zespole scrummasterskim i wspólnie wyciągajcie wnioski, które w późniejszym czasie wprowadzicie w życie.

 Na koniec

Uwierzcie mi – praca w zespole scrummasterskim to nie jest łatwy kawałek chleba, przełożony takiego zespołu musi włożyć kawał serca, aby mógł on działać bez dysfunkcji. W zasadzie świetnie cechy takiej osoby opisują wartości scrumowe, czyli lider taki powinien być:

  • otwarty (na opinie innych, podejścia do rozwiązywania problemów, realizacji zadań)
  • skupiony (na celach stojących przed zespołem, wsparciu go w ich realizacji) 
  • zaangażowany (w życie tego zespołu, proaktywne podejście do problemów, wspieranie Scrum Masterów w rozwijanie zespołów)
  • odważny (aby doprowadzić do tego, aby różnorodność stała się atutem, a nie problemem) 
  • kierujący się szacunkiem.

W mojej opinii te przymiotniki świetnie odzwierciedlają cechy/zachowania, którymi na co dzień powinien się kierować lider takiego zespołu (choć te wartości… świetnie pasują do dowolnej roli w firmie ;)) Posiadając te cechy, trzeba teraz przystąpić do właściwej organizacji życia, rytmu i sposobu funkcjonowania zespołu, co również jest dużym wyzwaniem.

Rola Agile Coacha/Scrum Mastera, który prowadzi zespół scrummasterski zdecydowanie powinna się pojawić w każdej organizacji, która zatrudnia kilku Scrum Masterów. Dzięki temu, różnorodność osób pracujących na tym stanowisku zostanie przekuta w atut, a zespołu nie sparaliżuje bezwład decyzyjny. 

#Scrum#ScrumMaster