Odświeżenie Scrum Guide’a – co zmienia się w Scrumie w 2016 roku?

ScrumValues6 lipca 2016 twórcy Scruma (Jeff Sutherland i Ken Schwaber) ogłosili kolejne odświeżenie zasad Scruma zawartych w Przewodniku po Scrumie. Jeff i Ken wyjaśnili, co zmienili i z czego wyniknęła potrzeba kolejnej ewolucji podstaw Scruma. Rozszerzyli też wprowadzone zmiany o swoje interpretacje tych zapisów i historie, jakie za nimi stoją.

W porównaniu do poprzedniej zmiany (z 2013 roku) tegoroczne odświeżenie Scruma wydaje się być niewielkie. Trywializując sprawę, można powiedzieć, że wszystko, co zrobiono, to raptem dodano “Wartości Scruma” do początkowych sekcji Przewodnika po Scrumie. Jeff z Kenem zbierali informacje zwrotną od użytkowników Scruma i sugestia dodania Wartości Scrumowych do podstawowej definicji Scruma była najczęściej pojawiającą się propozycją.

Dlaczego Wartości zostały dodane do Przewodnika po Scrumie?

Twórcy Scruma przywołali kilka anonimowych historii o tym, że istnieją organizacje, które próbują mechaniki Scrumowej, ale nie mają spójnych ze Scrumem wartości, co blokuje jakiekolwiek korzyści z tego podejścia. Wartości w Scrumie są szkieletem, to wartości czynią mechanikę scrumową skuteczną. Dzięki wartościom scrumowym tworzy się w organizacjach kultura pomagająca ludziom pracować wspólnie, ufać sobie, usprawniać się na poziomie zespołu i całej firmy. Ken Schwaber podkreślił, że wartości scrumowe nie są nowym elementem Scruma, są już wymienione w jednej z pierwszych książek o Scrumie – “Agile Software Development with Scrum”.

Wartości Scrumowe – co to jest?

Jeff z Kenem w ramach ogłoszenia zmian przybliżyli swoje zrozumienie 5 Wartości Scrumowych – Zaangażowania, Skupienia, Otwartości, Szacunku i Odwagi.

Zaangażowanie – członkowie zespołu są zaangażowani – zobowiązują się wzajemnie przed sobą, że będą starać się najlepiej jak potrafią przy wykonywaniu pracy. Zobowiązują się też do ciągłej poprawy, zmieniania sposobu pracy zespołu i całej firmy. Ken przywołał metaforę drużyny sportowej – bez zaangażowania wszystkich członków zespołu nie ma możliwości wygrywania. Nie ma możliwości korzystania z korzyści pozostałych elementów Scruma, jeśli nie ma zaangażowania. Poprawnie stosowana mechanika nic nie zmieni, jeśli członkom zespołu będzie wszystko jedno, czy sprinty się udają czy nie, czy jest potrzeba się usprawniać i tak dalej.

Skupienie – kolejna z podstawowych wartości scrumowych, zaszytych w Scrumie między innymi w koncepcji sprintu. Cały Zespół skupia się na tym, by zrealizować kolejny przyrost produktu, nie daje się odciągać od swojej pracy jakimkolwiek rozpraszaczom ze strony innych projektów czy zleceń ze strony menedżerów poza Backlogiem Sprintu.

Otwartość – żeby zrozumieć, gdzie jesteś i gdzie zmierzasz, wszystko co zespół robi, musi być widoczne (stąd też jeden z filarów Scruma – Przejrzystość). Tylko wtedy, gdy wśród wartości, jakimi kierują się członkowie zespołu i organizacja jest otwartość, jest miejsce na to, by postęp pracy był widoczny, usprawnienia odbywały się systematycznie, przewidywania co do zakończenia prac były wiarygodne. W pełni zachowana otwartość w Scrumie wprowadza swego rodzaju kontrkulturę, przeciwieństwo do typowego w organizacjach ukrywania się, chowania słabości i nie przyznawania się do niedociągnięć. Twórcy Scruma mocno nawiązali do filozofii Lean – każdy zespół powinien otwarcie umieć określić “jaki jest nasz największy problem”, wiedzieć, jak się z tym problemem mierzy i czy są widoczne usprawnienia z dotychczasowych starań.

Szacunek – wartość bardzo blisko otwartości. W wielu organizacjach bardzo trudno o otwartość (w tym otwartość w przyznaniu się do błędu), jeśli członkowie zespołów czy menedżerowie osądzają się wzajemnie, szukają winnych. Brak szacunku we wzajemnych relacjach generuje postawy ukrywania prawdy. Wszystkim członkom Zespołu potrzebny jest szacunek dla słabości, dla różnicy zdań, również szacunek dla przyznania się przez kogoś z zespołu, że ma się problem i potrzebuje się pomocy.

