Aktualizacja Przewodnika po Scrumie 2020

18 listopada 2020 roku twórcy Scruma podczas webinaru przedstawili najnowszą aktualizację w Przewodniku po Scrumie. W tym odcinku dzielimy się z Tobą na gorąco naszymi przemyśleniami na temat najważniejszych zmian. Odcinek nie pokrywa wszystkich modyfikacji, których jest ich dużo więcej, niż się spodziewaliśmy. Z odcinka dowiesz się, co szczególnie zwróciło naszą uwagę. Mamy też kilka wątpliwości, m.in. jakie faktyczne znaczenie dla zespołów zwinnych będą miały te zmiany? Sprawdź nasze pierwsze refleksje po aktualizacji i koniecznie samodzielnie zapoznaj się z aktualizacją Przewodnika po Scrumie.

Zobacz wersję wideo:

TRANSKRYPCJA

Jacek: Dzisiejszy odcinek, taki spontaniczny dosyć, poświęcimy, żeby skomentować z Kubą na gorąco aktualizację Przewodnika po Scrumie, która dzisiaj, 18. listopada została upubliczniona przez twórców Scruma. Jesteśmy świeżo po webinarze. Odpoczęliśmy trochę. Podyskutowaliśmy z Kubą o naszych przemyśleniach na gorąco i chcielibyśmy się tymi przemyśleniami z Tobą podzielić.

Kuba: Na pewno jest tak, że podkreślę również ja, odcinek będzie trochę bardziej spontaniczny, niż taki, do którego już przyzwyczajony lub przyzwyczajona. Sam też odcinek nie pokryje absolutnie wszystkich zmian, jakie w tym Scrum Guidzie nastąpiły. Jest ich nawet trochę więcej, niż się spodziewaliśmy. Stąd struktura odcinka będzie raczej skupiona wokół tego, że zaczniemy od punktów, które zwróciły naszą szczególną uwagę i wymienimy się listą pewnych przemyśleń i pewnych komentarzy na ten temat. No i w drugiej części odcinka, pod koniec odcinka, podzielimy się też kilkoma wątpliwościami, na takim trochę meta poziomie. Czyli mniej związane z tym, że Scrum się konkretnie zmienia w takich, a nie innych zdaniach, ale też, jakie to ma znaczenie dla zespołów zwinnych, dla ruchu zwinnego, czy dla społeczności praktyków zwinności. To zacznijmy może od tych przemyśleń. Same te przemyślenia też chcieliśmy w jakąś taką w miarę uporządkowaną listę zebrać. Co mamy na pierwszym miejscu Jacek?

Jacek: Na pierwszym miejscu mamy takie przemyślenie, właściwie obserwację, co do której się oboje zgodziliśmy, że co do zasady ten bardzo szeroko rozumiany kierunek zmian, jeśli chodzi o najnowsze wydanie przewodnika po Scrumie, no jest dobrym kierunkiem. Sporo konkretnych zmian, które zostały zaproponowane, to co do zasady są dobre zmiany. Również rzeczą, która zwróciła naszą uwagę i też pozytywne jest to, że ten cały dokument został skrócony. Więc nie mamy, zdaje się osiemnastu stron, tylko trzynaście. Natomiast czytając tak w pierwszym, czy drugim czytaniu, osobiście odnoszę wrażenie, że strony zostały zredukowane, natomiast nie czuję, żeby to miało negatywny impakt na wydźwięk tego, co pozostało jako treść.

Kuba: No i tu, jak Jacek mówi zgadzamy się. Ja sam czuję, że uproszczenie to jest dobry kierunek. Natomiast tutaj, to uproszczenie nie spowodowało jakiegoś pogorszenia, jakichś pominięć, czy dziwnych niezrozumień. W wielu miejscach nawet mamy do czynienia z przypadkiem, że nie dość, że pewien akapit, który w poprzedniej wersji przewodnika po Scrumie był dosyć rozbudowany, teraz jest sprowadzony raptem do kilku zdań. To jeszcze w dodatku te kilka zdań, jest o wiele bardziej konkretnych, niż pierwotne, czy poprzednie brzmienie tych myśli. Więc ogólny kierunek zmian w przewodniku po Scrumie, no zgadzamy się z tym, jak to jest reklamowane i sami byśmy to też tak określili. Uproszczona treść, mniej preskryptywna, jeśli to jest również, to jest polskie słowo, taka prosta kalka z angielskiego. No i co ważne też, fajnie, że jednocześnie przy tej  mniejszej ilości treści, większa jednoznaczność tego, jak to jest poukładane i zakomunikowane, czym Scrum jest i co to znaczy dobrze realizować, czy dobrze wykorzystywać metodę scrumową.

Jacek: Moim zdaniem jest to też sensowny kierunek, z tego względu, że nadal co do zasady i to nie uległo zmianie, Scrum pozostaje frameworkiem, czyli ramami postępowania. Z mojej perspektywy, im więcej rzeczy było przemycanych do przewodnika, tym większa była pokusa, że dokładnie tak właśnie trzeba robić. Tu słynny przykład z trzema pytaniami z Codziennego Scruma. On bardzo mocno sugerował, że właśnie tak to należy robić, czy taki też bardzo precyzyjny opis, jak powinien wyglądać Przegląd Sprintu. Tak więc, jeżeli to ma być framework, jeżeli to ma być lekkie, jeżeli to ma zmuszać nas do myślenia, no to odchudzanie, to jest zdecydowanie dobry kierunek.

Kuba: Kierunek, z którym się zgadzamy z Jackiem, że ten nowy Przewodnik wytycza, taka koncepcja podniesienia poprzeczki. W kilku miejscach mamy takie odczucie, czy tak sobie te zmiany interpretujemy, że o wiele bardziej na serio Scrum wytycza jakieś podpowiedzi, jak powinna być realizowana praca zespołu. Jak powinien być umiejscowiony w organizacji? Bardzo konkretnie podnoszona jest poprzeczka Scrum Mastera, o czym jeszcze trochę wspomnimy. Natomiast mamy takie poczucie, że Scrum stał się w tej wersji trochę bardziej wyrazisty i może również z tego powodu trochę trudniejszy.

