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

pytania dla Scrum MasteraW pierwszej części artykułu opisałam, jak rozumiem wspieranie innych przez Scrum Mastera, na czym polega jego praca i za co jest odpowiedzialny. W tej części, zgodnie z obietnicą, przedstawiam Wam konkretne obszary, w jakich Scrum Master może wspierać Product Ownera, Zespół Deweloperski i Organizację.

Opisałam je w formie pytań, żeby podkreślić, że Scrum Master to dla mnie człowiek, który pracuje pytaniami… przede wszystkim ze sobą. Nie zrozumcie mnie źle, to nie jest lista, z której można wyciągnąć o poranku dowolne pytanie, żeby wiedzieć, czym się zająć, jeśli odpowiedź jest przecząca. Działania Scrum Mastera powinny być ukierunkowane na konkretny, transparentny cel. Pytania, które tutaj proponuję, mogą okazać się dla Was pomocne w odpowiednim zdefiniowaniu tych działań.

Co nie zmienia faktu, że w idealnym świecie, w którym Scrum Master nie jest potrzebny, nikt w firmie nie byłby w stanie odpowiedzieć na żadne z wymienionych pytań przecząco. Jestem ciekawa, czy widzieliście taki kawałek świata. Ja (jeszcze;)) nie.

Wspieranie Product Ownera

  • Czy Product Owner zdefiniował cel biznesowy, kierunek dla zespołu?
  • Czy Product Owner odpowiednio szybko prezentuje swoje pomysły Zespołowi Deweloperskiemu, dzięki czemu już na wczesnym etapie planowania prac jest w stanie wziąć pod uwagę możliwości i ograniczenia technologii?
  • Czy Product Owner współpracuje partnersko z Zespołem Deweloperskim, weryfikuje z nim swoje tezy i buduje zobowiązania wobec klienta i managementu w oparciu o ustalenia z zespołem?
  • Czy Product Owner posługuje się twardymi danymi (KPI), planując prace z zespołem i czy ostateczne KPI są efektem ich porozumienia?
  • Czy Product Owner dysponuje choćby ogólną roadmapą rozwoju produktu?
  • Czy główni interesariusze znają postępy prac, mają okazję dawać feedback (pojawiają się na Sprint Review)?
  • Czy Product Owner odpowiednio szybko podejmuje decyzję o pokazaniu efektów pracy zespołu użytkownikowi końcowemu (produkcyjne wdrożenie, badanie na próbce użytkowników)?
  • Czy Product Owner podejmuje decyzje o postępie prac w oparciu o feedback od użytkownika końcowego, klienta, interesariuszy?
  • Czy podejmując nowe tematy biznesowe, Product Owner “rozmawia z zespołem” warsztatowo, dzięki czemu wykorzystuje jego potencjał i angażuje również na etapie koncepcji?
  • Czy Product Owner potrafi “sprzedać” zespołowi swoją wizję, “zarazić nią”?
  • Czy Product Owner jest osobą asertywną, potrafi podejmować decyzje i uargumentować je w zrozumiały sposób w zespole?
  • Czy Product Owner potrafi stanąć na straży spokoju pracy zespołu (jest blokerem dla tzw. „wrzutek”)?
  • Czy Product Owner jest świadomy ew. długu technicznego produktu i czy opracował wspólnie z zespołem plan radzenia sobie z nim?
  • Czy Product Owner zarządza produktem całościowo – od jego rozwoju poprzez utrzymanie (ang. maintenance) i błędy, które pojawiają się na produkcji?

Wspieranie Zespołu Deweloperskiego  

  • Czy zespół regularnie otrzymuje feedback od klienta, interesariuszy, managementu?
  • Czy zespół wie, kto jest użytkownikiem końcowym jego rozwiązań i czy testuje na nim rozwiązania, bierze pod uwagę jego feedback?
  • Czy zespół rozumie różnicę pomiędzy inżyniersko najlepszymi możliwymi a wystarczająco dobrymi rozwiązaniami i czy potrafi dojść w tej kwestii do porozumienia z Product Ownerem?
  • Czy zespół potrafi wspólnie z Product Ownerem zaplanować wstępnie dalsze prace w sposób, który  pozwala Product Ownerowi efektywnie współpracować z klientami i managementem?
  • Czy zespół potrafi przystosować się do zmiany wymagań np. nowej decyzji biznesowej uargumentowanej zmianą sytuacji na rynku?
  • Czy zespół faktycznie poddaje swoją pracę nieustannej inspekcji i adaptacji, a co za tym idzie, ze sprintu na sprint jest bardziej produktywny, efektywniej ze sobą współpracuje, usprawnia się?
  • Czy zespół pracuje nad rozwiązaniami w sposób iteracyjny i przyrostowy?
  • Czy wszystkie zdarzenia scrumowe przynoszą spodziewane efekty i kończą się o ustalonym czasie?
  • Czy cały zespół jest zaangażowany w przebieg zdarzeń scrumowych?
  • Czy w trakcie sprintu zespół zajmuje się tylko zadaniami ze Sprint Backloga, czy może realizuje również “na szybko” “małe” prośby z zewnątrz?
  • Czy zespół na tyle szybko wyłapuje zależności pomiędzy zadaniami, systemami, innymi zespołami, że nie wpływa to na prędkość i jakość jego pracy?
  • Czy zespół potrafi rozwijać architekturę rozwiązań w na tyle elastyczny sposób, żeby odpowiadał na potrzeby biznesowe?
  • Czy zespół zna tzw. big picture swojej pracy, wyrażone w metrykach – np. jakość kodu, ilość i źródła bugów, czas reakcji, impakt na użytkownika końcowego i wyniki finansowe…?
  • Czy zespół na bieżąco śledzi wydajność i jakość swojej pracy, korzystając z twardych danych (metryki)?
  • Czy zespół dba o komfort swojej pracy (stosuje Definition of Ready) i jakość swojej pracy (stosuje Definition of Done)?
  • Czy zespół testuje przygotowywane rozwiązania i czy sposób tego testowania zapewnia wyłapanie błędów? (Code Review, testy automatyczne, TDD)
  • Czy w zespole są wszystkie kompetencje niezbędne do wykonania pracy i czy zespół potrafi z wyprzedzeniem zaplanować poszerzanie wiedzy o nowe, potrzebne umiejętności?
  • Czy zespół współpracuje efektywnie i w przyjaznej atmosferze z osobami zaangażowanymi w prace na część etatu, np. specjalistą UX i grafikiem?
  • Czy zespół ma czas na research, rozwój, poszukiwanie odpowiednio dobrych rozwiązań?
  • Czy zespół dba o wymianę wiedzy w zespole tak, aby dowolne zadanie mogło być realizowane przez więcej niż jedną osobę?
  • Czy kierownik/ lider zespołu pozostawia mu autonomię co do rozwiązań (jak?) i obdarza go zaufaniem?
  • Czy zespół otwarcie i konstruktywnie ze sobą dyskutuje, czy nawet kłóci się, nie obawiając się np. ośmieszenia, czy kpin z pomysłów?

