Codzienna praca Scrum Mastera z Właścicielem Produktu

Super Scrum Master - klatka z filmu video

Super Scrum Master – klatka z filmu video

Scrum Master kojarzony jest zazwyczaj z Zespołem. Mówiąc precyzyjniej, z Zespołem Deweloperskim. Pomaga w zrozumieniu Scruma, w prowadzeniu spotkań, usuwa blokady, załatwia zależności zewnętrzne, chroni Zespół od wszelkiego rodzaju zakłóceń. Dokładnie w ten sposób jest postrzegany najczęsciej zakres obowiązków Scrum Mastera.

Łatwo w tym całym zamieszaniu zapomnieć o Właścicielu Produktu. Uważam, że odpowiednia osoba na tym stanowisku potrafi wyciągać Zespół na wyżyny możliwości. Analogicznie, słaba osoba jest w stanie obniżyć morale Zespołu i pociągnąć go za sobą w dół.

Dlatego tak ważna jest codzienna praca z Właścicielem Produktu. I nie chodzi tutaj bynajmniej o rozmowę w stylu „jak było wczoraj na grillu”, tylko o konkretną porcję merytorycznych pytań dotyczących ubiegłej, bieżącej oraz planowanej pracy. Potrzebuje on – tak jak i Zespół Deweloperski – wsparcia ze strony Scrum Mastera.

Przykładowe formy wsparcia Właściciela Produktu przez Scrum Mastera:

  • dawanie informacji zwrotnej na temat podejmowanych działań
  • rozmowy na temat dalszego rozwoju produktu
  • dyskusje dotyczące efektywności oraz zaangażowania Zespołu Scrumowego (tak, dotyczy to także działań Scrum Mastera oraz Właściciela Produktu)
  • pomoc w dogłębnym zrozumieniu agile’a
  • dialog o oczekiwaniach środowiska w stosunku do jego roli
  • wsparcie wiedzą dotyczącą mechanizmów Scrumowych

Jak widać, form aktywności nie brakuje. Dużo inspirujących pomysłów można znaleźć w książce Lyssy Adkins „Coaching Agile Teams”, o której niedawno pisałem na blogu. Warto zaplanować sobie codziennie czas przeznaczony wyłącznie na to zadanie.

A Ty jak często rozmawiasz ze swoim Właścicielem Produktu?

Obszar działania coach’a

Niełatwa rola coach'a

Niełatwa rola coach’a

Po powrocie z pracy, spędzam czas ze swoją 3,5 letnią córką. Gramy w gry, układamy puzzle, rozwiązujemy zagadki. Dziecko w tym wieku rozumie zaskakująco dużo spraw. Uzyskanie odpowiedzi na niektóre pytania, wymaga zadania odpowiednich pytań oraz umiejętnego poprowadzenia rozmowy.

Podczas rozwiązywania zagadek, gdy odpowiedź nie pada od razu, podpowiadam pierwszą literę. Inaczej formułuję pytanie. Szukam analogi, podobieństw, skojarzeń, które mogłyby pomóc. Zachęcam ją do pomyślenia, przypominając, że doskonale zna odpowiedź. Zazwyczaj – prędzej czy później – pada poprawna odpowiedź. Obserwuję błysk w oku oraz wielką satysfakcję.

Podobnie widzę rolę coach’a w zespole. Codzienna praca w grupie to nieustanne wyzwania, problemy oraz zagadki. Zespół najczęściej zna odpowiedzi na swoje problemy, a nawet jeśli nie, to jest w stanie sam zdobyć potrzebne informacje. Jedyne, czego potrzebuje, to lekkiego wsparcia, naprowadzenia, usłyszenia odpowiedniego pytania.

Nie mogę dać rozwiązania na tacy. Nie mogę również pozostać obojętnym wobec ich problemów. Mogę oświetlić ciemną drogę, ale to nadal ich droga. Kierunek podróży określają sami. Ja tylko trzymam latarkę.

Fotografia użyta na licencji Creative Commons od użytkownika Alaskan Dude.

„Coaching Agile Teams” – Lyssa Adkins

Coaching Agile Teams, Lyssa Adkins

Coaching Agile Teams, Lyssa Adkins

Książkę Lyssy Adkins „Coaching Agile Teams” przeczytałem ze szczególnym zainteresowaniem. Tytuł – łączący w sobie trzy obszary, które darzę zwiększoną uwagą – nie pozostawia złudzeń co do zawartości.

Jest to bez dwóch zdań pozycja, która w sposób komplementarny pokrywa obszar codziennej pracy hmm… no właśnie. Dla kogo konkretnie jest ta książka?

Podtytuł rozwiewa tę wątpliwości: jeśli Twoja rola to Scrum Master, agile coach, kierownik projektów, a także – pomimo, iż nie został wspomniany w podtytule – menadżer średniego szczebla w zwinnym środowisku, koniecznie przeczytaj tę pozycję.