Jacek. No zdecydowanie ta poprzeczka podniesiona na wielu aspektach jednocześnie, no tak przeglądając, pod wieloma tymi podniesieniami poprzeczki bym się podpisał. Z jednej strony one potrafią być takie dosyć banalne, jak na przykład „Product goal” po angielsku. No i tak, z jednej strony patrząc fajnie, że to zostało dodane. Z drugiej strony, to może być jakaś, nazwijmy to przeszkoda dla wielu organizacji. No bo wiele tych elementów, które zostały wskazane jako część Scruma, one nie występują w wielu zespołach, jeśli by spojrzeć przekrojowo przez rynek. Więc z jednej strony fajnie, że ta poprzeczka poszła w górę. Natomiast z drugiej strony ten taki niełatwy Scrum do zaimplementowania, już w tej wcześniejszej wersji, stał się jeszcze bardziej prosty w opisie i jeszcze trudniejszy w implementacji.

Kuba: Czyli trochę parafrazując to, co powiedziałeś, intuicyjny, czy taki bym powiedział przeciętny zespół, jaki spotkamy w przyrodzie, który miałby wystartować ze Scrumem, zacząć go wykorzystywać, ma prawdopodobnie jeszcze większy dystans do pokonania, co ma swoje plusy, ale może też oznaczać taki trochę ekskluzywny charakter Scruma. Wiele zespołów widząc, jak daleko im jeszcze do wykorzystania Scruma, albo jak firma może się zmienić, może sobie odpuścić. Nawet nie aspirować do tego, żeby z tej metody skorzystać. I to może oznaczać, że to będzie coraz bardziej taki nieosiągalny ideał piękna, a nie coś, co jest bardzo praktyczne, pragmatyczne i możliwe do zastosowania w wielu firmach i w wielu kontekstach. Zwłaszcza że coś, co dostrzegamy, to to, że Scrum już naprawdę konkretnie zaznaczył fakt, że wykorzystywany jest do wielu przedsięwzięć, a nie tylko do wytwarzania oprogramowania.

Jacek: Tego trochę mi zabrakło w sumie w trakcie webinaru. Takiego odniesienia się do stanu rzeczywistego, w którym wiele organizacji nie korzysta ze Scruma w sposób, który został opisany. I nie chodzi mi tutaj o to, żeby być tak bardzo książkowym. Bardziej chodzi mi o to, żeby w sposób świadomy używać tego frameworka. Po cichu w cudzysłowiu twórcy podnieśli poprzeczkę. Natomiast bardzo mało, z mojej perspektywy, czasu webinaru zostało poświęcone na dyskusję – No dobrze, to teraz jak to zrobimy w praktyce? Było sporo zachwytów nad jakimiś tam konkretnymi aspektami.

Kuba: Przybijanie piątek.

Jacek: Dokładnie. Akurat ten, to z mojej perspektywy w ciemno strzelam Kuba, że się zgodzisz, to to jest problem. Jakby jakość tych implementacji. Tak więc poprzeczka podniesiona wysoko. Trochę czuję niedosyt, jakby kto tę lukę wypełni, czy kto to dociągnie? Może Scrum Master? No wrócimy jeszcze do tego tematu. Natomiast no czuję tutaj pewnego rodzaju ryzyko, że to może nie wyglądać w praktyce tak kolorowo, jak twórcy Scruma sobie wyobrażają.

Kuba: I idąc dalej, było takie hasełko, które powiedział chyba JJ Sutherland, czyli niekoniecznie już było ogłaszane, tylko to był bardziej komentarz do tej zmiany, że Scrum się nie zmienił, tylko opis jest lepszy. On chyba się powołał, że to Ken Schwaber powiedział, gdy oni się przygotowywali do tej zmiany. To jest ciekawa obserwacja. Tu nie chodzi o to, żeby tutaj epatować swoim własnym ego, ale i tak nie mogę się powstrzymać. No bo na przykład taki temat, który został w tym Scrum Guidzie mocno dodany, to czyli temat celu produktu. To jest coś, co w moim sposobie pracy z zespołami było ewidentne, niezbędne. W zasadzie pierwsze pytanie, od którego powinniśmy zaczynać w budowaniu zespołu, no to jest cel produktu. Nawet nie, kto jest Product Ownerem, tylko jaki jest cel produktu, bo cała reszta wokół tego orbituje. Jak zdefiniujemy produkt, kto jest właściwym Product Ownerem, jaki jest potrzebny zespół, cała reszta jest pochodną tego, jaki mamy cel i dokąd zmierzamy. No i tutaj wokół tego wątku w sumie Ken i Jeff trochę też opowiedzieli, że no w zasadzie ten Scrum zawsze taki był, tylko może on nie był tak dobrze opisany, albo też wiele zespołów tak dokładnie to realizowało. No i tutaj ja doceniam to, że jest dalej ciągły kontakt z pewną rzeczywistością, taką prawdziwą, projektową, czy biznesową. I ten fakt, że wiele z tych zmian jest bardzo spójnych z tym, co ja, czy Jacek też na pewno obserwujemy obaj w naprawdę dobrych zespołach, te elementy nie wymagają zmiany. Te zespoły już takie są.

Jacek: Tak. Tak, żeby dać jakieś przykłady. Powiedziałeś o celu produktu. Dla mnie nieodłącznym elementem startu z kolei zawsze była wizja produktu. Inny przykład. to jest też w nowym wydaniu, bardziej wyraźniej jest zaakcentowana jedność pomiędzy osobami, które są, nazwijmy to, w rolach biznesowych, a osobami, które są w roli developerskiej. Czyli teraz mówimy bardziej o Zespole Scrumowym, gdzie nie mamy ról konkretnych, a raczej odpowiedzialności. No i to też jest absolutny klasyk, w sensie nadal pokutuje w wielu organizacjach takie podejście, że zespoły developerskie, w szczególności, jeśli mówimy o rozwoju oprogramowania, to jest jakiś Software House. Albo, że są to zespoły – one są nazywane wykonawcze. Ja na nie mówię podwykonawcze, bo trafiają do nich już takie bardzo konkretnie zdefiniowane wymagania. I właściwie tej przestrzeni na jakąś co-kreację nie ma. No i ta granica między biznesem, a IT, no to to jest, no niestety coś, co nadal bardzo często obserwuję w różnych organizacjach. Tutaj ten akcent jest postawiony trochę inaczej. Faktycznie jest tak, pewne teamy, czy wewnętrznie czuły, czy po prostu inspirowały się nie tylko Scrumem, ale ogólnie szeroko rozumianym ruchem zwinnym, po prostu naturalnie tak pracowały, bądź sobie wypracowywały. Tak więc dobrze, że zostały te wybrane aspekty, o których mówiliśmy wyszczególnione. Natomiast pytanie brzmi, jakie inne nie zostały, które na przykład warto byłoby zaakcentować. Czyli mi jest bardzo blisko do takiego podejścia, w którym robimy właściwe rzeczy, czyli cały ten aspekt odkrywania produktu. To również jest coś, co mogło być wskazane, tak jak ten cel produktowy, nie zostało. No i pewnie takich dobrych pomysłów stosowanych przez najlepsze zespoły jest więcej. No twórcy zdecydowali, żeby właśnie ten aspekt dołożyć. Tak jak mówię, tutaj jakby jestem nie tyle sceptyczny. Zastanawia mnie to, dlaczego te, a nie inne rzeczy. Dlaczego akurat ta nakazowość poszła w tym kierunku, a nie w innym? No, ale na koniec dnia jakby cieszę się, że ten akcent produktowy został nieco bardziej wzmocniony.

