Skip to content

Team Estimation Game jako alternatywa dla Planning Pokera

W jednym z poprzednich wpisów spróbowałem wytłumaczyć, na czym polega relatywne szacowanie w story pointach. Istnieje wiele technik, które to wspierają, a chyba najpopularniejszą jest Planning Poker. Jest to świetna technika, jednak ma kilka słabszych punktów:

  • Ile? Deweloperzy próbują od razu odpowiedzieć na pytanie „ile?” zamiast porównywać ze sobą różne elementy Backlogu Produktu (np. historyjki użytkownika) i określać relatywny rozmiar.
  • Powrót do szacowania w jednostkach czasu. Odpowiadając na pytanie „ile?” deweloperzy szukają jakiegoś odniesienia dla „abstrakcyjnego” story pointa i znajdują go znowu w godzinach albo dniach.
  • Szacowanie zajmuje dużo czasu, a gra na dłuższą metę jest nudna i męcząca. Zabawnie jest chyba tylko pierwsze dwa razy.
  • To 2 czy 3 punkty? Często prowadzi do przedłużających się dyskusji o nieistotne szczegóły zamiast budować wspólne rozumienie wymagań.
  • Falstarty. Co niecierpliwsi nagminnie odkrywają karty zanim koledzy z zespołu wybiorą swoje.

W zespołach, z którymi pracuję, jako alternatywę dla Planning Pokera jakiś czas temu zaczęliśmy wykorzystywać technikę Team Estimation Game.

Team Estimation Game — przebieg gry

  1. Przynosimy przygotowany wcześniej stos kart z historyjkami użytkownika. Najlepiej, jeśli karty będą ułożone zgodnie z kolejnością w Backlogu Produktu, czyli na górze stosu będzie historyjka z góry Backlogu.
  2. Wykładamy pierwszą kartę ze stosu na środek stołu.
  3. Ustalamy, po której stronie tej karty mają leżeć karty większe, a po której mniejsze.
  4. Pierwsza osoba zdejmuje ze stosu kolejną kartę i, w zależności czy uzna ją za większą lub mniejszą, kładzie ją po odpowiedniej stronie już leżącej karty. Jeśli uzna, że obie karty mają zbliżony rozmiar, to układa je razem w pionową kolumnę.
  5. Następna osoba ma dwie opcje:
    1. zdjąć kolejną kartę ze stosu i ułożyć ją w odpowiednim miejscu względem leżących już na stole lub
    2. przesunąć jedną (ale tylko jedną) z już ułożonych na stole kart w inne miejsce.
  6. Kolejne osoby wykonują swoje ruchy w kółko aż to momentu, kiedy zostaną oszacowane wszystkie karty.
  7. Każdy wykonując ruch uzasadnia swoją decyzję, a pozostali mogą zadawać pytania wyjaśniające ale nie mogą podważać oszacowania osoby wykonującej ruch.
  8. Na koniec można zrobić dodatkową rundkę (albo kilka) na opcjonalny ostatni ruch.
  9. W rezultacie powinniśmy otrzymać kilka grup kart o zbliżonych estymatach. Jeżeli grup jest zbyt dużo, możemy zdecydować się na połączenie kilku.
  10. Następnie przypisujemy tym grupom wartości w story pointach, np. z ciągu Fibonacciego.

    Karty ułożone podczas Team Estimation Game

    Karty ułożone podczas Team Estimation Game

Oczywiście o moderację nadal należy dbać. Tu też zdarzają się falstarty (ktoś przesunie coś nie czekając na swoją kolej) albo wpływanie na czyjąś decyzję („Tutaj?! No bez przesady… Ja bym dał to niżej!”).

Najciekawsze na koniec

Z moich doświadczeń najważniejsza jest jednak końcówka. W Planning Pokerze sesja estymacyjna najczęściej kończyła się albo po upływie zaplanowanego czasu (rzadko, częściej spotkania się przeciągały), albo po oszacowaniu ostatniej historyjki. Zespół po prostu kończył spotkanie i rozchodził się.