Odwaga – żeby Scrum w danym zespole czy organizacji był skuteczny, wszyscy członkowie zespołów muszą mieć odwagę, rozumianą w tym przypadku jako zdolność do podejmowania ryzyka. Potrzebna jest odwaga, by się zmieniać, odrzucać stare metody postępowania i szukać nowych, lepszych podejść. Usprawnienia nie pojawią się, jeśli poszczególne osoby i całe zespoły nie będą miały odwagi zaryzykować, eksperymentować, nawet jeśli od czasu do czasu będzie się to wiązało z kosztami pomyłek czy nietrafionych pomysłów. Framework Scruma tworzy swego rodzaju siatkę bezpieczeństwa (ang. safety net) dla takich prób (zarówno na poziomie procesu współpracy jak i produktu) – próbujemy zrobić coś w określonym skończonym czasie (sprint) i sprawdzamy czy to przynosi efekty, czy oczekiwana zmiana zachodzi. Praca w krótkich odcinkach czasu i poprawa produktu albo procesu kawałek po kawałku zdejmuje ciężar z barków, nie musimy idealnie trafić z wielkimi rewolucyjnymi poprawkami, możemy do usprawnienia dojść ewolucyjnie.

Aktualna, oryginalna wersja Scrum Guide (po angielsku) i) dostępna jest na stronie scrumguides.org, sukcesywnie pojawią się tam też tłumaczenia w innych językach. W przygotowaniu jest też polska wersja.

Na zakończenie prezentacji zmian w Scrum Guide odbyła się sesja pytań i odpowiedzi, które w gruncie rzeczy nie były związane z  samą aktualizacją, ale ponieważ są to ciekawe odpowiedzi na bardziej ogólne pytania o Scruma jako takiego i trendy, jakie twórcy Scruma dostrzegają w szeroko rozumianym rozwoju software’u, przytaczam poniżej skrót tych wypowiedzi w formie “surowej”.

Całość prezentacji zmian w Przewodniku po Scrumie Jeff z Kenem podsumowali powtórzeniem pewnej myśli uzasadniającej oficjalne dołączenie Wartości: Widzimy organizacje, w których Scrum nie działa i często wynika to z braku wartości organizacji spójnych z wartościami scrumowymi. Jeśli chcesz uzyskać korzyści wynikające ze Scruma, musisz żyć jego wartościami. Jeśli chcecie poczytać więcej o koncepcji wartości scrumowych, polecam również zestawienie czym są wartości Scrumowe spisane przez Gunthera Verheyen.

KenSchwaber_JeffSutherland

Sesja pytań i odpowiedzi z twórcami Scruma:

Dlaczego refinement nie jest zdarzeniem scrumowym?

Refinement można robić na różne sposoby, celem refinementu jest gotowy Backlog Produktu. Są zespoły które robią to przez cotygodniowe spotkania, inne pracują nad Backlogiem codziennie po kawałku. Refinement to też ciągła praca PO – to jest proces w trakcie sprintu a nie osobne zdarzenie. Scrum Guide ma mieć minimalny zestaw wymagany by mieć Scruma, “less not more”. Refinement jest praktyką sytuacyjną, zależy od tego, co działa w danym zespole czy firmie – Jeff i Ken świadomie nie chcą tego doprecyzowywać.

Jaka jest różnica między prognozowaniem a zobowiązaniem? Co sądzą o nurcie #NoEstimates?

W ocenie Jeffa i Kena interesariusze projektowi często źle rozumieli to, co mówił zespół gdy podawał przewidywania – zespół mówił że jest to możliwe (zrealizowanie sprintu, stworzenie przewidywanego zakresu releasu), a nie że na pewno się to wydarzy. Dlatego w 2013 nazwali to prognozą, żeby to podkreślić – to jest możliwe, ale nie wiemy na 100%, bo wytwarzanie oprogramowania jest dziedziną złożoną i wiele rzeczy może się wydarzyć, które wpłyną na realizację wcześniejszych planów. W wielu firmach wprowadza się szczegółowe rozliczenie zobowiązań zespołów i jest to w ocenie Kena dysfunkcjonalne.

