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

6 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 (jesteś product ownerem zaangażuj swój zespół)– 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 (story jam session czyli product backlog od zera w jeden dzień), 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.

[Aktualizacja grudzień 2020]: Zwróć proszę uwagę, że w aktualizacji Scrum Guide z 2020 roku wprowadzone zostało dużo zmian, w tym związanych z nazewnictwem (m.in. zmiana nazwy Ról na Odpowiedzialności, wprowadzenie zobowiązań w postaci Celu Produktu, Celu Sprintu i Definicji Ukończenia). Powyższy artykuł odnosi się do zmian z 2016 roku i zachowuje ówcześnie obowiązującą nomenklaturę, można go traktować jako artykuł historyczny, będący zapisem pewnego momentu w czasie w rozwoju metod zwinnych.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x