W Team Estimation Game gra tylko teoretycznie się kończy po oszacowaniu ostatniej karty ze stosu i opcjonalnej dodatkowej rundzie. W rzeczywistości po ostatniej rundzie zespół najczęściej wstaje i wszyscy wspólnie jeszcze raz się pochylają (dosłownie) nad wyłożonymi na stół historyjkami, żeby „na koniec rzucić okiem” i zaczynają zadawać naprawdę ważne pytania, jeszcze coś zespołowo doprecyzowują, przesuwają, aż rzeczywiście cały zespół będzie zgodny co do tego, jak całość jest ułożona.

Kolejne sesje estymacyjne

Rzadko kiedy mamy do oszacowania zupełnie nowy Backlog Produktu. Najczęściej szacujemy nowe historyjki w ciągle utrzymywanym Backlogu. Wtedy jako punkt odniesienia zamiast pierwszej karty ze stosu lepiej użyć kilku już wcześniej oszacowanych (albo wręcz zaimplementowanych) historyjek o różnych rozmiarach, np. po jednej za 1, 5 i 13 punktów.

Wariant niemy

Można ustalić, że jedynie osoba wykonująca aktualnie ruch może się odzywać po to, żeby zadać pytania Product Ownerowi. Nikt inny z zespołu nie może komentować ruchu. Wyłapujemy w ten sposób „wędrujące” historyjki, ale w miarę, jak kolejne osoby zadają pytania, a Product Owner odpowiada, w końcu znajdują one swoje miejsce na stole albo są odkładane na bok do dyskusji na później.

Zalety Team Estimation Game

  • Relatywne szacowanie. Deweloperzy nie muszą od razu odpowiadać na pytanie „ile?”, a jedynie porównują ze sobą karty. Łatwiej jest powiedzieć, która z historyjek jest większa/mniejsza, niekoniecznie określając, jak bardzo.
  • Punkt odniesienia. Nie tracimy z oczu już oszacowanych historyjek, dzięki czemu cały czas mamy dobry punkt odniesienia dla kolejnych.
  • Korygujemy estymaty. Dość powszechne jest wracanie do już oszacowanej historyjki i ponowne jej szacowanie, dzięki czemu może być ono dokładniejsze (w odróżnieniu od Planning Pokera, kiedy o historyjce zapominano zaraz po jej oszacowaniu).
  • Perspektywa zespołu. Historyjki są szacowane z punktu widzenia całego zespołu. W Planning Pokerze każdy z osobna szacował bardziej ze swojej specjalistycznej perspektywy.
  • Brak oporu w przypadku niepewności. Jeżeli ktoś z zespołu ma problem z oszacowaniem którejś z historyjek, nic strasznego — może położyć ją gdziekolwiek, a koledzy poprawią w następnych ruchach.
  • Jest szybciej. Nie tracimy czasu na historyjki, co do których jest zgoda, a dyskusja toczy się jedynie wokół tych przesuwanych.
  • Każdy głos może być usłyszany. Osoby cichsze nie są tak łatwo zagłuszane przez gaduły, jak to często ma miejsce przy Planning Pokerze, a cała dyskusja przebiega sprawniej i jest bardziej merytoryczna.
  • Skalowanie. Technikę można z powodzeniem stosować w bardziej licznych zespołach albo gdy kilka zespołów pracuje z jednym Backlogiem Produktu. Zdarzyło mi się zastosować wariant niemy z niemal 20-to osobową grupą.

Oryginalny pomysł Team Estimation Game przypisuje się Steve’owi Bockmanowi, a ściągę z regułami można znaleźć na stronie agile42.com.

Categories: Estymacja.

FedEx Day w Polskapresse Internet