Kuba: W tym wątku ja też mam pewną taką rysę, czy taką wątpliwość. Nie będzie to nadmierna krytyka, ale coś, co troszkę mnie zaczęło drażnić właśnie w dalszej części webinaru związanych z ogłoszeniem, gdzie kolejne osoby, bardzo istotne w nurcie scrumowym, bo to to między innymi w webinarze uczestniczył CEO Scrum.org, gdzie oni sobie wszyscy właśnie mówię, przybijali piątki, jedli z dziubków zachwyceni, jak to wspaniale ten nowy Scrum jest jeszcze lepszy, niż ten poprzedni Scrum. Ja mam trochę problem z tym, jak takie zamiany będą odbierane i mam też trochę problem z takim dwójmyśleniem. Trochę nawiązanie może do „Folwarku zwierzęcego”, że zmieniają się reguły i teraz nagle chór zachwyconych osób potwierdza, jakie to jest wszystko wspaniałe i tak dokładnie powinno być już dawno. No i ja się boję, że w ramach tego chóru zachwytów, będzie też takie lustrzane odbicie, chór hejtu na to, co się robi nie tak. Bardzo się boję tego, że za chwilę będzie korygowanie każdego, kto jest ze Scrum Guide’a w wersji siedemnastej i tam użyje jakiegoś słowa typu, rola scrumowa, która ze Scrum Guide’a wylatuje, albo zapomni nowych słów, które gdzieś tam się pojawiają. Bądźmy tu czujni na takie trochę właśnie, dla mnie to komunizmem pachnie, że partia mówi, że tak mamy teraz po nowemu myśleć, to my teraz przez noc przeformatowaliśmy wszystkie treści i gadamy po nowemu. Wiemy, że to stare to już jest błędne, bo zostało właśnie cofnięte, albo skrytykowane. Bądźmy na to czujni, ponieważ dzisiaj 2020 Scrum Guide jest świeży, ale może będzie nam dane doczekać kolejnych update’ów Scrum Guide’a. Może się okazać, że wszystko to, za co ktoś tam bardzo taki prawilny skrytykuje jakichś praktyków w najlepszych zespołach, najbardziej efektywnych. Może się okazać, że po miesiącu Scrum Guide 2023 powie, tak, wprowadźmy również praktyki Product Discovery i trzeba będzie się przeprosić.

Jacek: Kolejnym takim aspektem, który zwrócił naszą uwagę jest bardzo wyraźne zaakcentowanie leana obok empiryzmu w rozdziale, który mówi o fundamentach Scruma. Jest to o tyle z mojej perspektywy ciekawe, że znów, najlepsze zespoły mocno, albo ciężko inspirują się leanem i wykorzystują koncepcje stojące za tym pojęciem w swojej pracy. Też tak trochę przekornie powiem, nie czekając aż powstanie certyfikacja łącząca Scruma z leanem. A może nawet istnieje już? Bo sporo ich powstało. Natomiast, co do zasady, fajnie, że to padło. Z jednej strony bardzo sensowny krok. Z drugiej, czy nie istnieją jakieś inne fundamenty, które mogłyby się tutaj pojawić. Oczywiście, nie mi decydować. Natomiast z mojej perspektywy fajnie, że lean się pojawił. Fajnie, że został akcentowany. W szczególności ten aspekt, ja to tak czytam, ograniczania strat. No czyli gdzieś blisko marnotrawstwa, koncentracji na tym, co najważniejsze. No to znów, w racjonalnie funkcjonujących Scrumach, to gdzieś było. Dobrze, że zostało to zaakcentowane, jako coś, co teraz jest zgodne z najnowszym pojmowaniem, czym Scrum jest, a czym nie jest.

Kuba: Tu akurat z Jackiem mamy osobiste doświadczenie. Byliśmy na szkoleniu u Jeff’a Sutherlanda lata temu. Dla mnie samego to było mega zaskoczenie. Scruma już jakoś znałem, jakoś go praktykowałem. Zupełnie mnie zadziwiło, że pokaźny procent szkolenia może nawet i połowa, to były praktyki, techniki, filozofie powiązane z leanem, które wtedy były dla mnie trochę obce. Nie znałem ich też z poprzednich szkoleń scrumowych, gdzie była duża optyka konkretnych praktyk i technik scrumowych. Jednak ten lean gdzieś z tyłu głowy u tych źródeł Scruma był, tylko być może był schowany. No to na pewno jest mocny sygnał, że nie ma sprzeczności, czy jakiejś takiej świętej wojny, że jest agile i jest lean. No jeśli Scrum jest techniką zwinną, to ważne jest też podkreślenie, że ma on swoje mocne, konkretne i potwierdzone przez twórców korzenie i inspiracje wychodzące z leana. Co może być też mocnym sygnałem. Jeśli lean jest Ci obcy, to może zaczerpnij u dobrych źródeł, właśnie w tym obszarze.

