2 grudnia 2019
Maciej Wilmiński
Scrummasterskie chowanie głowy w piasek
Jak już jakiś czas temu pisałem, za waterfalla było lepiej, a przede wszystkim w wielu aspektach łatwiej
Project Manager – zło dla dewelopera, dobro dla organizacji?
Ot, na przykład istniała rola/stanowisko (IT) Project Manager. W skrócie – była to osoba od nadzoru realizacji projektu – pilnowania budżetu i zakresu, raportowania postępów “wyżej”, planowania prac oraz pilnowania żeby szły one zgodnie z tym co zaplanowano, a przede wszystkim w czasie jakim zaplanowano (w rzeczywistości najczęściej jakim sama zaplanowała). Było to zajęcie trudne i niedocenianie.
Na przykład z punktu widzenia dewelopera – osoba tego typu jednoznacznie reprezentowała zło. Nieustannie przychodziła i pytała się: jak idzie i drążyła: dlaczego tak wolno, skąd biorą się problemy, potrafiła pięć(dziesiąt) razy zapytać: dlaczego? Nierzadko oceniana bardzo negatywnie jako totumfacki, upierdliwiec, zawracacz głowy, postrzegana jako część firmowej kamaryli, a jeśli nie był(a) osobą techniczną, to epitety były jeszcze ciekawsze. Jakkolwiek przez programistów postrzegana, rzadko z ich strony rozumiana i doceniana.
Z punktu widzenia “góry”, istnienie takiej roli jednak bardzo dużo ułatwiało, szczególnie w kontekście tego kogo informować o decyzjach (ew. z kim je ustalać), pytać o postępy i rozliczać z rezultatów. Nieprzypadkowo swego czasu sporą karierę w IT robił zaczerpnięty z Apple’a akronim DRI (Directly Responsible Individual), gdzie panaceum na typowy w dużych firmach brak widocznego postępu w określonych zobowiązaniach, miało być to, żeby każde zadanie, ustalenie, miało przypisaną osobę, mającą za to odpowiadać. Krył się za tym prosty mechanizm – jeżeli ktoś był głównym odpowiedzialnym, do tego odpowiednio umocowanym – nie miał wtenczas oporów przed przekazaniem osobom, od których był zależny (np. wykonawców projektu) tzw. “twardego feedbacku”, odpowiednim ich zmotywowaniu, szybką eskalacją problemów. Inaczej sam kładł głowę pod firmowy topór.
Deweloperzy mieli na kogo narzekać, natomiast organizacja miała jedną główną osobę odpowiedzialną za cały projekt, dbającą o to, żeby prace nad nim przebiegały prawidłowo. Która widząc, że coś dzieje się nie tak, natychmiast reagowała. A przynajmniej powinna, inaczej jej dalsze losy w organizacji nie rysowały się w różowych barwach.
Jak wspomniałem, praca na tym stanowisku nigdy nie należała do najłatwiejszych. Stąd dojrzałe organizacje starały się stawiać na osoby doświadczone, z dużą odpornością psychiczną i wiedzą co, jak i kiedy robić. Raczej nie zdarzały się osoby przypadkowe, wymagano sporego doświadczenia w branży, jak i samej organizacji
Nowa układanka
No i nagle pojawiły się agile i Scrum. Zło usunięto. Jednoosobowe sterowanie zmieniono w działania kolektywne. Uwierzono w dobro i wzajemną współpracę. I zaczęły się problemy.
Pojawiły się trzy role. Product Owner mający maksymalizować wartość produktu i pracy Zespołu Deweloperskiego, decydujący o kolejności wykonywanych prac, Scrum Master służebny przywódca, pomagający w tej maksymalizacji, mający wycisnąć z kultury agile i zasad Scruma maksimum, i w końcu Zespół Deweloperski, który w nowym świecie zyskał wiele nowych możliwości – stał się interdyscyplinarny, posiadający wszelkie potrzebne kompetencje, ale tym razem sam decydujący (uprawniony przez organizację do decydowania) o tym jak się zorganizować, jak pracować, ile pracy jest w stanie zrealizować w określonym czasie. Do tego podejście projektowe przekuto na produktowe, gdzie zamiast konkretnego zestawu wymagań do realizacji w przewidywanym czasie, powinniśmy działać na zasadzie krótkich cyklów, stopniowo rozwijających produkt, nawigując na bazie informacji zwrotnej od użytkowników, oraz backlogu, zbierającego wszystkie możliwe wymagania, które Product Owner musi odpowiednio spriorytetyzować.
Niezwykle wzmocniliśmy prerogatywy, decyzyjność i samodzielność zespołów deweloperskich, zbliżyliśmy do nich tzw. biznes, wymagając od jego przedstawiciela stałej, częstej obecności, a do wspierania obu tych stron dodaliśmy Scrum Mastera, mającego działać “na miękko”, poprzez przykład, dobre wzorce. Gdzie się podziali dotychczasowi Project Managerowie? Najczęściej zostali przekwalifikowani/przechrzczeni w role Scrum Masterów lub Product Ownerów. Sporo z nich świetnie się odnalazło w nowej rzeczywistości, niektórzy dalej szli starą ścieżką w innych firmach, a w niektórych firmach na zmianie nazwy stanowiska się skończyło, metody i działania pozostały takie same, a scrumowa fasada i słownictwo, wystarczyły żeby zakończyć transformację.
Co jest w tym wszystkim niezwykle ważne, a często zapominane, zarówno Schwaber i Sutherland, jak i siedemnastka od manifestu, postawili pewne “gwiazdki”, przypisy przy swoich założeniach, o których często się zapomina. Duet panów S zaczyna prezentację zespołu deweloperskiego od sformułowania złożony jest z profesjonalistów. Z kolei w agile manifesto mamy: twórzcie projekty wokół zmotywowanych ludzi. Niby naturalne sformułowania, nikogo dziwić nie powinny, z czasem jednak zaczynamy widzieć tu gdzieś, schowane między wierszami zastrzeżenie: to wszystko zadziała w przypadku dojrzałych, odpowiedzialnych, zmotywowanych osób.
Z czasem twórcy Scruma dodali jeszcze dwa akapity o pięciu wartościach, zaznaczając, że powodzenie w wykorzystaniu Scruma zależy od biegłości w postępowaniu z nimi, jednoznacznie wskazując, między innymi, że:
- Członkowie Zespołu Scrumowego mają odwagę postępować właściwie i przezwyciężać trudności
- Zespół Scrumowy i jego interesariusze zgadzają się pozostawać otwartymi na wszystkie aspekty wykonywanej pracy i związane z nią wyzwania.
Nikt nie reaguje? Jesteśmy zabezpieczeni… w teorii
Tyle teoria. Weźmy jednak na tapet przeciętny scrumowy zespół realizujący jakąś inicjatywę, czy to rozwijający produkt, czy realizujący jakąś większą funkcjonalność, dawniej projekt. I załóżmy, że nie wszystko idzie tak, jak powinno. Kolejne sprinty przynoszą rezultaty dalekie od oczekiwanych, pojawia się sporo błędów, ewidentnie widać, że funkcjonalności zostaną zrealizowane w czasie znacząco odległym od zapowiadanego, prognozowanego. Idealne pole do działania dla (IT) Project Managera. A jak jest w zwinnym świecie? Wcześniej – większość odpowiedzialności i oczekiwania skupiono na jednej osobie, która problem rozwiązywała bądź eskalowała. Teraz trzeba zadbać o wiele więcej spraw, bo odpowiedzialność jest nieco rozmyta, rozdystrybuowana w wielu miejscach.
Jeśli źle się dzieje, pierwszy powinien zareagować zespół. Scrum oferuje mu ku temu całą gamę możliwości, progres powinien być codziennie śledzony na Daily, a najpóźniejszym momentem, na którym należy coś zrobić z problemami, jest retrospektywa. To w ostateczności w jej trakcie członkowie zespołu powinni zauważyć, że nie ma oczekiwanych efektów. I na bazie wspólnych dyskusji, wypracować i wdrożyć jakieś rozwiązania.
Bardzo często bywa jednak tak, że zespół nie reaguje. Cisza.
Jeśli zespół nie reaguje, powinien wkroczyć Scrum Master. Spróbować skierować uwagę zespołu na problemy, zainicjować dyskusję na temat ich źródeł, zaplanować działania.
Często jednak i Scrum Master nie reaguje.
No to w końcu Product Owner, czyli ten mający maksymalizować wartość, choć nie do końca mający ku temu możliwości i narzędzia. Z reguły mający jeszcze mniejszą techniczną wiedzę niż Scrum Master. Jeżeli w zespole nie widać autorefleksji i chęci zmiany, a dodatkowo Scrum Master nie reaguje lub bezradnie rozkłada ręce, powinien wkroczyć on.
A co i jeśli tu jest cisza?
Są przecież jeszcze Przeglądy Sprintów, gdzie zespół, chcąc nie chcąc, powinien pokazać coś działającego. Gdzie powinni przychodzić interesariusze i oczekiwać zapowiedzianych na poprzednim przeglądzie rezultatów albo przynajmniej o nie delikatnie podpytać. A zatem logicznie – jeśli by nic nie zobaczyli, powinni zareagować.
Wydaje się, że konstrukcja Scruma zabezpiecza organizację ze wszystkich stron, do tego scrumowa transparencja i otwartość oraz praca w krótkich cyklach powoduje, że problemy powinny być odkrywane i ujawniane dużo szybciej, aniżeli bywało to dawniej. Nie powinno też być żadnej szansy na ukrycie czegoś pod dywanem, jak to drzewiej bywało, kiedy biznes oddawał projekt IT, wrzucając go do czarnej skrzynki, a następnie miesiącami oczekiwał efektów.
Do tego, wszystkie te zespoły nie działają w organizacyjnej próżni. Mają swoich przełożonych, którzy zapewne dopytują się o postępy, progres, problemy.
W teorii wszystko pięknie, w praktyce jakoś nie zawsze się to udaje. A, do diaska, miało być przecież lepiej! Jak to możliwe, że pomimo tych wszystkich mechanizmów, o których wspomniałem wyżej, nadal są problemy?
Przyjrzyjmy się najczęstszym ich przyczynom
1. Scrum Master całkowicie liczy na zespół
Dlaczego nie reaguje zespół?
Powodów może być naprawdę bardzo dużo.
Najpopularniejsze?
Bo tworzą go optymiści: to złe miłego początki, nadgonimy. Bo – w przeciwieństwie do tego jak było dawniej – w pracy agile’owej/scrumowej często panuje większy, wręcz nadmierny luz, nie ma już tego złego, który cisnął, w konsekwencji pojęcie sprintu jest typowo umowne, a w powietrzu krąży podejście no trudno, staraliśmy się, no ale nie ten sprint, to następny.
Bo to nie zespół, a grupa indywidualistów – w sumie każdy oddzielnie jest zadowolony z efektów swojej pracy, swoje zrobił, a, że nie wyszło zespołowo…. No i właśnie. Pół biedy, jeśli każdy działa indywidualnie, nie patrząc na efekty zespołu. Gorzej, jeśli ewidentnie widać, że ktoś dezorganizuje prace, nie przykłada się, jawnie ignoruje pewne zasady. A tu cisza. Dlaczego? Ileż to razy słyszałem pieklących się scrummasterów, że ewidentnie Gnuśniackiemu się nie chce, że jawnie się opierdziela, a oni nie reagują!!
A dlaczego nie reagują na sytuacje takie, jak powyższe? Nie potrzeba do tego ukończonych studiów z psychologii. Pamiętacie te przypisy w Przewodniku o Scrumie i Agile Manifesto, o których wspominałem wyżej?
Zanim będziemy mieli zmotywowany zespół profesjonalistów, potrzeba bardzo dużo pracy, stworzenia odpowiedniego środowiska i czasu na efekty. A te mogą czasami w ogóle nie przyjść.
Dawanie sobie szczerej informacji zwrotnej jest niezwykle trudne. Jest z tym problem w sytuacjach pracy 1:1, a co dopiero w grupie. Dlaczego, jako deweloper, mam się wychylać i publicznie komuś zwrócić uwagę – nadepnąć na odcisk, z tego mogą być tylko problemy. Lepiej nie dowieźć sprintu, niż stracić kumpla, albo zyskać wroga. Trudno się takiemu myśleniu dziwić.
To nie tylko kwestia zespołów deweloperskich, przyjrzyjcie się zespołom sportowym. Ile potrzeba czasu, żeby się wzajemnie dotrzeć, poznać wzajemnie swoje mocne i słabe strony, nauczyć się ze sobą szczerze, otwarcie komunikować. Weźmy sobie piłkę nożną. Czy młokos, który właśnie dołączył do kadry, będzie odważnie zwracał uwagę gościowi, który gra w niej 120 mecz, strzelił 30 bramek i powoli zaczyna odcinać kupony, że nie pomaga w defensywie? A nawet jeśli, co tamten mu odpowie? Kto ma rację – napastnik wściekły, że dośrodkowanie było dziadowskie czy pomocnik, który uważa, że napastnik mógł biec szybciej i lepiej ustawić się do strzału? Kto i dlaczego powinien ustawić się do wykonania rzutu wolnego w 94 minucie przy stanie 0:0?
Cóż, nieprzypadkowo w sporcie istnieje rola trenera/menedżera.
I w zasadzie nie ma nic złego, nietypowego, że zespół nie reaguje. Nie oznacza to zarazem, że tworzy go banda obiboków, którym na niczym nie zależy. A łatwo przechodzi się do takich oskarżeń. O niewdzięczni deweloperzy, tyle tu możliwości, nowy, wspaniały świat Scruma, a wy nie chcecie się usprawniać, ochrzaniać leniwych kolegów, motywować innych do działania…
Zespół siedzi cicho, powinien wkraczać Scrum Master. Właściwie, powinien to złe słowo, musi. Bezwzględnie. I tyle.
Od Scrum Masterów często jednak w takich sytuacjach słyszę, że zespół sam musi się potknąć, sam przekonać, sam dojrzeć, że potrzeba czasu. Samoorganizacja, coaching itp. Ok, rozumiem. Jeden sprint – pewnie, dwa – no dobra, ale trzy i więcej?? Takie czekanie na Godota.
Często jednak brak reakcji ze strony Scrum Mastera wynika z czegoś o wiele gorszego, problematycznego, mianowicie…
2. Scrum Master się boi
Czasami po drążeniu tematu albo – częściej – z obserwacji z boku, wynika, że Scrum Master nie tyle świadomie nie interweniuje, co po cichu liczy, że w końcu zespół się zlituje i dokona tej mitycznej samoorganizacji, rozwiązując problem. A jak nie, zespół, to Product Owner. A dlaczego na to czeka? A dlatego, że po prostu się boi.
Boi się, bo sam czuje się w zespole, w swojej roli bardzo niepewnie.
Boi się konfrontacji z deweloperami, bo nie czuje się w pełni kompetentny technicznie, boi się, że zostanie zjedzony/wyszydzony/zarzucony technikalami, z którymi ciężko mu będzie polemizować.
Boi się, bo wie, że nikt go może nie wesprzeć i za chwilę będzie miał przeciwko sobie cały zespół.
Boi się z tego samego powodu, co na przykład deweloperzy.
Albo daje się zbyć ogólnikami i technikaliami: to skomplikowany moduł, tego nie dało się przewidzieć wcześniej, to musi tyle trwać, mamy tu wiele zależności, przy tym poziomie skomplikowania ta ilość błędów jest czymś normalnym. Szczególny problem rodzi się, kiedy Scrum Master nie jest osobą techniczną i zawsze przyjmuje to, co mówi zespół za dobrą monetę, zamiast – jeśli sam nie ma odpowiedniej wiedzy – wesprzeć się obiektywnym ekspertem, pomagierem spoza zespołu.
Niepewność, obawy pracy w zmaskulianizowanym, specyficznym świecie deweloperskim, cechuje szczególnie Scrum Masterów nietechnicznych. Są to uczucia w pełni zrozumiałe i normalne. Ile razy słyszałem opowieści o tym, ile kogoś kosztowało przełamanie się, zanim odważył się przeprowadzić porządną retrospektywę.
Żeby pełnić dobrze rolę Scrum Mastera trzeba jednak mieć odpowiednie cechy charakteru lub je w sobie zbudować, przełamując się. Trzeba to robić, zaczynając od najmniejszych kroków. Co ciekawe z reguły ograniczają nas chomąta, które sami na siebie narzuciliśmy. Pewne założenie, ograniczenia. Odwagi!
Czasem niepewność, brak mocnego podłoża w scrummasterce powoduje zupełnie inne charakterystyczne zachowania, mianowicie…
3. Scrum Master wchodzi w rolę kumpla
W skrajnych przypadkach wygląda to tak: pomogę Wam bezboleśnie przeżyć tego cholernego Scruma, spokojnie, damy radę. Tak, wiem, że te spotkania są bez sensu, że te wykresy o kant d***. To cytaty z życia wzięte. A wzięte od Scrum Masterów najpewniej… wstydzących się Scruma. Nierozumiejący za dobrze całej tej zwinności, wrzuceni w rolę z przypadku lub konieczności, słyszący nieustanną szyderę i ataki ze stronę deweloperów, żeby przetrwać, dołączają do chóru, nierzadko w roli koryfeuszy.
Zdarzyło mi się zawitać kiedyś jako obserwator do pokoju zespołu deweloperskiego. Na ścianie wisiały obowiązki Scrum Mastera, efekt świeżej retrospektywy. Na pierwszym miejscu widniało “organizowanie eventów”. Ech, pomyślałem, klasyczny rezerwowacz salek. Tymczasem okazało się, że chodziło o organizowanie eventów po godzinach: gokarty, piwo, obiadki i inne cuda. Ręce opadają.
W ten sposób Scrum Master próbował jednak zakumplować się z zespołem. A wiadomo, że w kumpelstwie lepiej się pracuje: słuchaj Jasiu, zerknąłbyś może na to zadanko, ja wiem, że to straszny syf, ale dadzą nam trochę spokoju.
Kiedy jednak jest źle rozumiane kumpelstwo w pracy, zaczyna się problem ze szczerą, prawdziwą informacją zwrotną. Gorzej, zaczyna się przymykanie oczu, tolerowanie spraw, który nie powinny mieć miejsca… Kiedy sytuacja zachodzi za daleko, trzeba by wyjść z roli kumpla, co może być problematyczne. I wtedy najczęściej wpadamy w kolejną pułapkę…
4. Scrum Master umywa ręce i wyręcza się menedżerami
Sporo Scrum Masterów, szczególnie tych blisko zakumplowanych z zespołem, często chce uchodzić przed zespołem za tych dobrych. W związku z czym, nawet jeśli dostrzegają problemy, to ciężko jest im zwrócić na nie uwagę zespołowi. Szczególnie jeśli dotyczą one tematów drażliwych, a nierzadko trudno uchwytnych, jak wydajność, efektywność, tempo pracy czy na przykład poziom zaangażowania i odpowiedzialności.
NIerzadko tacy Scrum Masterzy podrzucają problem przełożonym tychże deweloperów lub wręcz kadrze menedżerskiej działu. Ci nie mają większych problemów, oporów z wyłożeniem kawy na ławę, którą robią w mniej lub bardziej wysublimowany zespół. O ile ze Scrum Masterem, który sobie na to pozwoli, zespół może pogrywać, o tyle, jak do gry wkracza przełożony to żartów nie ma, trzeba posłuchać.
W skrajnych przypadkach wspomniany Scrum Master zachowuje kamienną twarz i potem nawet i pociesza zespół: a widzicie mówiłem Wam, że tak to się skończy, a teraz przyszedł dyrektor Karwowski i będą kłopoty, zapomnijcie o premiach. Następnym razem mnie słuchajcie. No, ale nic, damy radę.
No, niezbyt to ładne, chluby taka postawa Scrum masterowi nie przynosi. Natomiast, jakkolwiek paskudnie to wygląda, to według mnie, to sytuacja bardzo często spotykana.
Problem tej sytuacji to jednak nie tylko niewiarygodny, dwulicowy Scrum Master. Jako, że wspomniani przełożeni działają w takich sytuacjach nie na bazie bezpośrednich przeżyć, obserwacji, a na bazie tego, co i w jakiej formie im przekazano i czemu w zaufaniu uwierzyli, nierzadko wychodzą z tego grubsze problemy.
Oczywistym jest, że Scrum Masterzy powinni ściśle współpracować z menedżerami IT i przełożonymi ludźmi, z którymi pracują. Natomiast nigdy nie powinni się nimi wyręczać czy zostawiać im rolę złego policjanta.
Współpraca ta powinna być w pełni jawna i transparentna dla zespołu, a Scrum Master i przełożeni, menedżerowie powinni mówić do zespołu, jednym, tym samym głosem.
Taka sama sytuacja dotyczy współpracy z Product Ownerami, bo sytuacje takie jak wyżej opisane są w zasadzie możliwe, jeśli…
5. Nie ma współpracy między Scrum Masterem, a Product Ownerem
No właśnie. Takie historie jak wyżej, są wręcz wzorcowymi dowodami na to, że taka współpraca nie istnieje.
Mogą też wskazywać dowodem na to, że w organizacji Scrum Masterzy pracują przy zespole czy z zespołem, a Product Owner jest traktowany, jak dawniej, jako ciało obce, intruz.
Tymczasem Scrum Master powinien działać ramię w ramię z Product Ownerem. Osoby pełniące te role powinny stale wymieniać spostrzeżenia, wnioski, pomysły dotyczące codziennej działalności zespołu. I wspólnie, w duecie sobie z nimi radzić, wspierać się, mówiąc jednym głosem przed zespołem.
Praca nad takim modelem współdziałania powinna się zacząć od samego początku wspólnej drogi i pracy w Zespole Scrumowym.
Nie ma tu miejsca na ukrywanie problemów, brak zaufania, bo jeżeli tak się dzieje, bo Scrum Master nie chce pokazać bolączek swoich lub działu IT, a Product Owner nigdy nie przyzna się, że biznes nie funkcjonuje jak trzeba, no to trzeba wrócić do podstaw, albo dać sobie spokój z całą tą zwinnością.
Oczywiście, żeby to się zadziało, nie może istnieć takie zjawisko jak
6. Nieprzygotowany Scrum Master
Jeśli miałbym podsumować najczęstszy wspólny mianownik, dotyczący dotychczas omówionych punktów, będzie to brak dobrego przygotowania Scrum Master do pełnienia swojej roli.
No właśnie.
Strach, niepewność, zagubienie, niezrozumienie idei, źródeł agile’a
Niestety, w ostatnim czasie, sporo osób wskakuje w tę rolę niejako z przypadku, będąc do jej pełnienia kompletnie nieprzygotowanym, a jej główne zadanie to próby – wedle najlepszych intencji – wprowadzenia w zespole scrumowej mechaniki. Często brak tu wiedzy o technikaliach, zrozumieniu problemów zespołu. W konsekwencji często jest też nieciekawe przyjęcie i traktowanie ze strony zespołu. Stąd właśnie najczęściej rodzi się próba zakumplowania z zespołem. I stąd unikanie problemów.
Niemało dużych organizacji wyznacza przypadkowe osoby na Scrum Masterów, podrzuca Scrum Guide z hasłem radźcie sobie. Zero wsparcia, mentoringu, pomocy, nierzadko walka 30 scrum masterów o dwa wolne sloty w kalendarzu zewnętrznego Agile Coacha przybywającego do firmy co środę (znów, z życia wzięte!). Z tego typu organizacji najczęściej płynie jad na niedziałający agile. Tak, wracam do tematu z artykułu zalinkowanego wyżej. Niestety, staje się on coraz mocniej aktualny.
Czy coś da się z tym zrobić?
Przede wszystkim nie można przejść wobec problemu obojętnie, tylko starać się edukować, wpływać, tłumaczyć, działać gdzie się tylko ta. I wspierać jak tylko można osoby rzucone na głębokie wody scrummasterki.
Konsekwencje
W zespole jest ewidentny problem, tymczasem, konsekwentnie, przez długi czas nikt na niego nie reaguje. Jak już wspominałem na początku, przysłowiowe szambo, dzięki transperentności i nieustannej inspekcji, w teorii powinno wybić szybciej, niż dawniej. Owszem, czasem okazuje się, że można i w tym trybie pracy, tygodniami unikać reakcji, choć tu powinno być o to znacznie trudniej. Jeśli więc zespół prześlizguje się tygodniami, Product Owner i Scrum Master nie chcą tego widzieć i akceptują kolorowanie rzeczywistości na Przeglądach Sprintów przy przypadkowym audytorium, wtedy w organizacji powinny uruchomić się inne mechanizmy obronne. I z reguły wraca tzw. “stare”. Jakieś raporty, jakieś podsumowania, jakieś wykresy. Prędzej czy później wszystko ujrzy światło dzienne.
Problemy zaczynają się rozrastać i nawarstwiać, w konsekwencji sypią się pewne organizacyjne plany, nie ma efektów, jest rozgoryczenie lub/i wściekłość zarządzających. Inicjatywy się nie udają/opóźniają, rezultatów nie ma, odpowiedzialnych za taki stan rzeczy też nie, w łagodniejszej wersji: wszyscy się starali, wszystkim zależało, w gorszej: zaczyna się wojna podjazdowa w starym stylu.
Najczęściej “obrywają” za to Product Ownerzy, jako będący najbliżej “biznesowej części organizacji”, odpowiadający bezpośrednio przed osobami kierującymi takimi działami. A przecież nie mają oni wedle scrumowych definicji narzędzi, możliwości wpływania na działalność zespołu. Zaczynają się pretensje do IT, Scrum Masterów i nierzadko tyle ze zbliżenia prac obu grup, wraca “stare”. Zaczynają się nerwowe działania, próby przywrócenia dawnego porządku. Frustracja w organizacji rośnie, zaczynają się nerwowe ruchy, z naczelnym Scrum u nas nie działa, na czele. Pojawiają się pomysły przywrócenia Project Managerów, bo oni trzymali to w ryzach, pilnowali, nie dopuściliby do takich sytuacji.
Tymczasem najczęściej problem leży po stronie źle pełniącego swoją rolę Scrum Mastera. A może dopuszczenia niewłaściwych osób do pełnienia tej roli. Śmiem twierdzić, że wymagania i standardy dla stanowisk typu Project Manager mieliśmy w branży znacznie, znacznie wyższe.
I tak to się wszystko kręci.
Bez dobrych Scrum Masterów można sobie całego tego agile’a…