W kwietniu 2013 r. w Polskapresse — firmie, w której pracuję — odbył się pierwszy FedEx Day. Jest to wydarzenie, które polega na tym, że każdy w firmie może pracować nad czym chce przez 24 godziny. Jedyny warunek to, żeby projekt dotyczył któregoś z rozwijanych w firmie produktów lub używanych narzędzi. Można pracować samodzielnie lub w dowolnie uformowanym zespole, a po 24 godzinach należy zademonstrować to, co udało się w tym czasie wykonać. Nazwa pochodzi od firmy FedEx, która dostarcza przesyłki właśnie w ciągu 24 godzin. Pomysł natomiast pochodzi od firmy Atlassian, w której takie wydarzenie odbywa się co kwartał i nazywa się ShipIt Days.

Lądowanie samolotu DC-10 FedEx

Lądowanie samolotu DC-10 FedEx. Autor: James Reppucci [CC-BY-3.0]

U nas FedEx Day rozpoczął się w pewien kwietniowy czwartek o godzinie 15. Zgłosiło się 10 zespołów z pomysłami i każdy został zaakceptowany. Każdy z zespołów po 24 godzinach dostarczył coś, co o 15:00 w piątek zaprezentował reszcie firmy.

Pomysły

Okazuje się, że ludzie dobrze wiedzą, co może być wartościowe dla firmy. Każdy ze zgłoszonych pomysłów był albo nową funkcjonalnością w produkcie albo usprawnieniem któregoś z używanych w firmie narzędzi. Jedne pomysły były bardzo praktyczne, inne dość odważne i zaskakujące, będące tylko próbą realizacji pewnej idei. Nie było jednak ani jednego pomysłu, który by nie niósł żadnej wartości.

Samoorganizacja

Okazuje się, że ludzie znając dobrze cel do osiągnięcia i rozumiejąc ograniczenia potrafią sami uformować się w zespoły i zorganizować swoją pracę. Nikt nie narzucał liczebności zespołów ani ich składu. Największy zespół liczył siedem osób, w jednym przypadku jedna osoba pracowała samodzielnie. Część zespołów uformowała się z ludzi, którzy pracują ze sobą w zespole na co dzień, ale były też takie, których członkowie pochodzili z różnych jednostek organizacyjnych. Tak uformowane zespoły były w stanie tak się zorganizować, żeby wykonać pracę, która ich czekała. Nikt nie narzucał sposobu ani godzin pracy, a jedynym ograniczeniem były 24 godziny na dostarczenie.

Dostarczanie w 24h

Zadziwiające, jak DUŻO udało się zespołom wykonać w ciągu tych 24 godzin. Oczywiście, że jedne dostarczyły mniej, inne więcej, ale ważne jest to, że każdy z zespołów dostarczył coś działającego. Nie było żadnego przypadku, żeby zespół nie miał czegoś do pokazania. Odwrotnie — w zdecydowanej większości zaprezentowane projekty zaskakiwały swoim zakresem jak i poziomem wykonania biorąc pod uwagę tak krótki czas na realizację.

Wrażenia z pracy

Sam także zdecydowałem się wziąć udział w wydarzeniu i pracowałem w 5-osobowym zespole. Wrażenia:

  • Fizyczna bliskość i ciągła komunikacja to podstawa. Nie dostarczylibyśmy tyle, gdybyśmy się nie zainstalowali razem w sali konferencyjnej.
  • Kolejnym czynnikiem sukcesu było skupienie. Nie robiliśmy niczego innego, tylko ten jeden projekt. To komfort, na który rzadko możemy sobie pozwolić na co dzień.
  • Mieliśmy jasno określony cel i bardzo ogólnie nakreślony plan w formie backlogu na karteczkach post-it. Wymagania zmieniały się na bieżąco. Nie dostarczyliśmy wszystkiego, co planowaliśmy, ale jednocześnie dostarczyliśmy też coś, czego nie planowaliśmy na początku.
  • Bardzo pomocne okazały się momenty, kiedy wszyscy na chwilę przerywaliśmy pracę, oglądaliśmy razem na dużym ekranie to, co już udało się stworzyć i ustalaliśmy, co dalej. Takie krótkie kilku-minutowe Sprint Review, których mieliśmy kilka w ciągu 24 godzin.
  • Wyczerpujące. Nie jest to wydarzenie, które można robić co tydzień czy nawet co miesiąc.
  • Mega zabawa!