Jacek: Kojena rzecz, która jest bardzo fajna, wartościowa i też uważamy z Kubą, że to jest ruch w dobrą stronę, to takie bardziej wyraźne zaznaczenie pewnej takiej jedności, spójności Zespołu Scrumowego i jednoczesne przywiązane odpowiedzialności za rezultaty do całego Zespołu Scrumowego. To nawet padł na webinarze ten przykład, o ile dobrze pamiętam, to z ust Kena, gdzie na przeglądzie Sprintu, Product Owner rozlicza zespół z tego co wytworzyli. Pokażcie, co zrealizowaliście. No znów, z mojej perspektywy coś absolutnie nieakceptowalnego. Coś, co jak widzę w zespole, to od razu ląduje to w moim notatniku, żeby następnie przekazać to w sesji feedbackowej. No, ale dobrze, że zostało to zaakcentowane. W sensie Zespół Scrumowy, jak sama nazwa wskazuje, to jest zespół. No i, pomimo że teraz to troszeczkę inaczej zostało nazwane, odpowiedzialności, wcześniej mówiliśmy o rolach. No to, pomimo że mamy różne role, czy teraz powinniśmy powiedzieć, różne odpowiedzialności, no to nadal jako zespół gramy do jednej bramki. Tak więc fajnie, że ten akcent został położony na team, a nie na konkretne role, czy odpowiedzialności.

Kuba: Te odpowiedzialności same w sobie też są warte tutaj dookreślenia, dopowiedzenia, zwłaszcza jeśli słuchasz nas, zanim przeczytałeś lub przeczytałaś ten update Przewodnika po Scrumie, no to tutaj konkretny kawałek dosyć istotnej zmiany. Scrum wyraźnie zauważa, że ówczesna, czy dotychczasowa rola Product Ownera i Scrum Mastera oraz zespołu wytwórczego, teraz są już odpowiedzialności. Co między innymi ma za sobą taką konsekwencję, że no to jest odpowiedzialność, więc po pierwsze pozostali członkowie Zespołu Scrumowego również mogą kontrybuować do wykonywania tej odpowiedzialności, tylko po prostu jest wskazana osoba lub osoby, które są ostatecznie odpowiedzialne. To niestety w polskim języku nie ma aż tak dobrego odnośnika. A druga kwestia, która też wcześniej może w praktyce była stosowana, ale z Przewodnika po Scrumie tak bardzo nie wynikała, no to ten fakt, że Product Owner i Scrum Master mogą być developerami. Mogą również kontybuować do realizacji prac. Coś, co w tych realiach, czy w tych takich korzeniach Scruma w świecie IT, może nie było aż tak oczywiste, bo Product Owner przychodzi z biznesu, Developerzy to są programiści i testerzy. Tak zwłaszcza w zastosowaniu Scruma w projektach czysto biznesowych, z którymi z Jackiem ostatnio mamy sporo do czynienia, pokazuje, że w zasadzie, z jakiego powodu Product Owner i Scrum Master mieliby nie kontrybuować do sukcesu zespołu. Zwłaszcza jeśli mają bardzo konkretne swoje doświadczenia, czy swoje umiejętności, które są w zespole bardzo przydatne. Więc tutaj Scrum staje się trochę bardziej uniwersalny i też trochę bardziej trochę holistyczny, czy zespołowy. Scrum Master, Product Owner, developer, to są odpowiedzialności i wspólnie cały Zespół Scrumowy odpowiada za wytwarzanie Increment’u co Sprint. Wszyscy razem za to odpowiadamy, nie ma tutaj jakichś odróżnień i czy subteamów na webinarze zostało wskazane, że jesteśmy teamem, ale w środku teamu, jest jeszcze wewnętrzny team.

Jacek: Kolejny punkt, który myślę, może wzbudzić sporo kontrowersji, sporo dyskusji, to jest punkt, który przypina do Scrum Mastera odpowiedzialność za efektywność Zespołu Scrumowego. Wcześniej nie było zdefiniowane to w ten sposób. Tak więc sam pamiętam wiele dyskusji w różnych kontekstach na temat tego, czy Scrum Master może, albo czy powinien odpowiadać za efektywność pracy w zespole. Czasem pojawiała się pokusa, żeby efekty pracy zespołu, żeby to też była odpowiedzialność Scrum Mastera. Tak więc było sporo takiej wieloznaczności i co organizacja można było spotkać różne podejście. No tutaj wyraźnie ta odpowiedzialność za efektywność jest przypięta do Scrum Mastera. Z mojej perspektywy, uważam to za dobry ruch. Między innymi dlatego, że ten Scrum Master, moim zdaniem zyskał taką pewną wyrazistość, sporą odpowiedzialność. Te wszystkie żarty, memy i historie o tym, jak Scrum Master pracuje z rękoma w kieszeni i tylko zadaje pytania, no to mogą przestać być śmieszne. No bo nagle się okaże, że faktycznie no ta odpowiedzialność jest z mojej perspektywy spora. W szczególności osoby, które są nowe w branży, no mogą mieć z mojej perspektywy spore wyzwanie przed sobą, żeby tę efektywność Scrum Teamu zapewnić. W sensie podnoszenie tej efektywności, no bo tak generalnie czytał ten zapis.

Kuba: W tym aspekcie, patrząc na to bardziej jako fragment, czy po prostu bardziej, jako intencję zmiany, warto też docenić wyrazistość konkretnego zdania. Cytuję: „Scrum Masterzy to prawdziwi liderzy działający na rzecz Scrum Teamu. Tutaj nie ma już takiego wieloznacznego servant leadership’u. O tym też Jeff wspomniał, powołując się na Kena, że to jest jedna z tych rzeczy, która jest dosyć niejasna. Co dokładnie to znaczy? Jak to jest realizowane w praktyce? W tej chwili jest tutaj najbardziej mocne jak się da, Scrum Master to prawdziwy lider zespołu. Tak dobrze jak to zdanie brzmi, tak jednocześnie zaczynam mieć wątpliwość, no bo używamy teraz słowa lider i sam wielokrotnie spotykam się z takim przypadkiem, jak w wielu kontekstach, w wielu firmach, w wielu zespołach, słowo lider może być albo bardzo mocne – na zasadzie, kapitan, przewodnik, człowiek, któremu ufamy, człowiek, za którym pójdziemy w ogień. Czyli takie bardzo pozytywne skojarzenia. No ale dla wielu innych lider, to jest taki najsłabszy rodzaj kierownika. Prawie bez władzy. Prawie bez kompetencji. Nikt go jeszcze nie awansował, albo nigdy już nie awansuje. Znowu jest tu problem, jak pewnie z wieloma kwestiami związanymi z definicjami, że używamy słów, które dla wielu osób mogą mieć tak różne znaczenie, że nawet zdania, które wiemy, że mają mieć wyraziste znaczenie, dla osoby nieznającej tych kontekstów i tych intencji, będzie – aha, to jest taki pierwszy szczebel zarządzania. Bałbym się tego.

