pytania dla Scrum Mastera
pytania dla Scrum Mastera

Scrum Master wspiera innych, czyli co konkretnie robi? cz.1

Komiks pig & chicken“Wspieranie” to słowo klucz i buzzword jednocześnie. Często pojawia się w kontekście roli Scrum Mastera i nie implikuje tego, że jest on odpowiedzialny za jakiekolwiek efekty swojej pracy. W Scrum Guide przeczytacie: Scrum Master jest odpowiedzialny za to, by Scrum był rozumiany i stosowany. W mojej interpretacj oznacza to przede wszystkim odpowiedzialność za to, jak zmienia się w czasie sposób pracy Zespołu Deweloperskiego i Product Ownera. Idąc krok dalej, współodpowiedzialność za efekty ich pracy. Te powinny coraz bardziej zbliżać się do ideału wyznaczonego przez agile i z takiej perspektywy proponuję spojrzeć na rolę Scrum Mastera.

Agile’owi poświęciłam oddzielny artykuł. Poniżej przypominam w telegraficznym skrócie jego najważniejsze założenia:

Priorytetem jest zadowolenie klienta, a jest on zadowolony wtedy, kiedy wcześnie i regularnie otrzymuje wartościowe, działające oprogramowanie. Ono jest miarą postępu. Na każdym momencie developementu klient może zmieniać wymagania, co daje mu przewagę konkurencyjną. Agile’owe zespoły są samoorganizujące się, regularnie poprawiają swoją wydajność, stawiają na bezpośrednią, efektywną komunikację. Ludzie są zmotywowani do pracy, ponieważ mają do dyspozycji potrzebne środowisko, otrzymują wsparcie, zaufanie, współpracują w atmosferze szacunku.



Scrum to narzędzie, dzięki któremu zespół powinien przynosić klientowi coraz większą wartość, stawać się bardziej produktywny, efektywniej ze sobą współpracować. Scrum Master ma za zadanie sprawić, żeby zespół umiejętnie z tego narzędzia korzystał. Warto zastanowić się nad tym, czy w moim zespole faktycznie tak jest, czy ja jako Scrum Master działam w dobrym kierunku, czy za moją sprawą zespół staje się zwinny (ang. agile).

Pamiętacie kultowy komiks z kurczakiem i prosiakiem? Mam wrażenie, że przez problemy ze zdefiniowaniem, czym w zasadzie ma się zajmować Scrum Master i za co jest odpowiedzialny, niejeden wciela się w kurczaka. Jest zaangażowany, ale niewiele z tego wynika dla efektów pracy zespołu.

Komiks pig & chickenTaki kurczak znosi metaforyczne “złote” jaja, na przykład sprawia, że zespół perfekcyjnie stosuje mechanikę Scruma (zdarzenia, timeboxy), namawia Product Ownera na kolorowe labelki w backlogu i stosowanie business value, prowadzi spotkania za pomocą Komiks pig & chickenwyszukanych technik kreatywnych, stawia ludziom „coachujące” pytania, przekonany, że wnosi ich tym samym na kolejny poziom agile’a. Gdyby zapytać dowolnego dewelopera z jego zespołu, po co to wszystko, doradziłby zapewne, żeby zapytać Scrum Mastera, bo tylko on zna odpowiedź. Tymczasem zespołowi obrywa się za niezadowolenie klienta, błędy, awarie, deweloperzy nie potrafią ze sobą współpracować, zespół dubluje rozwiązania, które ktoś już kiedyś stworzył w firmie… Żadne wsparcie, prawda? Taki kurczak szkodzi wszystkim, przeszkadza w pracy, denerwuje i robi złą famę agile’owi, Scrumowi i tym wszystkim, którzy dla odmiany robią w temacie dobrą robotę. Na dodatek, w każdym momencie może wycofać się i powiedzieć, że przecież on nie ma wpływu na to, jak pracuje zespół i Product Owner, bo jest tylko Scrum Masterem, w swoim rozumieniu liderem służebnym (ang. servant leader) i nikt nie musi go słuchać, on jedynie sugeruje, podpowiada, uczy, coachuje… Nie zgadzam się.

Od czego w takim razie warto zacząć, na czym się skupić? Początkującym Scrum Masterom i takim, którzy rozpoczynają współpracę z nowym zespołem proponuję – od podstaw.

  • Omówienia/powrócenia w zespole do tematu, po co to wszystko, czym jest agile, do czego ma doprowadzić stosowanie Scruma.
  • Wspólnego przedyskutowania ról w zespole, uspójnienia wyobrażeń na temat tego, kto faktycznie za co odpowiada, od kogo czego można oczekiwać, z czym się do kogo zwracać.
  • Przypomnienia lub uzgodnienia, jaki jest cel pracy zespołu (Po co? Dlaczego? Dla kogo?)
  • Zweryfikowania, jak w tej chwili wygląda sytuacja w zespole, co utrudnia pracę, czy Product Owner i zespół faktycznie wiedzą, dla kogo (klient, użytkownik końcowy) i co (jaka potrzeba i wartość) mają za zadanie zrealizować.
  • Zdefiniowania celu krótkoterminowego dla zespołu (jak najszybsze wdrożenie produkcyjne? częstsze wydania nowych wersji? poprawa przewidywalności zespołu? uporanie się z długiem technicznym? zminimalizowanie zadań utrzymaniowych na rzecz rozwojowych?….)