Samoorganizacja, dostarczanie wartości w krótkim czasie, czerpanie autentycznej radości z pracy — to wszystko jest możliwe, jeżeli stworzy się ku temu odpowiednie warunki.

Categories: Samoorganizacja.

Story points. O co chodzi z tymi punktami

Często jestem świadkiem trudności, z jaką przychodzi zespołom przestawienie się na metody szacowania oparte o jednostki względne, jakimi są story points. „Przyjmujemy, że jeden punkt to dzień, tak?” — słyszę często podczas sesji estymacyjnych.

Niesłusznie zakładamy, że szacowanie w story pointach polega na zamianie dni czy godzin na jakieś abstrakcyjne punkty, które nadal mają odzwierciedlać czas.

Tak nie jest. Chociaż celem szacowania nadal pozostaje odpowiedź na pytanie, ile czasu coś zajmie, to zamiast od razu odpowiadać na pytanie o czas, powinniśmy najpierw oszacować rozmiar pracy do wykonania. Następnie, biorąc pod uwagę naszą wydajność, będziemy mogli określić czas potrzebny na wykonanie zadania.

Jeżeli zadaniem jest np. pokonanie trasy z Gdańska do Warszawy, to zanim powiemy, ile czasu nam to zajmie, określamy rozmiar pracy do wykonania — długość trasy wyrażoną w kilometrach. To oczywiście duże uproszczenie, bo oprócz samej długości trasy uwzględnimy też jej złożoność: liczbę obszarów zamieszkałych po drodze, długość wyremontowanych dwupasmowych odcinków i odcinków starej jednopasmówki.

Następnie określamy wydajność — średnią prędkość wyrażoną w kilometrach na godzinę. Tutaj także oprócz możliwości samego środka transportu uwzględnimy inne czynniki, takie jak natężenie ruchu, warunki pogodowe, umiejętności kierowcy, czas potrzebny na przerwy.

Warto podkreślić dwie kwestie: (1) długość trasy pozostaje taka sama niezależnie od tego, kto, czym, jak i kiedy będzie ją pokonywał; (2) większa trudność jest w szacowaniu prędkości niż długości trasy.

Dopiero wynik działania matematycznego (rozmiar/wydajność) to jest ten czas potrzebny na jej pokonanie.

W wytwarzaniu oprogramowania często nieświadomie idziemy na skróty i zamiast oszacować osobno rozmiar pracy i osobno wydajność, próbujemy od razu oszacować czas potrzebny na wykonanie zadania.

Powód jest banalny: brak sensownej jednostki pracy w wytwarzaniu oprogramowania i używanie jednostek czasu — mitycznych osobogodzin czy osobodni.

O ile możemy zmierzyć drogę do przejechania w kilometrach, ściany do pomalowania w metrach kwadratowych, ładunek do rozładowania w tonach, to w czym zmierzyć oprogramowanie? W dodatku nieistniejące, które dopiero ma powstać?

Brak jednostki nie wyklucza jednak możliwości pomiaru. Na rysunku poniżej zostały umieszczone trzy koła. Nie znamy dokładnej powierzchni każdego z nich, ale na oko widać, że B jest większe od A około dwa razy, a C — 4 do 6. Nie potrzebujemy bezwzględnej jednostki, żeby móc porównać ze sobą dwa obiekty i określić ich relatywny rozmiar. Jeżeli kołu A przypiszemy wartość 1, to możemy uznać, że B ma rozmiar 2, a C — 5.

Koło B jest dwa razy większe niż A, a C pięć razy większe.

Koło B jest dwa razy większe niż A, a C pięć razy większe.

Wśród zwinnych zespołów popularnym sposobem formułowania wymagań są historyjki użytkownika (user stories). Porównując je ze sobą możemy określić relatywny rozmiar jednej historyjki w stosunku do drugiej przypisując im punkty (story points). Oczywiście, ma to zastosowanie nie tylko w stosunku do historyjek użytkownika, ale też do wymagań sformułowanych w dowolnej innej formie.