Jacek: Natomiast sam ten akcent, na to słowo prawdziwy lider, tak jak oczywiście może być różnie zrozumiane, no to mi się bardzo podoba. W sensie takie dobrze rozumiane przywództwo, które oczywiście nie jest mikromanagementem. Ja to traktuję w takim rozumieniu, że ten Scrum Master bierze pewną odpowiedzialność, bo przywództwo jest odpowiedzialnością. Nie jest proste. No i tutaj prawdziwość tych liderów, z mojej perspektywy, jest też wskazówką, kto powinien być na tym stanowisku, czy teraz byśmy powiedzieli, kto powinien brać tę odpowiedzialność? No i to też pokazuje szerszy aspekt, czyli nie tylko działanie na rzecz Scrum Teamu, ale też organizacji, co oczywiście nie jest niczym nowym. No, ale też pokazuje, że to prawdziwe liderstwo ma się przewijać, pokazywać, czy mieć swój wydźwięk w organizacji. Czyli też rozmowy i współdziałanie z interesariuszami, z tom managementem, z kadrą dyrektorską, no co oczywiście wymaga pewnej postawy i dobrze, że to zostało tak silnie dosyć wyszczególnione w tej aktualizacji.

Kuba: Następny wątek, który wymienimy na tej liście takich naszych najważniejszych obserwacji, które dostrzegamy w tej aktualizacji Scruma, to jest fakt, że pojawia się nowy byt, czy nowy element Scruma. Po angielsku nazywany comitmens, po polsku zobowiązania. To jest taki jakby nowy byt. W tym sensie, że pojawia się nowe zobowiązanie, cel produktu, które jest powiązane z Backlogiem Produktu, ale oprócz tego konkretnie, jednoznacznie nazwane jest miejsce, czy rola, czy zauważone są już bardzo mocno zdefiniowany sens i przyczyna istnienia celu Sprintu oraz już bez żadnych ogródek i bardzo też konkretnie zaznaczone Definition of Done. Każdy z tych zobowiązań jest spięty z konkretnym artefaktem scrumowym. Czyli tak, jak już mówiłem, cel produktu jest związany z Backlogiem Produktu. Cel Sprintu z Backlogiem Sprintu, jest jego nieodłącznym elementem i Definicja Ukończenia charakteryzuje, czy tutaj jakby ściśle definiuje, czym jest Przyrost?

Jacek: No i tutaj na dzisiaj, tak jak ja to rozumiem, tak jak rozmawialiśmy z Kubą, to jednak należałoby rozróżnić ten commitment, tak jak został wspomniany na webinarze, jako taką bardziej wolę i ukierunkowanie. W tym przypadku rozumiemy jednak te commitmenty jako coś takiego, co bardziej wskazuje, że to musi się pojawić. No znów, sensowne wskazanie, co do zasady, no bo wszystkie te trzy rzeczy, które wymieniłeś, mają sens. No też coraz mniejsza furtka się robi na to, żeby sobie z pewnych rzeczy tam rezygnować. Znam masę zespołów, które z różnych powodów nie definiują sobie Celu Sprintu. Niektóre zespoły po prostu tego nie robią, a mogłyby to robić. Inne zespoły są tak skonstruowane, że taki Cel Sprintu, no po prostu tak w ich realiach jest trudny do określenia, no bo ten zespół to tak naprawdę cztery podgrupki dwuosobowe. Każdy robi coś innego i nie ma żadnego sensownego Celu Sprintu na poziomie biznesowym, który by powodował, że Ci ludzie będą pracować razem nad czymś. Tak więc fajnie, że to zostało wzmocnione, no bo to też pokazuje trochę, jak powinny być konstruowane Zespoły Scrumowe, w jaki sposób. Czyli już nie tak, że to po prostu zespół pracuje Scrumem i robi sobie, co tam wpada do Backlogu, no tylko jednak o wiele silniejsze jest tutaj mowa o jakimś konkretnym produkcie. No co zamyka trochę furtkę na robienie wszystkiego i niczego, jeżeli chcemy używać Scruma, tego w wersji 2020. No co też z mojej perspektywy jest pewnego rodzaju nawiązaniem do wartości – skupienie. Czyli po prostu maksymalnie skupiamy się na tym, żeby robić jakiś jeden konkretny cel biznesowy. No i jakby po to zostaliśmy powołani. No jeżeli mamy dostarczać te obiecywane dwa razy więcej, dwa razy szybciej, to po prostu pewne określone wymagania, no muszą zostać spełnione.

Kuba: Przechodząc już powoli do końca trochę listy naszych obserwacji, mamy w zasadzie trzy takie punkty, które jednak ocenimy jako może punkty, które mogłyby być zmienione trochę bardziej odważnie, albo może są niejednoznaczne. Pierwszy punkt jest tutaj związany z nazwą zmienioną na Development Teamu na Developers. Tutaj Jacek komentarz Twój do tej sytuacji.

Jacek: Tak, ja bardzo często się spotykam w szczególności, jak pracuję z zespołami, z organizacjami, które nie są organizacjami IT, z takim niezrozumieniem. Albo słyszę, że no przecież ten cały Scrum to jest dla programistów, tak? To dla IT? I tutaj jest jakby pierwsza cała historia, taka powiedzmy do wyprostowania. No, a druga sprawa jest taka, że no nadal to skojarzenie Developer, no to jednak skojarzenie, z którym się spotykam, to jest programista. Drugie skojarzenie, z którym się spotykam ktoś, kto buduje, stawia nieruchomości. Tak więc, tyle o ile podoba mi się rezygnacja z całej nazwy Zespół Developerski i powiedzenie sobie tylko, że są Developerzy, jest bardzo fajne. Jakby już na poziomie nazewnictwa usuwa nam jakiś tam podzespół w Zespole Scrumowym. O tyle myślę sobie, że można byłoby przy okazji tej aktualizacji zastanowić się nad tym, czy nie istnieje lepsze sformułowanie? Takie bardziej odcinające nas od IT, no bo cała część zmian, które są w najnowszej wersji, też trochę można powiedzieć, obdziera tego Scruma z resztek śladów tego, że pewne korzenie swoje, pierwsze eksperymenty działy się w Zespołach Software’owych. Oczywiście jest to pewnego rodzaju detal. Natomiast przy tak dużej skali zmian, w porównaniu do poprzedniej aktualizacji, no to to jest coś, co z mojej perspektywy można było dopracować.

