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.
Link do oryginalnego badania: http://journals.sagepub.com/doi/abs/10.1177/0956797618761659
Źródło obrazka w nagłówku: By Anna Tunikova for peats.de and wikipedia [CC BY 4.0 (https://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons
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ę?
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
Czytaj dalej Stack Overflow Developer Survey 2018 okiem Scrum Mastera
„Grubiorze mieli fatalny Sprint. Nie dostarczyli praktycznie nic. Velocity = 3. Porażka. Ale wystarczyło, że konkretnie ich ochrzaniłem i nastraszyłem, żeby w kolejnym Sprincie było już ok. Myślę teraz, żeby dawać im lekki, ale regularny ochrzan co Sprint.”
Rafał (44 l.), Product Owner w zespole „Grubiorze”
Czytaj dalej Ochrzan mobilizuje. Pochwały demotywują. Homeopatia działa.
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.
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.
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.
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
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:
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.