Co do #NoEstimates – przywołane została badanie Rally Software, które sprawdziło różne aspekty ponad 14.000 zespołów scrumowych. Najwolniejsze zespoły estymowały swoją pracę w godzinach. Kolejne najwolniejsze to zespoły, które nie estymowały – byli średnio rzecz biorąc trochę szybsi niż Ci co szacują w godzinach; najszybsze są te zespoły, które dzielą backlog na małe historyjki i szacują je w storypointach. #NoEstimate działa dla zaawansowanych zespołów, ale mniej doświadczonym trudno o konkretne zaangażowanie i prognozowanie dostarczenia, jeśli nie ustalają wielkości tego, co mają do zrobienia w ramach sprintu.

Dlaczego ludzie decydują się antywzorce, takie jak na przykład sprint zero?

Ludzie robią to, żeby ominąć dysfunkcje swoich organizacji, przykrywają problemy. Jeff pytał menedżerów w Dolinie Krzemowej (gdzie jak twierdzi 80% zespołów robi “Agile In A Name Only”) dlaczego ktokolwiek płaci Scrum Masterom i Agile Coachom za to, że co sprint nie ma działającego produktu. Ludzie wymyślają niesamowite rzeczy, by uniknąć prawdziwego celu – działające oprogramowanie na końcu każdej iteracji, co jest fundamentalną podstawą Scruma. Nawet zdobywający popularność DevOps w wielu zespołach nie rozwiązuje podstawowej kwestii – czy produkt każdego sprintu jest rzeczywiście “Done”.

Dlaczego Scrum Guide nie wspomina o skalowaniu, czy twórcy Scruma planują coś o skalowaniu dodać?

Jeff: 20 lat temu skalowaliśmy Scruma i nie było problemu. Nagle pojawiły się frameworki skalowania, niektóre z nich całkiem dobre, ale często dodają niepotrzebne dysfunkcje, jak sprint zero czy sprint stablizacyjny. Ken: Skalowanie jest bardzo zależne od firmy, nie możesz przepisać recepty jak firma to powinna robić, bo zależy to od wartości biznesowej, sytuacji rynkowej, produktu, technologii. Scrum Guide jest dokumentem minimalistycznym, nie zawiera w sobie wielu praktyk, w tym planowanie releasów, technik pracy z backlogiem czy współpracy zespołu, oraz również skalowania. To jest świadomy zabieg i tak pozostanie.

Przez 20 lat jakie są największe zmiany, jakie twórcy Scruma zaobserwowali?

Scrum rozwinął się na niesamowitą skalę. Jeff miesiąc temu był na spotkaniu polityków samorządowych i państwowych w Berlinie. Rozmawiali ze sobą o tym, jak zrobić, by Berlin był agile, by mógłbym być globalnym centrum zaawansowanych technologii. Rozmawiali o tym, jak zrobić scrumowy framework na poziomie polityki państwa i samorządu. Tego Jeff by się nie spodziewał, gdy zaczynał pracować Scrumem w swoim pierwszym zespole.

Ken stwierdził że 20 lat temu software nie był tak dużym problemem, teraz społeczeństwo, świat finansów, obieg informacji jest połączony i działa głównie dzięki różnego rodzaju oprogramowaniu. W czystym waterfallu taka rewolucja by się nie udała.