Scrum Master dowie się, z jak wielu perspektyw powinien spojrzeć na pracę zespołów. Agile coach znajdzie dobre wprowadzenie do coachingu zespołów agile’owych, a także listę narzędzi do wykorzystania w codziennej pracy. Kierownik projektu zrozumie, jak zmienia się jego rola w środowisku samoorganizujących się zespołów. Menadżer przeczyta, jak nie przeszkadzać, a zarazem jak wspomagać zespoły w osiąganiu świetnych rezultatów.

Największa z mojej perspektywy wartość książki, to pełne wyartykułowanie zakresu działań świadomego Scrum Master’a. Lyssa jasno pokazuje, że rola ta, to coś więcej, niż tylko dbanie o poprawność procesu scrumowego. Otrzymujemy zatem masę wskazówek, technik oraz pomysłów, które pozwalają lepiej wspomagać zespoły, Właściciela Produktu oraz wszelkiego rodzaju interesariuszy w ich codziennej pracy.

W trakcie czytania zaznaczyłem niemal 100 fragmentów, do których co najmniej raz w tygodniu wracam. Po przeczytaniu książki „od deski do deski”, sięgam do wybranych rozdziałów w poszukiwaniu inspiracji czy konkretnej odpowiedzi na nurtujące mnie pytania.

Szczególnie istotne wydaje mi się zwrócenie uwagi na niezmiernie ważny aspekt pracy, jakim jest codzienna praca z Właścicielem Produktu. Zanim zaczniemy mieć pretensje co do jakości Rejestru Produktu, braku odpowiedniego wkładu do zdarzeń Scrumowych, czy niejasnej wizji rozwoju, zastanówmy się, czy na pewno poświęciliśmy wystarczającą ilość czasu na wsparcie Właściciela Produktu w jego roli.

Któż bowiem jak nie my, powinien nauczyć myślenia agile’owego wszystkich zainteresowanych?

Absolutnie obowiązkowa pozycja.

Moja ocena: 5/5

5 mitów dotyczących agile’a

Pięć mitów agile

Pięć mitów agile

Agile. Dla jednych jedyne słuszne podejście do tworzenia oprogramownia, dla innych wyłącznie marketingowo opakowany chaos. Podczas rozmów jednych i drugich pada wiele śmiałych stwierdzeń. Nie wszystkie z nich są prawdziwe.

Poniżej pięć mitów dotyczących agile’a, które słyszę najczęsciej:

1. Wreszcie nie musimy tworzyć dokumentacji

To, że kompletna dokumentacja nie istnieje w momencie, gdy zasiadamy do kodu nie oznacza, że nie ma jej w ogóle. To, że może nie mieć postaci 30-stronicowego dokumentu nie znaczy, że nie wiadomo, co trzeba zrealizować w projekcie. Zgodnie z najlepszymi praktykami, w agile’u dokumentacja powstaje ad-hoc, w konkretnym wymiarze, na wymaganym poziomie szczegółowości.

2. Teraz projekty będziemy robić szybciej

Oprogramowanie może być dostarczane wcześniej. Nie zawsze jednak agile znaczy szybciej – wiele zależy od zrozumienia organizacji, co tak naprawdę znaczy zwinność. W odpowiednio przygotowanych warunkach, przy ścisłej współpracy IT oraz biznesu, wartość płynąca z gotowego oprogramowania może ujawnić się wcześniej, niż miało by to miejsce w przypadku klasycznego modelu kaskadowego.

3. Agile jest dobry, ale dla startupów

Przykłady taki firm jak Yahoo! czy Salesforce pokazują, że Scrum oraz inne praktyki agile’owe znajdują zastosowanie również w dużych, rozbudowanych przedsiębiorstwach. Może być to sposób na przywrócenie pierwotnej – zatraconej na skutek rozrostu – dynamiki firmy w obszarze wytwarzania oprogramowania.

4. Kadra kierownicza nie jest już nam potrzebna

Nie jest prawdą, że średni szczebel zarządzania w firmie nie jest potrzebny. Co więcej, aktywne działanie managementu w Scrumie jest potrzebne jak nigdy dotąd. Tworzenie przestrzeni do działań, pomoc w usuwaniu przeszkód czy wsparcie rozwoju pracowników to tylko część obowiązków managera w środowisku agile’owym.

5. W końcu nie musimy planować

Na kiedy to będzie?” to znienawidzone pytanie w zespołach deweloperskich. Niektórzy postrzegają agile’a jako możliwość ucieczki od planowania i odpowiadania na trudne pytania dotyczące terminów. Nic bardziej mylnego – planowanie w agile’u jest dostępne na wielu poziomach i stanowi stały element każdej iteracji, bez względu na jej długość.

Fotografia użyta na licencji Creative Commons od użytkownika khanele.