Kuba: Kolejną kwestią, która wzbudza jakąś wątpliwość, albo może jest nadal jeszcze kwestią tego, że ja czegoś nie rozumiem? Tak, jak bardzo mocno zgadzam się z koncepcją wprowadzenia Celu Produktu, tak jedne pewne zapisy w okolicy Backlogu Produktu i właśnie pokazania tej intencji stosowania Celu Produktu, są moim zdaniem bardzo konkretnie, ambitnie, preskryptywne. Jednak jest tu wspomnienie o tym, że cel produktu zbiera wszystko to, co jest do zrobienia w Backlogu Produktu. No i Backlog Produktu trochę traci ten charakter takiego wcześniej rozumianego jakby miejsca, w którym zebrane są pomysły na zmiany, ale te pomysły mogłyby być dosyć różne. Teraz nie ma miejsca na różne pomysły. Jest tylko akceptowanie pomysłów, które są zbieżne, zgodne z celem produktu. Bardzo mocno laserowo ustawiają zespół. Waszym celem jest robienie tego, więc tylko te rzeczy mogą być w Backlogu Produktu. I dlaczego, z jednej strony jest to dobry pomysł i teraz jest miejsce na to, żebyś Jacek zaraz to skomentował. Natomiast ja sam mam z tym problem taki pragmatyczny, że w wielu organizacjach jest mimo wszystko, z jakiegoś powodu, potrzeba tego, żeby istniały takie narzędzia jak Road Mapa Produktu, jak jakieś plany rozwojowe, jakieś może miejsce na to, żeby również zarządzać oczekiwaniami interesariuszy. Wcześniejsze wersje Scruma trochę o tym wspominały. Teraz Product Backlog może zostać zebrany, mimo wszystko do takie listy rzeczy, które są – tylko te będą do zrobienia, a pozostałe trochę nie wiadomo. Ja się bardzo boję, że zacznie się robić praktyka takiego jakiegoś dodatkowego Product Backlogu, albo starego Product Backlogu, albo jakaś inwentaryzacja pomysłów. Jakkolwiek sobie to nazwiemy. I tak naprawdę z bardzo sensownego kierunku może się zacząć robić takie rozwadnianie, że jest Product Backlog oraz ta dodatkowa lista, która nie jest częścią Scruma, ale i tak musimy ją prowadzić, bo na przykład grupa Product Ownerów chce się zsynchronizować w dłuższym horyzoncie czasowym. Albo niestety korporacja oczekuje tego, że te plany będą trochę na większym horyzoncie, czy na większej odległości, niż tylko ten jeden Product Goal, który jest na początku tuż przed nami.

Jacek: Ja sobie myślę tak, że znów, żeby te obietnice twórców Scruma mogły być efektywnie, to z jednej strony czuję to. Na zasadzie tylko te rzeczy, które nas przybliżają do jakiegoś konkretnego celu. Natomiast no trochę tak empatycznie patrzę na te wszystkie zespoły no, które mają więcej problemów, niż tylko to, że coś jest spoza Celu Produktu Backlogu. No i to może być takie kolejne ograniczenie, kolejny punkt, który może rodzić dyskusje. Scrum nie jest dla nas. Scrum u nas nie zadziała i tak dalej. Co jest pewnym ryzykiem. No i tu znów. To są takie te aspekty, które no są takie, można powiedzieć, rozpatrywane na poziomie detali i można to pominąć na takiej zasadzie, ktoś może to pominąć, nie zwrócić na to uwagi, ale znajdzie się na pewno ktoś, kto bardzo literalnie będzie do tego podchodził.

Kuba: I robił sobie wyrzuty, albo komuś wyrzuty.

Jacek: Dokładnie. No bo tak jak mówię. Jakby co do zasady rozumiem jaka myśl za tym stoi, jednocześnie widząc przeszkody implementacyjne na drodze. Bo zaraz może się okazać, że bardzo niewielki procent zespołu w ogóle jest w stanie pracować w ten sposób. Co z mojej perspektywy nie jest dobrym kierunkiem. Na takiej zasadzie, bo jeżeli Scrum ma stać się jakiś super elitarny poprzez to, że stał się taki dosyć wymagający, albo jeszcze bardziej wymagający, no to ile tych teamów będzie to w stanie realizować? No to jest jakby ciekawe i na pewno z wielką ciekawością będę obserwował, jak te zmiany, w jakim tempie i z jaką skutecznością będą propagować na przeciętnego Kowalskiego w przeciętnej polskiej firmie.

Kuba: Natomiast ja tu rozładuję swoje własne napięcie. Jest może też tak, że ja coś źle zrozumiałem. Może ten Product Goal i ta zależność między Product Goal, a Product Backlog jest jednak nie aż tak agresywna, jak ja to interpretuję na pierwsze, drugie i trzecie czytanie. I może pojawi się interpretacja, która będzie trochę bardziej swobodna. Na przykład kilka Product Goal, jako taki pokaz, no właśnie road mapa. Dzisiaj naszym Product Goal’em jest to, a jak to zrealizujemy, będzie na horyzoncie jakiś kolejny i to w sumie będzie w porządku.

Jacek: Dobrze. Ostatnia taka rzecz, która też może zostać odebrana dwuznacznie, to jest fragment, który mówi o tym, że Developerzy, którzy będą wykonywać pracę są odpowiedzialni za określenie wielkości elementów Product Backlogu. No i znów tutaj, co do zasady no to ja tak patrząc pozytywnie na to, to bym powiedział OK. Ci, którzy będą wykonywać pracę, w domyśle Developrzy wszyscy, którzy są w Zespole Scrumowym, no to po prostu odpowiadają. Oni w sumie, to to są te osoby, które będą określać wielkość elementów. No, ale Kuba patrzy na to z innej strony i pewne ryzyko się pojawia. Jakie tu widzisz zagrożenie Kuba w tym zdaniu?

