Tylko dla doświadczonych Scrum Masterów

Skoro to czytasz, to pewnie masz już dwa lata doświadczenia jako Scrum Master, a może nawet więcej. Pewnie jesteś już nawet Agile Coachem (nawet jeżeli tak nie nazywa się Twoje stanowisko) i dla wielu osób jesteś autorytetem. Jesteś dumny z tego, że pomagasz mniej doświadczonym kolegom i koleżankom, i cieszysz się z tego, że są coraz lepsi w swojej pracy.

Twoje działania są też dobrze widoczne na poziomie firmowym. Z shu-ha-ri zdecydowanie jesteś na poziomie „ri” i marzą ci się duże zmiany w organizacji, które spowodują, że będzie ona działała lepiej – bardziej zwinnie – na każdym poziomie. Coraz więcej osób pyta Cię o zdanie, zanim podejmie decyzję, która mogłaby wpłynąć na procesy firmowe i zespołowe. Teraz Twoimi najważniejszymi działaniami są te, które pozwalają ulepszać organizację całościowo, bo od razu wpływają na wszystkie zespoły, a nie tylko jeden czy dwa, jak to było dotychczas. Masz świetne pomysły i dokładnie wiesz, jak powinien działać dobry… co tam dobry… świetny Scrum Master!

Otwarcie się do tego nie przyznasz, ale wczoraj podśmiewałeś się po cichu z młodego Scrum Mastera, który jeszcze nie do końca rozumie co to znaczy „agile” i traktuje wszystko co napisane w Scrum Guide co do literki. Dyskusje prowadzi w komentarzach do zadania, a każdego nieprzygotowanego idealnie interesariusza odsyła z kwitkiem. Widać, że jeszcze nie wie, o co w tym wszystkim chodzi.

I wtedy, któregoś dnia, ktoś mówi, że coś się nie udało, bo Ty nie dopełniłeś swoich obowiązków. Ale jak to?! Przecież nie przychodzisz do pracy po to, żeby siedzieć na fejsie! Każdą minutę poświęcasz na to, żeby w firmie było lepiej! Nawet przerwy skracasz do minimum, żeby zrobić jak najwięcej. Jednym tchem możesz wymienić całą listę sukcesów, za którymi stoisz. Co prawda były sygnały ostrzegawcze, ale wmawiałeś sobie, że to nic takiego i to tylko wyjątki potwierdzające, jak dobrze pracują Twoje zespoły.

Na początku chcesz powiedzieć, że to nieprawda i to tylko pomówienia. Przyglądasz się jednak sytuacji i stwierdzasz, że to Ty się mylisz, a ta osoba ma rację. Pochłonięty “wyższymi celami” zapomniałeś o części swoich podstawowych obowiązków. Dopuściłeś do sytuacji, w której wymagania do zadań, realizowanych przez Twój Zespół, są marnej jakości. Nie mówią wystarczająco dokładnie, co się mieści w ich zakresie, a co nie. I nie chodzi tylko o wymagania na Backlogu, ale też o te, które są już na Sprincie, a nawet są już zrealizowane. Zespół nie zaprotestował, a Ty ich nie ochroniłeś! Nie byłeś wystarczająco asertywny i stanowczy w stosunku do Product Ownera i interesariuszy.

Po dokładniejszej analizie okazuje się, że cały Backlog przedstawia obraz nędzy i rozpaczy. Niby to zadanie PO, ale to Ty powinieneś mu pomóc. PO jest oceniany negatywnie, ale Ty też. Co gorsza, dochodzi prawo serii i Twój Zespół zalicza wpadkę na Review Sprintu. Im też nie poświęcałeś ostatnio za dużo czasu. Osoby, które do tej pory patrzyły na Ciebie z podziwem, teraz już nie są Ci aż tak przychylne. Sam na siebie patrzysz inaczej i zastanawiasz się, jak mogłeś do tego dopuścić. Przecież dobrze znasz te podstawowe zasady gry. A miało być tak pięknie…

Dlatego, gdy już skupiasz się na “wyższych celach”, nie zapomnij o swoich zespołach. Więc jeżeli ten wpis zapalił w Twojej głowie czerwoną lampkę, koniecznie zrób audyt obecnej sytuacji (możesz do tego wykorzystać na przykład Squad Health Check model). I napraw wszystko, co uznasz za niezbędne. Po pierwsze – Zespół Deweloperski. Po drugie – Product Owner. Dopiero gdy jesteś pewien, że w tych obszarach nie masz sobie nic do zarzucenia, zajmij się „wyższymi celami”.

Dbaj o swoje zespoły, bo drobne pozytywne zmiany każdego dnia dają często większe efekty niż jednorazowa zmiana na poziomie organizacji.