Komentarze do wpisu: “Odświeżenie Scrum Guide’a – co zmienia się w Scrumie w 2016 roku?

  1. „przewidywania co do zakończenia prac były wiarygodne.” czy ideą Scruma, nie jest ciągły rozwój produktu? Czym jest wtedy ten termin zakończenia?

    pozdrawiam

    • Jakub Szczepanik

      Hej Kuba,

      To o co pytasz może być początkiem ślicznej i długiej wymiany poglądów, ale przytoczę najbardziej ewidentne dla mnie przypadki z praktyki gdzie „data zakończenia” (czegokolwiek – konkretnego feature’a, jakiegoś zakresu z Backloga, czy w innych organizacjach – poprostu jakiegoś projektu) jest potrzebna:

      – Produkt dostarczony przez zespół jest przedmiotem reklamy telewizyjnej – potrzebna jest przewidywana data, w której będzie można puścić reklamę. Ale to nie może być „jak skończymy to będzie”, bo cykl produkcji reklamy telewizyjnej ma swoje normalne czasy przygotowania a także odpowiednie wyprzedzenie czasowe wykupu miejsca antenowego. Bardzo kosztowne jest robić to w mgnieniu oka i na ostatnią chwilę.

      – Produkt dostarczony przez zespół mocno zmieni pracę dużego zespołu wewnętrznego zajmującego się Operacjami (np. obsługą klienta czy procesowaniem jakiejś usługi opartej w części na tym produkcie). Zespoły procesowe muszą być odpowiednio wcześnie poinformowane o tym, jakie zmiany wchodzą, przeszkolone z nowych funkcji, dopasowane muszą być procedury itd. I owszem taką zmianę również można wprowadzać przyrostowo, ale nawet wtedy potrzebny jest przewidywany kształt produktu będący efektem chociażby sprintu

      – Produkt dostarczany przez zespół jest usługą oferowaną partnerom, którzy potrzebują dokonać zmian po swojej stronie (np. usługi płatności online). Współpraca z partnerami wymaga poinformowania ich z wyprzedzeniem o naszych planach, Możemy ich poinformować, że jesteśmy gotowi, gdy już będziemy gotowi (czyli propagować wyłącznie 100% pewne informacje), ale wtedy na własne życzenie wydłużamy sobie lead time. Zamiast tego możemy propagować bardzo prawdopodobne informacje (np. planowany kształt interfejsu, który w dużej części zaimplementowany jest już na jakiejś wersji środowiska) licząc na to, że zespół z dobrą trafnością poda przewidywany czas zrealizowania reszty zakresu.

      Przewidywanie pozostaje prognozą, nie sztywnym zobowiązaniem, które musi być zrealizowane za wszelką cenę. Ale sam fakt „ciągłego rozwoju produktu” nie może stać się automatyczną wymówką: „pracujemy w Scrumie więc nie możemy podać Ci jakiejkolwiek daty przewidywanego zakończenia” (upraszczam, ale słyszałem takie przypadki).

      • Rzeczywiście chciałem trochę sprowokować do wymiany poglądów. Przykłady podane przez Ciebie są oczywiste, bez dwóch zdań.
        Oczywiście zgoda, że brak przewidywanej daty zakończenia nie jest w większości przypadków akceptowalny ale też często na starcie prac estymaty co do terminu zakończenia(nawet jeśli dotyczą core’owych funkcjonalności) są z miejsca brane za sztywną datę zakończenia realizacji danego zakresu i skłonność do żonglowania zakresem jest niska. Trafia do mnie niuans poruszony w pierwszym pytaniu do Kena i Jeffa, używania określenia „prognoza” w przeciwieństwie do estymat.

        • Jakub Szczepanik

          No to ten niuans trafia już przynajmniej do dwóch osób.

          To co podajesz (pierwsza estymata staje się sztywnym deadlinem) jest faktycznie szarą rzeczywistością, czymś co Ken nazywał w innym pytaniu dysfunkcją. Pewnie jeszcze wiele wody w Wiśle upłynie i z jedna generacja menedżerów wymieni się w organizacjach zanim złożoność wytwarzania produktu zostanie zaakceptowana. A do tego czasu dla wielu projekt IT to będzie jak projekt budowy bloku mieszkalnego: „podaj zakres i termin przed rozpoczęciem pracy, potem będziemy go rozliczać”.

          Scrum on! 🙂

        • Data zakończenia może być przewidywaną datą konkretnego wydania lub MVP. Jeżeli bardzo ważna jest dla nas data, to możemy śledzić na bieżąco postęp i reagować także zmieniając zakres. Cześć PBI może wypaść albo zostać odchudzona do absolutnego minimum. Z mojego doświadczenia wynika, że bardzo często management wrzuca sporo „przydasi” do MVP lub ważnej wersji i kiedy pojawia się presja potrafią z tego zrezygnować. Wiadomo, że jak uzywamy średniej Velocity do planowania wydania, to tutaj też mamy margines błędu. Priorytetyzacja MoSCoW się przydaje w planowaniu zakresu. Najważniejsze, to nie upierać się na zmuszeniu zespołu na fixed scope i fixed date razem.

          Każdy kij ma dwa końce. Z jednej strony nie można zmuszać zespołu do 100% trafnych przewidywań. (Chociaż niektórzy upierają się, że dobry zespół to taki, który dowozi 100% Story Pointów zaplanowanych na Sprint Planning) Każdy dojrzały manager wie, że oszacowania zawsze są błędne. Z drugiej strony określenie prognoza nie daje przyzwolenia na pełen luz ze strony zespołu, bo z tyłu głowy powinni kierować się Zaangażowaniem i uprawiać Profesjonalny Scrum.

  2. Bardzo dobre wyjaśnienie wartości Scrumowych. Cenne tym bardziej, że w nowym Scrum Guide jest tylko krótka wzmianaka o tym, jak bardzo jest to ważne we właściwym rozumieniu i stosowaniu Scruma w organizacjach.


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