Kuba: Ja muszę w takim razie chyba podziękować mojej doktor logiki z Uniwersytetu Adama Mickiewicza, ale jednak to zdanie w żaden sposób nie zabrania mi tego zinterpretować również w taki sposób, który do tej pory raczej w Scrumie był antywzorcem. Może nawet nie tyle w Scrumie, co powiedzmy w praktykach związanych z wycenami, albo oceną wielkości zadań. No bo w sumie to zdanie identycznie mogę też zinterpretować. Ci Developerzy, którzy faktycznie będą wykonywać osobiście tę pracę, są odpowiedzialni za określenie wielkości elementów Backlogu Produktu, co może być niestety interpretowane, i już nawet nie mówię o tym, czy Scrum, Scrum Guide, Scrum.org, czy jakieś oficjalne instytucje, tylko mówię o zwykłych szarych ludziach, którzy poznają Scruma poprzez przeczytanie tego kawałka, czy tego zdania. Mogą to zrozumieć, OK, czyli musimy wiedzieć, kto to będzie robić. Ta osoba musi powiedzieć, ile mu to zajmie. Poda wycenę. Prawdopodobnie w tym kontekście to będzie wycena w godzinach lub dniach. Później będzie sobie tę pracę wykonywać. Zwróćmy uwagę, że tutaj zwłaszcza w tym zamyśle, że każde zdanie tu ma sens, jest z jakiegoś powodu zawarte. No to co najmniej ja to nazwę tak. Jest tu stracona okazja do tego, żeby może ująć to zdanie tak, żeby nie mogło być interpretowane w żaden inny sposób, no bo tutaj, chociażby kolejność w szyku słów, czy jakiś może przymiotnik, który dopowiada, o co chodzi. A może jest tak i to może jest zgodne z intencją, tego się może na razie nie dowiemy, póki któryś z twórców Scruma tego nie dopowie. Że może właśnie o tym, że oczekujemy, że cały zespół ocenia wielkość, właśnie znika. Może to mogłoby mieć sens. Zwłaszcza w projektach, czy takich zespołach bardziej biznesowych. Ocena wielkości zadania marketingowego prawdopodobnie jest do zrobienia wyłącznie przez marketingowca w zespole, a pozostali specjaliści, czy eksperci nawet w zasadzie nie ma ich, o co pytań, ani nie ma w zasadzie, o czym gadać. Natomiast dookreślenie tego zdania jest jedną z tych rzeczy, która przykuła moją uwagę. Może to jest szczegół zupełnie nieistotny porównaniu do skali wszystkich pozostałych zmian. Natomiast ja konsekwentnie oczekiwałbym, że taki dokument, jak Przewodnik po Scrumie, jest naprawdę idealny pod kątem tego, że może być interpretowany zgodnie z intencjami. W wielu, wielu miejscach ta intencja, dobrane przykłady, jednoznaczność pewnych sformułowań, ich wyrazistość, ma miejsce i jest godna polecenia.

Jacek: Zdecydowanie dajemy sobie z Kubą furtkę na to, żeby mieć po prostu swoją jakąś interpretację. Minęło raptem parę godzin od oficjalnej publikacji. Nie mieliśmy dostępu do tych zmian wcześniej. Tak więc patrząc na to, że zmiany ostatniej aktualizacji są dyskutowane do dzisiaj na różnych forach i ludzie potrafią się bardzo mocno ze sobą nie zgadzać, jakby jesteśmy spokojni, że na pewno trochę czasu upłynie i pojawią się głosy, myślę z okolic twórców Scruma, które pewne rzeczy, czy w jakichś blog postach, czy jakichś wpisach na forum po prostu będą doprecyzowywać, czy wyjaśniać.

Kuba: Przejdźmy teraz tak trochę na koniec odcinka do takich punktów, które w sumie sobie nazwaliśmy, może na wyrost wątpliwościami. Może to są bardziej takie punkty do przemyślenia. One już może nie są bezpośrednio związane z tym, co dokładnie w tym nowym Przewodniku po Scrumie jest zawarte, a bardziej z takim meta poziomem, że Scrum ewoluuje. Co samo w sobie jest świetną sprawą. To naprawdę już co najmniej z raz o tym wspomnieliśmy, że to jest dobry kierunek. Natomiast jest kilka punktów, które chcemy my głośno nazwać, czy tak głośno skomentować. Liczymy na to, że również Tobie dadzą do myślenia, czy dadzą okazję do refleksji.

Jacek: Pierwszy punkt, to jest punkt, który dotyczy tych wszystkich treści scrumowych, około scrumowych, które już zostały wyprodukowane. One w pewnym stopniu się dzisiaj o szesnastej czasu polskiego zdezaktualizowały. To są i posty na blogach i odcinki podcastów i książki, gdzie wszyscy, którzy te treści tworzyli, no jednak mieli jakiś tam, powiedzmy punkt odniesienia. Jeżeli chcieli być zgodni z oficjalnym Przewodnikiem po Scrumie, no to używali pewnych, konkretnych określeń tak, żeby być, przynajmniej ja tak do tego podchodzę, tak bardzo jednoznaczni, wyraźni i konsekwentni. No i teraz się okazuje, że jeżeli ktoś pisał o Zespole Developerskim, no to już tego Zespołu Developerskiego nie ma. Sam tutaj głośno nazywam tę wątpliwość, bo sam takich materiałów masę wytworzyłem. Czy teraz wracać do nich i robić aktualizacje? Czy je w jakiś sposób oznaczyć, że mogą być nieaktualne? Czy wytworzyć nowe? W przypadku książki mam jeszcze większe dylematy. No bo ta zmiana, to nie jest jakaś kosmetyka, tylko no taka poważniejsza zmiana. Tak więc no na pewno trochę tak trochę wchodzę tutaj w buty osób, które wchodzą do świata zwinnego, natrafiają na te starsze artykuły, no i jakby zaczynają swoją przygodę, jakby ucząc się rzeczy, które już uznajemy, powiedzmy za nie tak doskonałe, jak ta nowa definicja. No i jest to jakiś na pewno problem. Sam jestem ciekawy, jak nazwijmy to szeroko, branża zareaguje na tę zmianę.

