Jest dużo zespołów oraz organizacji, które myślą, że mają Scruma, a w rzeczywistości nie przestrzegają jego zasad, – i nie zyskują jego korzyści. Mają wtedy wszelkie rodzaje ScrumButów oraz Zombie Scrumów. Prawie zawsze takie zespoły są sterowane przez Pseudo-Scrum Masterów, co z kolei jest jednym z głównych powodów braku zwinności. Kim są Pseudo-Scrum Masterzy i co z nimi robić?
Wiem, że termin Pseudo-Scrum Master brzmi złośliwie, niczym uzurpator cesarstwa Rosyjskiego Dymitr Samozwaniec. Na szczęście tu nie chodzi o złe zamiary, tylko o problem kompetencyjny samej organizacji. Zacznijmy od tego, kim właśnie jest ten Pseudo-ScrumMaster?
Tak się często dzieje, że odpowiedzialność SM-a pełni ktoś, kto nim nie jest. Jakiś manager, analityk biznesowy, tech lead czy zwinny Developer dostaje dodatek do swoich codziennych obowiązków: „Teraz będziesz Scrum Masterem”. Jeśli ta odpowiedzialność nie jest wciśnięta konkretnej osobie na siłę, to po prostu zespół zostaje poinformowany, że muszą wybrać sobie SM-a spośród siebie. Tak lub inaczej, Scrum Masterem zostaje ktoś, kto szczególnie nie interesuje się tym ani nie ma głębokiej wiedzy o zwinności. Z jego czy jej perspektywy to wygląda następująco: „Dalej muszę pisać kod/testy/zarządzać projektem plus przeprowadzać Daily oraz planowanie Sprintu”. Ile problemów widzicie w tym zdaniu?
Po pierwsze, ta osoba dalej widzi siebie jako Managera lub Developera i nadal jest skupiona na rozwoju swoich umiejętności w tym kierunku. W wielu firmach ten rozwój jest oceniany raz na jakiś czas pod czas performance review. Główny fokus tej osoby jest nie na tym, żeby umożliwić efektywne działanie zespołu w Scrumie, ale na sobie i „swoich” celach.
Po drugie, ta osoba nie posiada wystarczającej wiedzy o Scrumie, żeby być efektywnym Scrum Masterem. Z jej perspektywy, Scrum Master – to osoba, która przeprowadza Daily i Planowanie Sprintu. Z mojego doświadczenia Retro często w ogóle jest pomijane.
Po trzecie, ta osoba też nie widzi potrzeby w tym, żeby zwiększać swoje scrumowe kompetencje. „Kazali mi przeprowadzać ceremonie Scrum, ja to robię, nikt nie narzeka”. Po co spędzać czas na szkoleniach ze zwinności, skoro szef nie mówi, że „za mało w tym Scrumie robisz!”. Lepiej przygotować się do kolejnego performance review, które rozlicza nas z różnych umiejętności „twardych”. Lepiej pójść na szkolenie ze wzorców projektowych.
Z czego ta cała grupa problemów się wywodzi? Pisałem kiedyś o tym, dlaczego Developerzy nie rozumiej Scruma. Poniżej znajduje się krótkie podsumowanie tego problemu, po bardziej wylewny opis zapraszam do oryginalnego postu.
Zaczynając swoją karierę Developerską, świeży Junior trafia do firmy w której stwierdza się, że „Jesteśmy zwinni i działamy w Scrumie!”. Niestety, najczęściej działają oni w jakimś ScrumBut, ale Junior tego nie wie. Więc utrwala sobie, że Scrum polega na tym że „mamy Sprinty i Daily”. Jeśli poczyta jakąś teorie na temat zwinności, to jest duża szansa, że nie zauważy żadnego problemu, bo teoria jest nudna a „ja i tak to wszystko wiem bo w tym pracuje”. Większość firm już odeszła od prawdziwego Waterfalla, ale nie przeszły do końca transformacji zwinnej. Są gdzieś pomiędzy jednym a drugim. Dlatego nie ma w tych firmach środowiska, gdzie człowiek mógłby nauczyć się, na czym rzeczywiście polega ten agile. Powstaje pewny zamknięty krąg:
Co z tym wszystkim można zrobić? Jedna z opcji w sytuacji kiedy mamy w firmie parę (wielu?) Pseudo-Scrum Masterów to zapewnić im możliwość dokształcenia się w tym kierunku. W większych korpo nierzadko może się znaleźć jakiś dobry Agile Coach, który mógłby tym się zająć. W moim doświadzceniu, w dużych korpo jeden projekt różni się od drugiego jak raj od piekła – także nie wyłączam, że w jednym dziale będą dobre kadry Scrumowe, a w innych – totalna porażka. Jeżeli nie mamy pod ręką kompetentnego Agile Coacha, to można tych Pseudo-Scrum Masterów wysłać na szkolenia zewnętrzne lub zatrudnić AC, który by ich szkolił i się nimi opiekował.
I tu nie można pominąć jednego ważnego aspektu. Mimo, że powyższy scenariusz może zadziałać, moim zdaniem jest on daleki od ideału. Sam fakt tego, że przejęcie roli SM-a jest wciskane członkom zespołu na siłę mówi o tym, że zarząd zbyt mało wie o tym, czym jest Scrum. Ewidentnie nie widzą korzyści w posiadaniu kwalifikowanego, dedykowanego SM-a skoro próbują zastąpić go kimś, kto nie jest odpowiednio kompetentny. Nawet jak sfinansują tym ludziom szkolenia czy mentora, to nadal nie są to właściwi ludzie na właściwym miejscu – z pasją do zwinności, z powołaniem. Są to ludzie, którzy chcą pisać kod, testy lub wykonywać cokolwiek innego w czym kształcili się wcześniej. Natomiast, dedykowany SM może zastąpić 3-5, a czasem i więcej Pseudo-Scrum Masterów, a do tego wykonywać ich pracę lepiej.
Tu może paść pytanie: „A czy nie jest tak, że każdy Scrum Master najpierw wykonywał inna rolę na projekcie, a potem się przekształcił?” To prawda, że najczęściej tak jest. Każdy z autorów tego bloga przez to przeszedł. Różnica jest taka, że to był nasz dobrowolny wybór. Mieliśmy wystarczająco dużo motywacji, żeby się doszkalać poza godzinami pracy. Ja łączyłem przez jakiś czas odpowiedzialności SM-a oraz Developera i doszedłem do wniosku, że muszę wybrać jedno, żeby robić to dobrze. Wiadomo, co wybrałem. Takie zjawisko prędzej nazwałbym Junior Scrum Master niż Pseudo SM. Choć obaj nie są zbyt doświadczeni, motywacja oraz fokus czynią niemałą różnice na korzyść Juniorów.
Mówiąc o Juniorach… Z czasów, kiedy jeszcze byłem Developerem, pamiętam, że w każdej firmie gdzie pracowałem był pewien system kompetencyjny. Pewna definicja, jaka wiedza oraz doświadczenie czyni kogoś Juniorem, Regularem lub Senior Developerem czy Leadem. Programista, który chciał podwyższyć swoje kwalifikacje mógł uzyskać dokładną informację, czego musi się poduczyć. Często nawet dostawał mentora o wyższym poziomie, który mu w tym pomagał. Taki system zapewniał wysoką jakość kadr technologicznych w firmie. Podobny system powinien być i dla kadr zwinnych, jeśli tylko firma traktuje własną transformację zwinną na poważnie. To powinno zabezpieczyć projekty przed sterowaniem przez Pseudo-Scrum Masterów, umożliwić kształcenie dobrych Juniorów oraz awans bardziej zaawansowanych SM-ów i Agile Coachów oraz polepszyć poziom rozumienia zwinności przez wszystkich innych uczestników procesu (Developerów, zarząd, interesariuszy). Pomoże to także uniknąć sytuacji, kiedy chcemy wcisnąć Scrum na siłę tam, gdzie nie jest on potrzebny. Pamiętajmy, że Scrum nie jest dla każdego.
