Eskalacja

Każdy, kto trafia do środowiska agile’owego z zewnątrz spotyka się z barierą językową. Dla jednych nie będzie ona przeszkodą i szybko odnajdą się w “stand-upach” i “Sprintach“. Inni długo będą zgadywali, czym jest ta “eskalacja” podobno wykonywana przez Scrum Mastera.

 

Eskalacja – Scrum Master edition

Zacznijmy przewrotnie, nie od słownikowej definicji, a od przypomnienia zadań Scrum Mastera. Wśród nich jest coś, o czym wszyscy zawsze pamiętają, czyli wsparcie Zespołu Deweloperskiego i obrona przez kłodami rzucanymi pod ich nogi.

“Scrum Master służy pomocą Zespołowi Deweloperskiemu na kilka sposobów, na przykład (…) usuwając przeszkody ograniczające postępy Zespołu Deweloperskiego” – Scrum Guide

Wspomniane w Scrum Guide usuwanie przeszkód to wcale nie “służebna” funkcja SM-a. Dobry Scrum Master daje wędkę, a nie rybę – rozwiązuje problemy zespołu wyposażając go w umiejętności potrzebne do poradzenia sobie z podobnymi sytuacjami w przyszłości. Dba też o to, żeby to co przekaże jednej osobie, zostało rozpropagowane w zespole.

Największa pułapka czyhająca na nowych SM-ów to pozwolenie zespołowi na wysługiwanie się nim. Nie ma nic gorszego niż przyzwyczajenie Development Teamu do tego, że “SM nam to załatwi”. Kończy się to zwykle totalnym brakiem czasu biednego SM-a na cokolwiek, a już na “zwiększanie efektywności wykorzystania Scruma” w szczególności.

Domyślnym działaniem zawsze powinno być dążenie do samodzielnego rozwiązania problemu przez zespół. A jeśli się nie da? Wtedy właśnie pojawia się eskalacja problemu.

 

Eskalacja problemu

Nadszedł ten moment, w którym możemy sięgnąć do naszego ulubionego Słownika Języka Polskiego i zmierzyć się z naszą znajomością słowa “eskalacja”. Nie powinno tu być takich problemów jak przy trójce metodologia, metodyka i metoda, ale nie zaszkodzi przypomnieć sobie, że

“eskalacja [to] stopniowe zwiększanie, potęgowanie się czegoś” – SJP PWN

W kontekście pracy Scrum Mastera często słyszy się o “eskalacji problemu”, co jest dość przydatnym skrótem myślowym. Dosłownie zwrot ten oznaczałby “potęgowanie się problemu”, czyli pogarszanie się naszej sytuacji. Chodzi nam jednak o coś zupełnie innego.

Tak naprawdę mamy na myśli “eskalację rozwiązania problemu” czy też “eskalację wagi osób, których próbujemy zainteresować”. Mówiąc wprost, chodzi nam o robienie coraz większego szumu wokół tego problemu. Im więcej osób o nim wie i im więcej traktuje go poważnie, tym większa szansa na jego rozwiązanie.

Trzeba pamiętać, że nasz kross-funkcjonalny zespół ma zwykle szerokie kompetencje i jest w stanie poradzić sobie z wieloma wyzwaniami. Gdy jednak coś wykracza poza nasze możliwości, trafia to do Scrum Mastera. Ten z kolei wiele rzeczy jest w stanie załatwić od ręki. Jeżeli zaś i on polegnie w walce z naszym problemem – dochodzi do eskalacji.

 

Różne drogi eskalacji

W tym miejscu konieczna jest mała dygresja i przypomnienie, że Scrum Master wspiera także Product Ownera i samą organizację. To znaczy, że problemy pochodzące z tych dwóch źródeł również będą przez niego eskalowane.

Co to jednak znaczy “eskalacja” w kontekście problemów z Agile Mindsetem w organizacji? Czy Scrum Masterzy powinien zebrać się razem i ruszyć do gabinetu prezesa, żeby zwrócić jego uwagę na nasze bolączki?

Zasadniczo – tak. Nie ma co się obawiać reakcji osób “wyżej postawionych”, a już na pewno nie powinniśmy przejmować się hierarchią w Scrum. Róbmy co do nas należy, ale w sposób zgodny z przyjętym podejściem.

Eskalacja to “stopniowe zwiększanie”. Nie ma sensu robić afery o drobnostki, jeżeli problem może zostać rozwiązany lokalnie. Bardzo często pierwszym krokiem nie powinna też być próba neutralizacji “wyzwania”, ale zabezpieczenie się przed jego negatywnymi skutkami.

Klasyk o nazwie “środowisko testowe jest niestabilne” może być trudny do rozwiązania i wymagać zmian systemowych. Odpowiedź na pytanie “co my jako zespół możemy zrobić, żeby nam to nie przeszkadzało?” jest o wiele prostsza. Eskalacja prośby o dedykowany serwer na potrzeby zespołu ma większe szanse powodzenia.

 

Eskalacja przez zespół

Tak jak wspominałem od samego początku i tak jak zawsze mówimy na naszych Szkoleniach dla Scrum Masterów – im więcej rzeczy zespoły będą robił samodzielnie, tym lepiej SM wykonuje swoje zadania. Idealnie byłoby, gdyby do SM-a nie trafiały żadne problemy, bo zespół jest w stanie wszystkie je rozwiązać samodzielnie.

A to znaczy, że musimy uczyć eskalacji. Bo niczym w bajce Ezopa o chłopcu, który wołał o pomoc, jeżeli będziemy robili aferę z każdej drobnostki, to nikt nie będzie traktował nas poważnie. Z drugiej zaś strony, jeżeli będziemy męczyć się próbując samodzielnie rozwiązać problemy wykraczające poza nasze kompetencje, to utkniemy w miejscu.

Uczmy więc zarówno siebie, jak i zespoły, właściwych ścieżek eskalacji i drogi do rozwiązywania problemów. To jest przecież jedno z zadań Scrum Mastera.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: