Aktualizacja Scrum Guide 2017

Twórcy Scruma, Jeff Sutherland i Ken Schwaber, od czasu do czasu aktualizują treść Podręcznika o Scrumie (ang. Scrum Guide), poprawiając sformułowania konkretnych wytycznych, albo ewoluując jego zasady na bazie tego, co wciąż w praktyce obserwują w zespołach korzystających z tego frameworka. 7 listopada 2017 w trakcie webinara ogłoszone zostały najnowsze zmiany: dookreślenie możliwych kontekstów, gdzie zastosowany może być Scrum, dodefiniowanie roli Scrum Mastera, uwypuklenie aspektu inspekcji i adaptacji w ramach Codziennego Scruma, łopatologiczne wyjaśnienie czym są „timeboxy” i dodanie praktyki uwzględniania w Backlogu Sprintu zadań usprawnieniowych wynikających z Retrospektyw.

Samo ogłoszenie zmian było unikalną okazją do obejrzenia w akcji twórców (czy jak sami się określili – rodziców) Scruma, a prezentację zmian zapoczątkowała historia tego, jak Scrum powstał, skąd się wywodzi i jak ewoluował. Jeff z Kenem wyjaśnili też, dlaczego pojawiła się najnowsza aktualizacja – zbierali informację zwrotną ze strony użytkowników Scruma za pomocą strony https://scrumguide.uservoice.com/ . Pojawia się tam duża słusznych sugestii zmian, ale też sporo pytań albo propozycji pokazujących niezrozumienie oryginalnych intencji, jakie stały za tym, jak Scrum był tworzony. W związku z tym część tegorocznych zmian to dalszy krok w ewolucji tego, jak Scrum jest stosowany, ale niektóre to raczej kosmetyczne zmiany w sformułowaniach, które mogły wzbudzać wątpliwości w poprzednim sposobie ich zapisu.

Jak Scrum Guide zmienił się w 2017 roku?

  • Dodanie akapitu na temat możliwości wykorzystania Scruma

Twórcy Scrum dookreślili, że wykorzystanie go nie jest ograniczone wyłącznie do świata wytwarzania oprogramowania. Jeff podał przykład klientów, z jakimi obecnie pracuje, m.in. firmy wydobywające ropę. Scrum Guide w nowym brzmieniu definiuje, że Scrum nadaje się do wszelkiego rodzaju sytuacji, w których wytwarzany jest produkt (dowolnego rodzaju), prowadzone są prace badawcze, rozwiązywany jest złożony problem itp.. Sercem Scruma jest zespół rozwiązujący te problemy dzięki podejściu iteracyjno-przyrostowemu i empiryzmowi.

  • Przeformułowanie roli Scrum Mastera

W definicji roli SMa użyto sformułowań lepiej oddających to, że jest liderem służebnym względem zespołu Scrumowego, zajmuje się promowaniem i wspieraniem zrozumienia Scruma przez zespół i organizację. Wyjaśnia osobom poza zespołu, jakie interakcje, w którym momencie sprintu są wskazane, a które niekoniecznie. Te delikatne sformułowania sugerują, że Scrum Master realizuje te wszystkie działania dzięki swoim umiejętnościom miękkim i dyplomatycznym. I jak podkreślił Ken – również dzięki cierpliwości, ponieważ Scrum Master mierzy się ze zmianą całej organizacji i jej kultury, co nie wydarzy się w krótkim czasie.

Przy definicji roli Scrum Mastera dodany został też fragment (nie wspomniany w trakcie webinaru) o tym, że SM w ramach wspierania Właściciela Produktu zajmuje się zapewnieniem, żeby wszyscy członkowie zespołu rozumieli cele, zakres i domenę produktu tak dobrze, jak to możliwe.

  • Zmiana w definicji Codziennego Scruma

Pierwszy akapit definiujący Codzienny Scrum uwypuklił, że jest to zdarzenie, które polega na codziennym planowaniu pracy przez zespół na najbliższe 24 godziny. Zespół dokonuje inspekcji pracy wykonanej od ostatniego Scruma i prognozowaniu tego, co zostanie wykonane w najbliższym czasie. Standardowe 3 pytania zostały wskazane w najnowszej wersji Scrum Guide tylko jako przykładowy sposób realizacji tego zdarzenia, a ważniejsze jest podkreślenie, że struktura spotkania zależy od Zespołu Deweloperskiego i najważniejsze, by pomagała w osiągnięciu celu sprintu.

  • Timeboxy to maksymalny sugerowany czas trwania zdarzenia

W sformułowaniach dotyczących timeboxów dla zdarzeń scrumowych dołożono podkreślenie, że to czas maksymalny. Dość trywialna zmiana i być może wyda się wielu zbędna, ale faktycznie spotykam osoby, które traktują sugerowane w Scrum Guide timeboxy jako wytyczną do całkowitego czasu trwania (np. retrospektywy). Jeff Sutherland przyznał, że widzi naprawdę dobre zespoły, które perfekcyjnie planują w pół godziny dwutygodniowy sprint. Wymaga to dobrze przygotowanego Backlogu Produktu, ale w żadnym wypadku nie jest naruszeniem zasad pracy w Scrumie. Podkreślił, że Scrum wymyślony jest po to, by dostarczać więcej wartości w krótszym czasie, więc wszystko, co realizuje tę wytyczną, jest zgodne z ideami scrumowymi. Timeboxing jest ścisłą granicą, której nie należy przekraczać, a nie wytyczną, ile dana aktywność powinna trwać. Przy okazji wyjaśniania, dlaczego mimo wszystko taka zmiana w sformułowaniu została zawarta w najnowszej wersji, Ken Schwaber błysnął złotą myślą „Scrum is not for people who can’t think” 😉

  • Ciągle usprawniaj jak Twój zespół pracuje

