Scrum Master – Happiness Dealer?

Co jakiś czas na forach i grupach agile’owych pada pytanie czy i jak jako Scrum Masterzy mierzycie poziom satysfakcji/zadowolenia/szczęścia w zespołach?. Ciężko polemizować z faktem, że dobra atmosfera w firmie i zespole pozytywnie wpływa na poziom zadowolenia pracowników oraz że zadowolony pracownik zwykle pracuje efektywniej. Ale czy obowiązkiem akurat Scrum Mastera powinno być zbieranie i analizowanie danych na ten temat? I wykraczając poza ramy Scruma – czy firmy, nawet mając najszczersze intencje, nie ingerują czasem zbyt głęboko w życie pracowników próbując mierzyć i zarządzać szeroko rozumianym poczuciem szczęścia, a nie tylko satysfakcją z pracy?

Czytaj dalej Scrum Master – Happiness Dealer?

W skomplikowanym związku z JIRĄ

Niedawno na blogu QAgile rozpoczął się bardzo fajny cykl artykułów o tym jak przy pomocy JIRy zabić zwinność. Tym razem kamyczek do Atlassianowego ogródka leci ode mnie *sploooonk*

Ponad 9 lat zajęło Atlassianowi dodanie funkcjonalności, która pozwala edytować zapisane filtry i pulpity (dashboards) przez kogokolwiek innego niż ich twórcę. Nawet admin nie mógł tego zrobić wprost, musiał zmienić ownera i dopiero nowy owner mógł cokolwiek edytować 🤦‍♂️🤦‍♂️🤦‍♂️

Okej, ale co to ma wspólnego z zabijaniem zwinności, poza tym, że sam Atlassian jest zwinny jak Gojira xD? Ano to, że tak mało elastyczne narzędzie nakłada spore ograniczenia na samoorganizujące się zespoły.

1) Jeśli tylko jedna osoba może edytować filtry i pulpity z burndown chartem i innymi gadgetami to w przypadku jej nieobecności zespół na dzień dobry ma problem.

2) Jeśli tylko jedna osoba ma prawa edycji to dużo bardziej prawdopodobne, że odpowiedzialność za wszelkie zmiany spadnie na Scrum Mastera jako, że popularne rozwiązanie w w postaci rotowania takiej odpowiedzialności w Zespole Developerskim odpada z powodu zbyt dużego narzutu.

Pomarudziłem to teraz idę świętować rozwiązanie JRASERVER-17783 🍾🥂
https://jira.atlassian.com/browse/JRASERVER-17783

pic: zdjęcie przedstawia mocno wyidealizowany obraz mojej relacji z JIRą

Scrum Values na retrospekcji

Tym razem krótko w temacie pięciu wartości, na których opiera się Scrum.