Wspieranie organizacji

andrea tomasiniTutaj komentarz z mojej strony. Jakiś czas temu natknęłam się na ciekawy cytat Andrei Tomasiniego, doświadczonego agile coacha, który przeprowadza w Europie agile’owe transformacje firm: Jeden z najpopularniejszych błędów to postrzeganie „organizacji” jako organizmu, zamiast nakładającej się na siebie sieci sprzecznych interesów.

Wspominam o tym, ponieważ lakoniczne zdanie typu: Scrum Master wspiera organizację / współpracuje z organizacją może powodować, że efekty tej współpracy są równie ubogie (jakieś ustalenia, których nikt nie przestrzega, wizualizacje, których nikt nie ogląda, szkolenia, które nie przekładają się na zmiany sposobu pracy). Konflikt interesów sugeruje natomiast, że należy zrozumieć perspektywę i potrzeby każdej ze stron, niekoniecznie je godzić, na pewno natomiast skonfrontować i wybrać wspólną wersję działań.

  • Czy management rozumie założenia agile’a i wie, jak można korzystać z jego atutów (szybkie dostarczanie wartości użytkownikowi, przewidywalność zespołu, kontrola ryzyka – podejście iteracyjne i przyrostowe)?
  • Czy efekty pracy zespołu odpowiadają na realne potrzeby firmy?
  • Czy są identyfikowane i spójnie rozwiązywane problemy, utrudniające pracę wielu zespołom (np. niestabilne środowisko testowe)?
  • Czy inne miejsca w firmie wiedzą, jak pracuje zespół scrumowy i w jaki sposób z nim współpracować tak, aby było to efektywne i satysfakcjonujące dla obu stron?
  • Czy osoby zainteresowane efektami pracy zespołu są zapraszane na Sprint Review, a w razie potrzeby również na Backlog Refinement (np. obsługa użytkownika, dział sprzedaży…)
  • Czy inne zespoły wiedzą, jakie rozwiązania powstają w zespole scrumowym tak, aby w razie potrzeby móc z nich skorzystać?
  • Czy zespół scrumowy realizuje wyłącznie rozwiązania, których jeszcze nie ma w firmie; wie, z jakich istniejących rozwiązań może skorzystać?
  • Czy inne zespoły wiedzą z wyprzedzeniem, czego będzie od nich potrzebował zespół scrumowy?
  • Czy zespół scrumowy wie z wyprzedzeniem, czego będą od niego potrzebować inni?
  • Czy w przypadku dużych, międzyzespołowych inicjatyw są organizowane cykliczne (co release, kwartał…) retrospektywy i czy przynoszą rezultaty w postaci usprawnień na poziomie ponadzespołowym?
  • Czy zmianie podlega kultura całej organizacji, zwłaszcza w miejscach bardziej przyzwyczajonych do tradycyjnego podejścia do zarządzania (budżetowanie, finanse, HR)?
  • Czy celebrowane są sukcesy wynikające z udanych inicjatyw, czy propagowane są korzyści wynikające ze zwinnego podejścia?
  • Czy mierzona jest efektywność całej organizacji i czy da się pokazać zależność między korzystaniem ze zwinnego podejścia a korzyściami biznesowymi?

Jeśli są pytania dla Scrum Mastera, których Waszym zdaniem zabrakło w tym materiale, koniecznie dajcie znać w komentarzu. Tym z Was, którym szczególnie odpowiada praca z checklistą, polecam również Przykładową listę kontrolną dla Scrum Masterów Michaela Jamesa.

Artykuł w wersji pdf

Źródło zdjęcia: https://www.flickr.com/photos/debord/4932655275/

Komentarze do wpisu: “Scrum Master wspiera innych, czyli co konkretnie robi? cz.2


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x