Do definicji Backlogu Sprintu został dołożony wzorzec sformułowany przez Scrum Patterns Group, podkreślający to, że zespół powinien usprawniać się w sposób ciągły, w każdym sprincie. By zapewnić, że efekty retrospektyw są wdrażane i sposób pracy zespołu się ciągle poprawia, w każdym sprincie przynajmniej jedna akcja wynikająca z retrospektywy powinna być włączona jako zadanie do planu pracy zespołu. Scrum nie zadziała, jeśli zespół nie ewoluuje swoich metod pracy.

  • Poprawa sformułowania, czym jest Przyrost

Ciekawym, drobnym dopiskiem w definicji przyrostu są podkreślenia, że Przyrost jest krokiem w stronę celu albo realizacji wizji. Musi być fragmentem ukończonego produktu, by wspierać empiryzm na koniec sprintu. Niestety w trakcie webinara Ken z Jeffem nie wspomnieli o tej zmianie, ani o intencjach tego doprecyzowania. Taka zmiana nie jest też nigdzie sugerowana na User Voice, ale te dodatkowe hasła definicji mogą pomóc zrozumieć, po co Przyrost jest robiony co sprint i że jest kolejnym kompletnym kawałkiem produktu przybliżającym nas do tego, co chcemy osiągnąć.

Popularne nieporozumienia związane ze Scrumem

Jeff i Ken skorzystali z okazji i pod koniec webinara rozwiali kilka mitów albo błędnych interpretacji na temat Scruma.

  • Scrum nie powinien być traktowany jako framework do wytwarzania oprogramowania. Dzięki Scrumowi można rozwijać produkty i usługi, bardzo odległe od świata software’u. Scrumem można też efektywnie dostarczać rozwiązania, w których oprogramowanie jest wyłącznie małym elementem składowym, a w obrębie sprintu realizowanych jest szereg różnorodnych czynności takich jak marketing, szkolenia, wdrożenia, uruchomienie produktu u klienta
  • Produkt może być wdrożony wcześniej niż na koniec sprintu. Efekty pracy zespołu mogą być dostarczone w dowolnym momencie uznanym za stosowny przez Właściciela Produktu i możliwym do zrealizowania przez Zespół. Praktyki Continuous Delivery nie są sprzeczne ze Scrumem a Przegląd Sprintu nie jest bramką decyzyjną, na której odbierany jest efekt pracy zespołu po to, by dopiero potem umożliwić ewentualne wdrożenie.
  • DevOps nie jest sprzeczny ze Scrumem – często osoby promujące koncepcje DevOps źle interpretują Scruma jako coś ograniczonego wyłącznie do rozwoju oprogramowania. Ken z Jeffem podkreślają, że zespół scrumowy ma za zadanie wytworzenie kompletnie działającego produktu, włącznie z tematem operacji, infrastruktury i możliwości wdrożenia. Organizacje, w których funkcjonuje DevOps, umożliwiają zespołom scrumowym sprawniejsze dostarczanie rozwiązań.

Ostatnią ciekawą myślą, jaką przekazał w ramach podsumowania Jeff Sutherland jest przestroga, by nie traktować Scruma jako menu praktyk, z których można sobie wybierać prostsze elementy i pomijać fragmenty trudniejsze. Scrum jest złożony z wzajemnie wzmacniających się składowych, które jak trybiki w zegarku – muszą wszystkie zadziałać razem, by dać spodziewany efekt. Rada od twórcy Scruma – Scrum Guide jest krótki, zaimplementuj jego wszystkie wytyczne i dopiero potem dalej usprawniaj go, by uzyskiwać jeszcze lepsze efekty.

Scrum Guide w wersji angielskiej jest już dostępny, polskie tłumaczenie jest też poważnie zaawansowane (ale w momencie pisania tego artykułu – jeszcze niedostępne publicznie). Osoby zainteresowane precyzyjną listą różnic między wersjami mogą też zajrzeć na stronę historii zmian Scrum Guide.

PS. Dziękuję Jackowi Wieczorkowi — autorowi książki Labirynty Scruma — za pomoc w przygotowaniu tego artykułu.

Link do slajdów z prezentacji

Link do filmu z nagraniem prezentacji

Źródło zdjęcia: https://www.scruminc.com/scrum-guide-revision-webinar

Jeden komentarz do wpisu: “Aktualizacja Scrum Guide 2017

  1. Dzięki za ciekawe podsumowanie. Mnie zastanawia kwestia przyrostu. Poza dopracowaniem definicji Przyrostu, słowo increment zostało dodane w różnych miejscach pięciokrotnie.
    Szkoda, że ta zmiana nie została rozwinięta w trakcie webinaru.


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