Prawdę mówiąc, zainicjowanie tego typu  dyskusji może być również odkrywcze i inspirujące dla zespołów, które współpracują ze sobą od dłuższego czasu. W takim przypadku proponuję zastanowić się na przykład nad tym, czy faktycznie udaje nam się zmieniać na lepsze, mimo tego, że często rozmawiamy o usprawnieniach.

Agile samurai

Wspólny mianownik ułatwia realne wspieranie, koncentrowanie uwagi i sił na rzeczach istotnych z punktu widzenia zespołu i efektów jego pracy. Pomaga zlokalizować realne przeszkody, a tymi wcale nie muszą być rzeczy oczywiste i łatwe do zdefiniowania, jak np. brak miejsca na serwerze. Równie dobrze mogą nimi być:  niedookreślenie, kto jest klientem, czy użytkownikiem końcowym realizowanych rozwiązań, jakie są wymagania biznesowe dla zespołu, jaki jest cel tego, czym zajmuje się zespół, brak decyzyjnego Product Ownera… Co zespół to inny przypadek, nie ma cudownej recepty na idealny zespół Scrumowy.

Scrum Master nie jest dla mnie magikiem, który sypie sztuczkami z rękawa, czaruje coś podczas spotkań z innymi Scrum Masterami, z których przychodzi z pomysłami zupełnie oderwanymi od realiów pracy zespołu. Wręcz przeciwnie. Ma do wykonania bardzo konkretną pracę, na którą umawia się z Product Ownerem, Zespołem, kierownikiem zespołu. Dzięki jego działaniom zespół ma zmieniać się na lepsze, w odniesieniu do konkretnej, zastanej sytuacji i celu, wyzwania, jakie przed nim stoi. Bez siłowych rozwiązań, kija i marchewki, nakazów i zakazów, manipulacji i wywyższania się. Za sprawą jego wiedzy o agile’u, czy iteracyjnym, przyrostowym podejściu do wytwarzania oprogramowania, podawanej w strawny, nieinwazyjny sposób; czujnego oka i ucha na przejawy konfliktów w zespole oraz niezbędnego taktu, który pozwoli temu zaradzić; umiejętności rozpoznania, kiedy dyskusje schodzą na manowce i refleksu oraz odwagi, które pomogą zawrócić je na odpowiedni tor. I jeszcze umiejętności pracy z ludźmi, uważnego słuchania, przesiewania słów przez sito pt. „co chcę przez to osiągnąć”, zadawania dających do myślenia pytań (myślenie pytaniami – ciekawa idea w drażniącej oprawie), szacunku. Innymi słowy, ma i wiedzę, i predyspozycje do pracy z zespołem.

Do jego zadań należą:

  • Dbanie o to, aby Scrum był stosowany jako metoda empiryczna, a nie powtarzalny, niewiele wnoszący schemat działań – wyciąganie wniosków z dotychczasowych doświadczeń (inspekcja) i udoskonalanie sposobu pracy (adaptacja),
  • Dzielenie się wiedzą o konkretnych przypadkach użycia: Scruma, technik współpracy i dobrych praktyk inżynierskich,
  • Pomoc w zdefiniowaniu realnych przeszkód, problemów w zespole, znalezieniu rozwiązań oraz zaplanowaniu tego, jak faktycznie wcielić je w życie i jak sprawdzać, czy się wydarzyły,
  • Stawianie w odpowiednim momencie trafiających w sedno pytań, które sprawiają, że zespół koncentruje się na najbardziej newralgicznych w danym momencie kwestiach (dotyczących realnych potrzeb użytkownika, możliwości technologicznych, zależności…),
  • Stosowanie podczas zdarzeń scrumowych technik pracy wspierających kreatywne rozwiązywanie realnych problemów zespołu, wzmacniających współpracę,
  • W razie potrzeby moderacja spotkań w taki sposób, aby każde z nich przynosiło konkretną wartość, miało pozytywny wpływ na kolejne działania zespołu,
  • Wszystko to w sposób jasny i zrozumiały dla wszystkich zainteresowanych stron (przejrzystość).

Drogi Scrum Masterze, ustal, nad czym teraz wspólnie pracujecie, co jest ważne. Gdzie muszą pojawić się zmiany i jakie, aby wszystkie zainteresowane strony uznały, że zespół ruszył do przodu. Pracuj przejrzyście również w kontekście Twojej roli. Zachęcam do… zakasania rękawów i do pracy ukierunkowanej na zdefiniowany, transparentny cel.

W drugiej części tego artykułu (scrum master wspiera innych czyli co konkretnie robi cz. 2przedstawię Wam przykłady konkretnych obszarów, w jakich Scrum Master może wspierać Product Ownera, Zespół Deweloperski i Organizację.

Źródła zdjęć:

Jonathan Rasmusson, The Agile Samurai: How Agile Masters Deliver Great Software, 2010

http://img.desmotivaciones.es/201104/pobrecerdo_www_Humor12_com.jpg

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x