Czy istnieje coś takiego jak "zbyt duża przejrzystość w organizacji"? Czy są jakieś granice, do których przejrzystość stworzona przez Scrum Mastera nie powinna sięgać? Patrząc na filary Scruma, wyraźnie widzimy: przejrzystość, inspekcję i adaptację jako podstawowe przekonania, na których opiera się Scrum. Ale co, jeśli doprowadzimy przejrzystość do ekstremum...? Zobaczmy, co się stanie.
Przypadek #1
Scrum Master od pewnego czasu współpracuje z Zespołem Scrum, budując fundamenty zaufania i wzajemnego szacunku. Jest aktywnym uczestnikiem codziennego życia zespołu, bierze udział we wszystkich wydarzeniach Scrum i ceni sobie wirtualne kawy, podczas których prowadzi rozmowy jeden na jeden. Podczas prywatnej rozmowy z jednym z programistów, Scrum Master zauważa niedawny spadek jego wydajności i pyta, czy zaszło coś, co mogłoby to wyjaśnić, oferując swoją pomoc. Wie, że bezpośredni przełożeni również to zauważyli w ciągu ostatnich dwóch Sprintów. Programista, w zaufaniu, opowiada o problemie osobistym, który wymaga obecnie więcej jego uwagi, niż przewidywał. Ma już plan, jak rozwiązać tę sytuację i zapewnia, że wróci do formy w ustalonym czasie.
Po tej rozmowie, manager programisty zwraca się do Scrum Mastera z pytaniem o sytuację. Rozmowa ta może pójść w różne strony - bezpośrednie przekazanie informacji uzyskanych od programisty może narazić na szwank zaufanie i szacunek.
Jednak czy chodzi tutaj rzeczywiście o transparentność? Transparentność może oznaczać uznanie prywatności tej rozmowy i zapewnienie managera że zostaną podjęte odpowiednie kroki. Jako Scrum Master możemy również pragnąć zapewnić bezpieczną przestrzeń dla naszego programisty i kierownika, by mogli razem omówić, jak najlepiej poradzić sobie z tą sytuacją. Istnieje wiele sposobów na zarządzanie tą sytuacją, bez konieczności tracenia zaufania.
Teraz spójrzmy na inny przypadek, bardziej ogólnie.
Przypadek #2
Organizacja stoi na początku swojej drogi do stania się zwinną. Wszystko jest nowe, ekscytujące, a zarazem nieco przerażające. Scrum Masterzy z entuzjazmem starają się wyjaśnić znaczenie Przeglądów Sprintów i pokazują wartość prezentacji prac różnych zespołów, co sprzyja budowaniu przejrzystości w całej organizacji. W jednym z nowo utworzonych zespołów, podczas jednego z pierwszych Przeglądów Sprintu, Scrum Master zachęca zespół do dzielenia się napotkanymi przeszkodami i wyzwaniami. Zespół jednak wykazuje opór przed publicznym omawianiem tych kwestii. Scrum Master, kierując się najlepszymi intencjami wobec zespołu i chcąc promować transparentność, postanawia samodzielnie przedstawić te problemy, ignorując wątpliwości zespołu. Jego intencją jest: "Podzielę się tymi problemami, a interesariusze zareagują i podejmą działania".
Ale czy naprawdę osiągnęliśmy to, co zamierzaliśmy?
Jego działania prowadzą do utraty zaufania zespołu do Scrum Mastera - nie byli oni gotowi do dzielenia się swoimi problemami. Co gorsza, interesariusze i organizacja nie byli przygotowani na usłyszenie o wszystkich tych problemach naraz, podczas tego wydarzenia. Poczuli się zagrożeni, jakby te problemy stanowiły bezpośredni atak na ich sposób pracy, a przez to na nich samych.
Efekt? Organizacja staje się jeszcze bardziej oporna na zmiany, obawiając się, że "ten scrum" wyeksponuje ich w niekorzystnym świetle. Zamiast otwarcie mówić o procesach, które wymagają poprawy, menedżerowie są jeszcze bardziej sceptyczni wobec przyjęcia zwinnych metodyk, zaniepokojeni postępowaniem Scrum Masterów.
Sytuacja nie została odpowiednio obsłużona, a omówione wyżej aspekty nie zostały należycie rozważone. Aby osiągnąć tak wysoki poziom transparentności, musimy najpierw zademonstrować wartość płynącą z małych zmian w procesie i osiągnąć choćby minimalną zmianę w sposobie myślenia, skierowaną ku rozwiązywaniu problemów, a nie ich osobistemu odbieraniu jako porażek.
Przypadek #3
Scrum Master dowiedział się o nowej zmianie w zarządzaniu organizacją, która bezpośrednio dotyczy Product Ownera. W kontekście dążenia do zwinności i budowania odpowiedzialności pojawia się pomysł, aby zlikwidować stanowisko Technical Product Ownera, zostawiając tylko Business Product Owners. Zmiana ta wpisuje się w zasady Scruma, zakładające jednego Product Ownera na produkt. Jednak szczegóły, dokładne daty i zakres obowiązków wciąż są ustalane. Scrum Master dowiedział się o tym podczas nieformalnej rozmowy przy kawie, dzięki czemu zdał sobie sprawę, że w zaprezentowanym podejściu brakuje transparentności, a obaj Product Ownerzy powinni być w proces zmiany zaangażowani. W związku z tym, zdecydował zorganizować na następny dzień spotkanie z oboma PO, sobą i osobą, z którą rozmawiał.
Obaj Product Ownerzy są zestresowani, niepewni co do tego, co zmiana będzie dla nich oznaczać, i czy któryś z nich straci pracę. Osoba rozmawiająca ze Scrum Masterem również czuje stres – to, co miało być przyjazną rozmową przy kawie, nagle wpłynęło na więcej osób. Spotkanie to nie przynosi rozstrzygnięć; brakuje osoby odpowiedzialnej, a rozmowa zmienia się w niepokojącą grę w zgadywanie. Napięcie wzrasta.
Można by powiedzieć, że Scrum Master zrobił, co do niego należało – upewnił się, że wszyscy bezpośrednio dotknięci zmianą są o niej poinformowani.
Jednak, aby rzeczywiście zapewnić transparentność, Scrum Master powinien był najpierw zebrać wszystkie niezbędne informacje. Dowiedzieć się, kto odpowiada za te decyzje, dlaczego zostały podjęte, kto będzie w nie zaangażowany. Działając pochopnie, mógł niechcący wywołać panikę i plotki, zanim jeszcze plan stał się jasny dla wszystkich, na przykład za dwa tygodnie, kiedy proces konsultacji z PO już miałby miejsce.
To tylko jedna z wielu sytuacji, które obserwowałam jako Scrum Master, gdzie transparentność była pojmowana jako wszystko albo nic.
Widzimy zatem, że pełna transparentność w organizacji wymaga określonych zachowań, zmiany sposobu myślenia i jasnych granic. Należy opierać się na danych, a nie tylko na opinii czy plotkach.
Oczywiście, to tylko część rozważań na temat transparentności. Pamiętajmy, że budowanie transparentności to proces wymagający czasu, a nie jednorazowa akcja.
