Szacunek to jedna ze scrumowych wartości, którymi powinni kierować się wszyscy pracujący w tej metodyce. Czasami jednak tego szacunku brakuje i jakoś tak się składa, że bardzo często dzieje się to na linii Developerzy – Scrum Master. Zobaczmy, z czego to wynika i co z tym można zrobić.
Brak szacunku to jeden z wielu rozpowszechnionych problemów, który napotykamy w Zespołach Scrumowych. Omawialiśmy go we trójkę na #białkowym kanale YouTube. Dziś przedstawię krótkie podsumowanie, jak go diagnozować.
Ze Scrum Guide’a wiemy, że 0powiedzialność Scrum Mastera w Zespole Scrumowym musi pełnić osoba objęta szacunkiem w zespole oraz w organizacji. Wiemy też, że Szacunek jest jedną z wartości Scruma, z których wszystkie są niezbędne do zbudowania zespołu o wysokiej wydajności.
Ale co jeśli jesteśmy w sytuacji, gdzie mamy już zespół oraz Scrum Mastera, lecz nie ma szacunku do SM-a ze strony Developerów? Widziałem takie sytuacje osobiście. Ich skutkiem zwykle jest to, że Scrum Master nie potrafi wykonywać jednego ze swoich głównych obowiązków – pomagać zespołowi być maksymalnie wydajnym. Developerzy nie będą liczyć się z jego czy jej opinią, będą całkowicie odporni na coaching i mentoring ze strony takiego SM-a, ponieważ nie będą wierzyli, że ten Scrum Master potrafi zrobić coś pożytecznego dla nich. To z kolei spowoduje, że problemy nie będą rozwiązywane, a często nie będą nawet zgłaszane. Jest szansa że taki zespół będzie funkcjonować i nawet dostarczać Przyrosty. Natomiast, nie ma szans żeby zespół ten osiągnął swój potencjał.
W gruncie rzeczy, brak szacunku do SM-a ze strony Developerów zawsze jest spowodowany tym, że zespół nie widzi żadnych korzyści dla siebie w pracy z tą osobą. Natomiast powody dlaczego tak jest, są różne.
Najczęstszym scenariuszem jest to, że Developerzy traktują zasady Scruma jako dręczące formalności. Oni nienawidzą chodzić na Retro: „znowu będziemy musieli wymyślać coś na siłę, żeby od nas się odczepili”. Daily Scrum jest spotkaniem typu status update – każdy mówi parę zdań o swoich zadaniach, ale nikt szczególnie nie słucha. Te wszystkie wydarzenia wydają się być przeszkodą, która tylko zabiera czas, potrzebny na pisanie kodu. Jeśli widzimy takie objawy u siebie, to znaczy, że nasi Developerzy nie rozumieją Scruma. Kto jest w tym winny? Oczywiście, Scrum Master, bo właśnie on jest odpowiedzialny za to, żeby zespół rozumiał ten cały Scrum.
Skoro Scrum Master nie nauczył ich tego, to albo sam nie posiada tej wiedzy, albo nie umie im tej wiedzy przekazać. W jednym i w drugim przypadku znaczy to, że jest niekompetentny i musi się doszkolić – w Scrumie albo w przekazywaniu wiedzy. Być może też nie rozumie perspektywy Developerów i nie potrafi rozmawiać w ich języku. Tu zdecydowanie łatwiej jest osobom posiadającym techniczny background, bo tacy SM-i wiele razy widzieli tę sytuację z obu stron. Ale głównym czynnikiem jest nie ten background, tylko empatia. Dobry SM musi być dobrym komunikatorem, rozumieć podejścia i perspektywy innych ludzi, potrafić oceniać atmosferę w zespole i rozwiązywać konflikty. Człowiek bez tych umiejętności powinien je jak najszybciej zdobyć albo zmienić zawód.
Kolejną sytuacją, w której możemy spotkać braku szacunku do SM-a, jest ta kiedy podstawowe zasady Scruma są przestrzegane i rozumiane przez zespół, ale nie ma tych bardziej głębokich. Nie ma inspekcji – ludzie nie mówią otwarcie o problemach, które powstają albo nie ma adaptacji – problemy są zgłaszane, ale nie są rozwiązywane. Wtedy problem zwykle polega na tym, że SM nie stworzył środowiska, gdzie ludzie sobie ufają i wiedzą, że mogą wszystko powiedzieć albo SM nie pilnuje, żeby zgłaszane przeszkody były usuwane.
Są też powody, które nijak nie są winą Scrum Mastera. Scrum nie jest dla każdego. Są ludzie, którzy nie potrafią w nim pracować i może powstać sytuacja, gdzie zespół jest złożony głównie z takich właśnie osób. Wtedy nawet bardzo dobry SM może nie być w stanie uzyskać szacunku z ich strony. Może być też tak, że SM nie ma odpowiedniego umocowania w organizacji żeby usuwać przeszkody czy wprowadzać zmiany, które umożliwiłyby zespołowi zwiększenie efektywności. Niektóre firmy, choć uważają inaczej, nie są gotowe na pracę w Scrumie.
Jak widać, jest kilka scenariuszy tego problemu, a każdy z nich ma inne źródło. Graf poniżej powinien pomóc szybko zidentyfikować, skąd w naszym otoczeniu bierze się brak szacunku dla Scrum Mastera. I tu ostatnia uwaga – nie każda sytuacja może mieć szczęśliwe zakończenie. Kierując się empiryzmem powinniśmy też być w stanie zauważyć, kiedy „nic z tego nie będzie” i… podjąć odpowiednie środki.