Pojawia się pytanie, jakie cechy porównywanych ze sobą wymagań uwzględniać. Tutaj głosy są podzielone: jedni twierdzą, że chodzi o wysiłek, jaki należy włożyć, inni zaś, że o złożoność wymagań. Ja staram się uwzględniać stopień pewności klienta co do swoich wymagań, stopień zrozumienia wymagań przez zespół, złożoność wytwarzanego rozwiązania, czy praca będzie wykonywana samodzielnie czy przez kilku różnych specjalistów, wysiłek, jaki trzeba będzie włożyć, ryzyko.

Im większe obiekty, tym większa musi być między nimi różnica, żeby móc ją dostrzec i określić, który z obiektów jest rzeczywiście większy i o ile. Na rysunku poniżej wyraźnie widoczna jest różnica między kołami A i B czy B i D, ale już nie między D i E. Wydają się one być porównywalne ze sobą i nawet jeśli dostrzeżemy, że D jest ciut mniejsze od E, to trudno jest określić, o ile. (W rzeczywistości D = 7 × A, E = 8 × A.)

Koła D i E wyglądają na porównywalne, chociaż D = 7 × A, a E = 8 × A.

Koła D i E wyglądają na porównywalne, chociaż D = 7 × A, a E = 8 × A.

Dlatego wiele technik szacowania relatywnego jako jednostki przyjmuje liczby Fibonacciego: 1, 2, 3, 5, 8, 13 itd. Nie potrzebujemy rozgraniczać historyjek np. 11, 12 i 13-punktowych, bo przy tej skali oraz uwzględniając błąd szacowania to nie ma większego znaczenia. Ciąg Fibonacciego to oczywiście nie jedyna możliwa skala. Równie dobrze jako jednostki sprawdzą się rozmiary ubrań: S, M, L.

Na tym właśnie polega relatywne szacowanie w story pointach. Punkty odzwierciedlają rozmiar pracy, a nie czas potrzebny do jej wykonania.

Liczba ukończonych story pointów w jednostce czasu (np. w tygodniu czy sprincie) to nasza wydajność określana mianem prędkości zespołu (velocity). Mając oszacowane wymagania w Backlogu Produktu i znając naszą prędkość możemy prognozować czas zakończenia danego zakresu prac.

Podsumowując:

  • Zamiast szacować czas potrzebny na wykonanie pracy, skup się najpierw na oszacowaniu jej rozmiaru.
  • Nie szacuj rozmiaru pracy w jednostkach czasu; użyj jednostek względnych.
  • Wydajność (prędkość) mierz empirycznie.
  • Czas zakończenia prac prognozuj na podstawie oszacowanego rozmiaru pracy do wykonania oraz mierzonej ciągle wydajności.

Powiązane wpisy:

Categories: Estymacja.

Książka: „Scrum. O zwinnym zarządzaniu projektami”

Okładka książki „Scrum. O zwinnym zarządzaniu projektami” Mariusza Chrapko

„Scrum. O zwinnym zarządzaniu projektami” Mariusz Chrapko

Książka „Scrum. O zwinnym zarządzaniu projektamiMariusza Chrapko jest chyba pierwszą polską książką poświęconą zwinnym metodom zarządzania. Choć na rynku jest dostępnych kilka książek po polsku na ten temat, to są to przekłady zagranicznych autorów. Ma to znaczenie z dwóch powodów: po pierwsze pojawiła się kolejna książka, do której można odesłać osoby zainteresowane tematem, ale nie posługujące się biegle językiem angielskim; po drugie — i to chyba powód bardziej znaczący — jest to książka naprawdę polska. Autor posługuje się językiem i metaforami, które będą w pełni zrozumiałe dla polskiego czytelnika, a liczne przykłady z życia dotyczą polskich warunków.