Prawie równo dwa lata temu Scrum Values oficjalnie weszły do Scrum Guide’a, choć wcale nie były nową koncepcją. Pierwszy raz pojawiły się… w pierwszej (i mojej ulubionej) książce o Scrumie „Agile Software Development with Scrum” (https://amzn.to/2fEZcQ5) i od tamtego czasu orbitowały wokół trzech filarów Scruma: transparencji oraz inspekcji i adaptacji.

Code Review – dlaczego tak trudno o dyscyplinę?

Jest wiele powodów, dla których utrzymanie dyscypliny i regularność przeprowadzania inspekcji kodu nie jest zadaniem łatwym. W tym krótkim wpisie chciałem przyjrzeć się bliżej jednemu, ale za to takiemu, którego miałem okazję doświadczyć z trzech różnych perspektyw.

Czytaj dalej Code Review – dlaczego tak trudno o dyscyplinę?

R. I. P. Mike Beedle

To będzie krótki i smutny wpis. Mike Beedle, jeden z sygnatariuszy Agile Manifesto i współautor najważniejszej książki o Scrumie został zamordowany 23 marca 🙁

„Agile Software Development with Scrum” jest pełna odniesień do filozofii nauki (Kuhn), ewolucjonizmu (Dennett) czy teorii złożoności (Holland). Mike Beedle był gorącym zwolennikiem poglądu, że przejście z podejścia zdefiniowanego (Waterfall) na podejście zwinne, empiryczne (Scrum) spełnia kryteria rewolucji naukowej i zmiany paradygmatu w rozumieniu przedstawionym przez Thomasa Kuhna w książce „Struktura rewolucji naukowych”.

Śmierć Mike’a to ogromna strata dla społeczności 🙁

Poniżej link do zbiórki ze wsparciem dla rodziny: https://www.gofundme.com/mikebeedlesupport?lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3B48aBFqgbSU6sjXR7EKT%2Fdg%3D%3D

Stack Overflow Developer Survey 2018 okiem Scrum Mastera

Ósmy rok z rzędu Stack Overflow publikuje wyniki ankiety przeprowadzonej wśród członków społeczności. Poniżej mój subiektywny wybór pięciu najciekawszych spostrzeżeń z perspektywy Scrum Mastera.

Czytaj dalej Stack Overflow Developer Survey 2018 okiem Scrum Mastera

Cone of uncertainty

Cone of uncertainty (czyli rożek/stożek/lejek niepewności) w większości publikacji związanych z zarządzeniem projektami definiuje się jako krzywą obrazującą następującą obserwację: „to jak dużo będzie kosztował projekt, jesteśmy w stanie tym dokładniej oszacować, im na dalszym etapie realizacji tego projektu jesteśmy”. A zatem, na początku rozrzut szacunków jest ogromny i maleje aż do osiągnięcia (teoretycznie) pełnej dokładności na końcu projektu. Szeroki na początku lejek niepewności zwęża się do zera wraz z upływem czasu.

Cone of uncertainty
źródło: http://www.agilenutshell.com/cone_of_uncertainty

 

Istnieje jednak druga definicja (nie druga interpretacja tego samego zjawiska), mniej znana, choć mi osobiście bliższa, mówiąca, że z perspektywy teraźniejszości im dalej chcemy zerkać w przyszłość, z tym większą niepewnością musimy się mierzyć, przede wszystkim, jeśli chodzi o to, co w ogóle będziemy robić. Tym razem, wąski na początku stożek niepewności rozszerza się wraz z okienkiem czasowym, stanowiącym granicę tego jak daleko w przyszłość sięgamy w naszych przewidywaniach.

Cone of uncertainty

W tym krótkim wpisie chciałbym odrobinę bliżej przyjrzeć się obu definicjom, podkreślając jeszcze raz, że nie do końca są to konkurujące interpretacje tego samego zjawiska, a raczej dwie różne obserwacje.

Czytaj dalej Cone of uncertainty

Nexus Guide 2018 – zmiany okiem młodego Scrum Mastera

Częstym zarzutem w stronę twórców Scruma jest to, że promując wartości płynące z częstej inspekcji i adaptacji, sami nie stosują się do swoich zaleceń i zmiany do frameworka wprowadzane są bardzo rzadko. Faktycznie przez pewien czas można było odnieść takie wrażenie, ale ostatnio pod wpływem ożywionych dyskusji na stronie Scrum Guide – User Voice, dostaliśmy uaktualnienie Scrum Guide’a (listopad 2017), a kilka dni temu Nexus Guide’a, czyli przewodnika po tym, jak skalować Scruma na 3 do 9 zespołów pracujących nad jednym produktem. O zmianach do Nexus Guide kilka słów poniżej.

Czytaj dalej Nexus Guide 2018 – zmiany okiem młodego Scrum Mastera

Memiczny Planning Poker

Z lekką obsuwą, ale są – memiczne karty do estymacji zadań metodą Planning Poker ®.

Karty warto wydrukować na twardszym papierze, w formacie większym od A4 (np. B4), koniecznie na drukarce dobrze radzącej sobie z dokładnym wydrukiem dwustronnym (inaczej brzegi kart z przodu i z tyłu nie będą się pokrywać).

PDF do druku: Planning-Poker-Memes.pdf

Przód:

Czytaj dalej Memiczny Planning Poker

„Labirynty Scruma” – recenzja

Książek o Scrumie autorstwa polskich ekspertów, znających polski rynek i jego specyfikę jest dosłownie kilka (a szkoda, bo to nie tylko moja subiektywna obserwacja, że w Polsce naprawdę dużo się dzieje, jeśli chodzi o zwinne podejście do rozwoju oprogramowania). Kilka miesięcy temu nasza rodzima oferta powiększyła się o „Labirynty Scruma”, książkę autorstwa Jacka Wieczorka, Agile Coacha i wieloletniego praktyka metod zwinnych.

Czytaj dalej „Labirynty Scruma” – recenzja