Kuba: Na pewno nie jest naszą intencją stękanie, jakieś takie wstecznictwo, że nie zmieniajmy Scruma, bo jakiś tam odcinek podcastu nam się zdezaktualizował. Zwłaszcza jeśli jesteś Słuchaczu twórcą jakichś treści, może zreflektuj na ten temat. Myślę, że mimo wszystko, jest jakaś odpowiedzialność twórcy i co najmniej ten update typu, ta treść bazowała na wersji Scrum Guide’a, która już jest nieaktualna, bądź uważanie na to może pomóc tym mniej obeznanym, czy początkującym, czy właśnie mniej czułym, że właśnie ten Scrum Guide ewoluuje. Druga rzecz, którą dopowiem. Oczywiście zauważyliśmy, że Scrum Guide ewoluuje nie po raz pierwszy. Natomiast jak sięgnę pamięcią do zmiany w siedemnastym, czy kilku wcześniejszych, no to one jednak miały o wiele mocniejszy charakter takiej spokojnej ewolucji. To było tu dopisanie. Tam coś doszczegółowienie. Tu zmiana jednego słowa. Pod tym względem ten update jednak o wiele bardziej ma charakter takiego Big Bang’u, a nie małej iteracji i tu z tych drobnych dopisków, albo drobnych przeformułowań jest sporo, a może nawet jeszcze trudniej zauważyć te zdania, czy te przymiotniki, które w dosyć niepostrzeżony sposób zniknęły. Bo to nagle oznacza, że przestały stanowić ten kanon scrumowy. My sami jeszcze z Jackiem nie wiemy. Rozmawialiśmy z chwilę przed odcinkiem, czy coś tu zadeklarujemy. Z jednej strony mamy poczucie, że ten taki pragmatyzm tych odcinków, które były o Scrumie zaznaczał w paru miejscach, że widzimy te różne rzeczy, które w sumie są zgodne z wersją z dwudziestego roku, no ale nie wykluczamy, że jakieś miejsca w starych odcinkach nam się właśnie dzisiejszego dnia zdezaktualizowały i być może albo wylecą z listy odcinków, albo nagramy je na nowo według nowego ducha, też w poczuciu tej odpowiedzialności.

Jacek: Kolejna nasza wątpliwość, czy może otwarte pytanie brzmi, jak organizacje mówiąc tak trochę przekornie, zainstalują sobie ten update? Jak to będzie wyglądać? Jaki będzie czas propagacji? Trochę tak, jak mamy Androida i różne wersje systemu. No bardzo podobnie może to wyglądać w organizacjach. Czy w ogóle zostanie to zauważone? Jeśli tak, to w jakim stopniu? Jak bardzo to wpłynie też na faktyczne rezultaty? No to jest, jakby myślę sporo pytań, na które powiem za siebie, dzisiaj nie mam odpowiedzi. Myślę, że najbliższe dni, tygodnie, miesiące, ale też pewnie lata, będą pokazywać, na ile ta zmiana jest wyraźna i na ile ona nadaje nowy tor, a na ile dla osób, które są mniej związane z podejściem zwinnym, będzie to coś, nazwijmy to kosmetycznego, co po prostu gdzieś tam przeleci, jako jakaś tam informacja na LinkedInie i nie będzie to miało żadnych skutków w faktycznym funkcjonowaniu.

Kuba: Kolejna kwestia, teraz już naprawdę bardzo ironiczna. Współczujemy wszystkim tym, którzy Scruma znali na pamięć. No bo tutaj w zasadzie trzeba na nowo nauczyć się go na pamięć. No i trochę żartuję, trochę współczuję. Bardzo podobny klimat, pamiętajmy o tym, że slajdy trzeba zmienić w szkoleniach. Być może stare, gotowe odpowiedzi na egzaminy już teraz nie będą dobrymi odpowiedziami. Będzie sporo zamieszania u osób, które znają Scruma na pamięć, albo inaczej mówiąc, znają go z teorii i trzeba go będzie teraz zaaplikować po nowemu i być może pogubią się niektóre uzasadnienia, albo wyjaśnienia tego, jak to funkcjonuje.

Jacek: Na szczęście żadnych podchwytliwych zmian nie ma. Na przykład Project Manager nie pojawił się jako rola, nie odpowiedzialność, więc może nie będzie tak źle. Natomiast też na pewno nie chcemy, żebyś odebrał, czy odebrała te wątpliwości, jako jakieś takie właśnie marudzenie, czy szukanie dziury w całym. Raczej takie spojrzenie na konsekwencje, które po prostu wystąpią. Natomiast absolutnie nie negujemy samej zmiany. No wręcz myślę, że mogę też ca Ciebie Kuba powiedzieć, że co do zasady ją wspieramy i też taka była intencja naszego odcinka, żeby o tym opowiedzieć, wskazując oczywiście plusy i minusy z naszej perspektywy. Natomiast chcielibyśmy zachęcić Cię do przede wszystkim sprawdzenia najnowszej aktualizacji Przewodnika po Scrumie. Dostępna jest wersja polska, dostępne są wersje w innych językach, jeżeli preferujesz inne języki. Na pewno warto przeczytać. Pewnie nie raz zastanowić się, przemyśleć, jakie te zmiany są. Jaki mają one impakt na Twój zespół, na Twoją organizację. No bo zdecydowanie te zmiany są czymś, obok czego no byłoby szkodą przejść obojętnie.

Kuba: W ramach tego odcinka wymieniliśmy raptem tylko pewien wycinek takich zauważalnych zmian. Jest ich o wiele więcej. Jak już przeczytasz ten Przewodnik po Scrumie, albo już to zrobiłeś lub zrobiłaś wcześniej, to koniecznie podziel się w komentarzu. Być może dla wszystkich słuchaczy ten odcinek może być jakąś taką formą inwentaryzacji i drobnej dyskusji na temat zmian, które nam się podobają. Zmian, które rozumiemy, ale również zmian, które gdzieś tam wzbudzają w nas wątpliwości, czy zadają nam dodatkowe pytania. Notatki do tego odcinka, to miejsce, gdzie też sugerujemy, żeby zawrzeć te komentarze, o których chwilę temu wspomniałem, transkrypcję naszej wypowiedzi, zapis wideo, który również się pojawi, znajdziesz na stronie porzadnyagile.pl/51

Jacek: Tymczasem to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.