Jeżeli chodzi o zawartość książki, to znajdziemy tam wszystko, co książka o Scrumie i zwinnym zarządzaniu projektami powinna zawierać: rozdziały poświęcone rolom Scrum Mastera i Właściciela Produktu oraz budowaniu zwinnych zespołów; bardzo szczegółowe i pełne praktycznych wskazówek rozdziały o każdym zdarzeniu scrumowym, z których dowiemy się nie tylko, jakie spotkania i po co są potrzebne, ale też jak je zorganizować, żeby były efektywne. Przydatne są metody planowania sprintu, sposoby organizacji codziennych scrumów w zespołach rozproszonych, wskazówki, jak zorganizować przegląd sprintu czy konkretne ćwiczenia przydatne podczas retrospektyw.

Oprócz szczegółowego przedstawienia samej metody nie mogło też zabraknąć tematów dotyczących zarządzania projektem IT, czyli zbierania i zarządzania wymaganiami, zwinnego szacowania i planowania projektów oraz wydań, monitorowania postępów prac.

Zabrakło mi natomiast głębszego wytłumaczenia empirycznego podejścia do kontroli procesu, mechanizmów przejrzystości, inspekcji i adaptacji, co w moim odczuciu jest kluczowe w zrozumieniu zwinności i Scruma.

Książka skierowana jest przede wszystkim do osób, które swoją przygodę ze zwinnymi metodami zarządzania dopiero zaczynają. Będzie dobrym wprowadzeniem w temat dla kierowników projektów, kierowników liniowych, programistów, testerów, projektantów, ale też dla osób „po drugiej stronie barykady” — klientów zamawiających oprogramowanie.

Nie znaczy to jednak, że książka nie przyda się komuś, kto Scruma zna, a nawet stosuje. Ja o Scrumie po raz pierwszy usłyszałem jakieś siedem lat temu, a metodę zgłębiać zacząłem cztery lata temu. Myślę, że Scruma znam i rozumiem dość dobrze, ciągle się uczę stosowania go na co dzień. Zdarza mi się też uczyć Scruma innych prowadząc szkolenia. Spodziewałem się, że książka będzie po prostu zbiorem tego, co i tak już wiem, a jednak zostałem mile zaskoczony. Być może nie znalazłem w niej wiele nowej dla mnie wiedzy, ale sposób przekazywania tej wiedzy i tłumaczenia pewnych zjawisk sprawił, że czytając książkę albo kiwałem głową na znak zgody z autorem albo myślałem sobie: „Świetnie wytłumaczone! Spróbuję podobnie następnym razem, kiedy znowu będę musiał komuś wytłumaczyć ten temat.”

Zdarzały się też fragmenty, przy których marszczyłem brwi i musiałem się chwilę zastanowić, bo… nie do końca z autorem się zgadzałem. Obawiam się na przykład, czy czytelnik nie zrozumie błędnie roli Scrum Mastera jako osoby odpowiedzialnej za organizację spotkań zespołu. Również przedstawienie roli kierownika projektu w Scrumie budzi więcej pytań niż odpowiedzi.

Warto też zwrócić uwagę na dwie cechy charakterystyczne dla tej książki, a mianowicie język i ilustracje.

Autor używa licznych metafor, np. ze świata muzyki, często odwołuje się do kina, literatury czy znanych filozofów. Za przykład niech posłużą tytuły wybranych rozdziałów: „Kontrabasista”, „Platon, idee i ryby”, „O żeglowaniu i obieraniu cebuli”, „Biegnij, Forrest, biegnij”. Dzięki użytemu językowi i przewijającym się przez cały czas pasjom autora książka nabiera osobistego charakteru. Chociaż momentami odczuwałem lekki przesyt metaforami i opowiastkami, to generalnie książka jest łatwa w odbiorze i będzie zrozumiała nie tylko dla programistów.

Brawa na pewno należą się pani Aleksandrze Bułhak za genialne wręcz ilustracje!

Książka jest napisana przez praktyka, osobę z ogromnym doświadczeniem w wielu organizacjach i projektach. Praktyczne rady i wskazówki, przykłady z rzeczywistych projektów, osobiste doświadczenia z pracy z różnymi zespołami, historie z życia, także te przedstawiające zagrożenia i błędy — wszystko to czyni książkę „Scrum. O zwinnym zarządzaniu projektami” pozycją godną polecenia.

4/5

Categories: Scrum.

O komunikowaniu decyzji

W swojej pracy czasami słyszę pytanie, czy Właściciel Produktu (Product Owner) powinien uzasadniać swoje decyzje Zespołowi Deweloperskiemu. Na przykład te dotyczące kolejności czy zakresu wymagań w Backlogu Produktu. Przecież to on jako Product Owner odpowiada za produkt, więc powinien mieć ostateczne słowo i dlaczego niby musi tłumaczyć się przed zespołem.

Zawodnik i trener

Kolega, który trenuje siatkówkę, podzielił się ostatnio ciekawą historyjką.

Moment podczas meczu Bułgaria - Serbia

Moment podczas meczu Bułgaria – Serbia. Autor: Biser Todorov [CC-BY-3.0]

Otóż w jego drużynie grał kiedyś pewien chłopak, nazwijmy go Zbyszek. Zbyszek swoją grę w drużynie zaczął jako rozgrywający i z czasem stał się niezłym graczem na tej pozycji. Po jakimś czasie zawitał jednak do drużyny nowy nabytek, który okazał się być lepiej rokującym rozgrywającym niż Zbyszek. Trener przesunął więc Zbyszka na inną pozycję. Zbyszek na początku radził sobie gorzej na nowej pozycji, jednak z czasem zaczął się wyrabiać i znowu stał się niezłym graczem. Do czasu, aż znowu nie pojawił się ktoś lepiej rokujący na tej pozycji niż Zbyszek i trener znowu zmienił mu rolę. Historia powtórzyła się jeszcze kilka razy.

Zbyszek nie był graczem wybitnym, jednak w wyniku licznych przesunięć stał się zawodnikiem wszechstronnym i grającym pewnie niezależnie od pozycji.

Wówczas trener uczynił ze Zbyszka gracza rezerwowego. Zbyszek coraz częściej mecz zaczynał od ławki rezerwowych, a do gry wstawał, kiedy ktoś z podstawowego składu miał gorszy dzień i „gra mu nie szła”. Zbyszek stał się „tajną bronią” trenera i w takich sytuacjach niejednokrotnie ratował drużynę.

Sytuacja jednak była bardzo frustrująca dla Zbyszka. Nie rozumiał decyzji trenera, nigdy nie wiedział, czy przyjdzie mu grać danego dnia i czuł się niedoceniany.

Podczas pewnego meczu czara goryczy się przelała. Kiedy podczas meczu po pierwszym secie usłyszał od trenera, że ma się szykować, bo zaraz wchodzi, nie wytrzymał i odpowiedział mu, żeby spadał (w bardzo niecenzuralny sposób). Był to ostatni mecz Zbyszka z tą drużyną.

Ani Zbyszek, ani trener nie rozumieli zachowań jeden drugiego. Rozstali się w taki sposób, że chyba nie rozumieją tego do tej pory. Jakże inaczej mogła się potoczyć historia, gdyby trener po prostu powiedział Zbyszkowi, dlaczego robi z niego rezerwowego i jak bardzo docenia jego wkład.

Oznajmianie a komunikowanie decyzji

Aby ludzie podążali za przywódcą, nie wystarczy decyzji po prostu oznajmiać i egzekwować. Decyzje należy skutecznie komunikować, tak, aby były one rozumiane. Wtedy jest większa szansa, że będą one także akceptowane.

Tak, to Product Owner odpowiada za produkt i ma ostateczne zdanie. Jednak dobry Product Owner nie będzie tylko oznajmiał swoich decyzji. Dobry Product Owner przedstawi je zawsze w szerszym kontekście (wizja, plany rozwoju). Omówi, wytłumaczy i uzasadni, żeby ludzi zaangażować, zdobyć wsparcie zespołu, zbudować zaufanie.

Categories: Leadership, Product Owner.