Kolejna aktualizacja Scrum Guide, to – wiadomo – gorący temat w środowiskach praktyków, teoretyków i sympatyków zwinności. Sam muszę przyznać, że czytałem dokument z wielkim zaciekawieniem, momentami prawie zdumieniem. Poniżej wskazuję kilka fragmentów, które szczególnie zwróciły moją uwagę, a pod każdym z nich dzielę się swoimi wrażeniami na gorąco oraz, jeśli już takie mam, interpretacjami. Pewnie będę te interpretacje z każdym kolejnym tygodniem modyfikował, dlatego mam nadzieję, że dziś posłużą bardziej jako pretekst do dyskusji, ewentualnie zaczyn delikatnego intelektualnego fermentu, a tego przecież nigdy dość.
Najprościej rzecz ujmując, Scrum wymaga, aby Scrum Master przyczyniał się do tworzenia środowiska, w którym:
1. Product Owner porządkuje pracę potrzebną do rozwiązania złożonego problemu, tworząc Product Backlog.
2. Scrum Team przekształca wybraną część tej pracy w wartościowy Increment w trakcie Sprintu.
3. Scrum Team oraz jego interesariusze sprawdzają efekty i dostosowują swoje działania na potrzeby kolejnego Sprintu.
4. Powtórz.
Moim zdaniem – kolosalna zmiana. I kolosalne wyzwanie dla Scrum Masterów. Owszem, w poprzednich wersjach była mowa o zobowiązaniach Scrum Mastera nie tylko wobec Product Ownera oraz Zespołu Developerskiego, ale również całej organizacji, a jednak można było odnieść wrażenie, że to „ten łebek od procesu”. Tymczasem wersja z roku bieżącego w samej definicji Scruma, już na trzeciej stronie, tuż po Celu Przewodnika i spisie treści, wali po gębie wymaganiem stawianym Scrum Masterowi. Według mnie ma to sens nawet na poziomie semantycznym: otóż tylko w nazwie tej odpowiedzialności pojawia się sam Scrum. Jak dla mnie, to wyrażone wprost, bez certolenia się półsłówkami, zaakcentowanie szczególnego znaczenia zadań Scrum Mastera. I przy okazji cieszę się, że znikł obrzydliwy, jak dla mnie, zapis z wersji poprzedniej: Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty gotowej do potencjalnego wydania funkcjonalności. Obrzydliwy, bo właśnie to nawet było półgębkiem i dookoła.
Scrum jest prosty. Wypróbuj go w takiej postaci, w jakiej został tu opisany i sprawdź, czy jego filozofia, teoria oraz struktura pomogą ci w osiągnięciu celów i tworzeniu wartości.
Filozofia? Litości… W najlepszym wypadku kogoś tu poniosło, w najgorszym – brzydko odbiła się komuś potrawa znana jako megalomania. Stoicyzm to jest filozofia, a nie Scrum. Oczywiście można uznać, że mowa w tym ustępie o zestawie zasad, idei i celów leżących u podstaw powstania i/lub funkcjonowania Scruma, ale nawet jeśli tak, to uważam zabieg za ryzykowny. Zdecydowane sekowanie wszelkich związków Scruma z chociażby podejrzeniami o sekciarstwo uważam za godne pochwały. Ta filozofia to według mnie krok wstecz. Krokiem naprzód jest natomiast usunięcie z polskiego tłumaczenia wzmianek o nieszczęsnym coachingu. Dlaczego nieszczęsnym? Wyjaśniałem tutaj.
Fundamentem Scruma jest empiryzm i koncepcja lean.
Świetnie! Nareszcie lean przyznaje się do ojcostwa. A właściwie Scrum akceptuje ojca. No, jednego z ojców: lean. Interesująco pisał na ten temat Gunther Verheyen w swojej książce Scrum – A Pocket Guide: A Smart Travel Companion. Przytaczam moje tłumaczenie jednego z fragmentów: W swoim artykule (chodzi oczywiście o „The New New Product Development Game” – przyp. MK) Takeuchi i Nonaka opisują żywą tkankę Lean i nazywają ją „Scrumem” jako wyróżnik w zakresie rozwoju złożonych produktów. Ich punkt widzenia zakłada, że jest mało prawdopodobne, by organizacja czerpała korzyści z tak zwanych praktyk „Lean” zastosowanych do rozwoju złożonych produktów, jeśli owa żywa tkanka – Scrum – nie manifestuje się, a dają o sobie znać wyłącznie towarzyszące jej praktyki. Jako że dzieje się tak w wielu przypadkach wprowadzania Lean, autorzy podkreślają wagę rozwoju duszy i serca systemu i odstąpienia od towarzyszących praktyk zarządzania.
Scrum polega na pracy grup osób wspólnie posiadających wszystkie umiejętności oraz specjalistyczną wiedzę potrzebne do wykonania pracy oraz dzielą się tymi umiejętnościami bądź nabywają je w miarę potrzeby.
Grup osób? Czyżby sugestia, że zespół, który składa się z około dziesięciu osób, coraz rzadziej bywał samowystarczalny? Czyżby wskazanie, że wobec złożoności większości wytwarzanych produktów skalowanie coraz częściej staje się koniecznością? Jeżeli tak, to trochę żałuję, że nie napisano tego bardziej wprost i dosadnie. A jeżeli nie, to jestem ciekaw, jak Wy, szanowni czytelnicy, interpretujecie ten fragment.
Adaptacja staje się trudniejsza, kiedy osoby w nią zaangażowane nie mają odpowiednich uprawnień lub zdolności samozarządzania.
Kolejne potwierdzenie, jak ważne dla wprowadzania Scruma są zarówno kompetencje, jak i błogosławieństwo oraz ciągłe wsparcie najwyższych kadr zarządczych. Myślę, że prezesowie wielu organizacji, którzy zdecydowali się na tak zwane zwinne transformacje, powinni tatuować sobie to zdanie na torsach. Ci mniej lotni – na czołach.
Podstawowym elementem Scruma jest niewielki zespół, czyli Scrum Team. W skład Scrum Teamu wchodzi jeden Scrum Master, jeden Product Owner oraz Developerzy. Scrum Team nie dzieli się na podzespoły, nie obowiązuje w nim hierarchia. To spójna grupa profesjonalistów skupionych na pojedynczym celu określanym jako Cel Produktu.
Moim zdaniem bardzo ciekawa ewolucja koncepcji interdyscyplinarności. Zwłaszcza że w ustępie poświęconym Daily Scrumowi pada również następujące sformułowanie: Jeśli Product Owner lub Scrum Master wykonują pracę związaną z elementami Sprint Backlogu, uczestniczą w spotkaniu jako Developerzy. Wygląda to na logiczną konsekwencję wyciągniętą z jednej z wartości Scruma – zaangażowania – jak i długo poszukiwaną przez niektórych odpowiedź na pytanie: czym właściwie zajmuje się taki Scrum Master?
Są także zespołami samozarządzającymi, co oznacza, że samodzielnie podejmują decyzję o tym, kto będzie wykonywał określone zadania, kiedy i jak.
Wcześniej mowa była o samoorganizacji, aktualnie – o samozarządzaniu. Wcześniej było tak: Samoorganizujące się zespoły samodzielnie decydują, w jaki sposób najlepiej wykonywać pracę, nie będąc przy tym kierowanymi przez osoby spoza zespołu. Oraz tak: Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty gotowej do potencjalnego wydania funkcjonalności. Różnica jest z pozoru niewielka, ale spójna z koncepcją Scrum Teamu, który decyduje nie tylko o sposobach wykonywania pracy, ale i o tym, nad czym pracować.
Scrum Team jest wystarczająco niewielki, aby pozostawać zwinnym, a jednocześnie wystarczająco liczny, aby móc ukończyć znaczącą część pracy w Sprincie, zwykle składa się z 10 osób lub mniej.
Zwykle, ale nie zawsze. Podoba mi się to, że zespołom, których liczebność nieznacznie przekracza rekomendację nadgorliwcy nie będą mogli już odmawiać prawa do tytułowania się Scrum Teamem.
(…) wzajemne egzekwowanie odpowiedzialności zawodowej.
To wyżej to wprost wyartykułowana odpowiedzialność developerów. Brawo! Precz z dziadostwem! Skoro samozarządzanie, to i konieczność egzekwowania odpowiedzialności zawodowej – coś za coś. Żadna Definicja Ukończenia nie wymusi, moim zdaniem, jakości tak skutecznie, jak ziomal z zespołu, który kopnie cię w kostkę, jeśli dajesz ciała.
Scrum Masterzy to prawdziwi liderzy działający na rzecz Scrum Teamu, jak i szerzej rozumianej organizacji.
Wcześniej była mowa o liderze służebnym. Oczywiście „prawdziwy lider” z wersji aktualnej jest określeniem równie nieprecyzyjnym, bo wieloznacznym i podatnym na interpretacje, ale to kolejny fragment, który wskazuje na kluczową rolę Scrum Mastera właśnie… Generalnie mam wrażenie, że nowa wersja Scrum Guide zdejmuje ze Scrum Mastera odium fircyka od tak zwanych „zagadnień miękkich”. Świetnie, że nie ma na przykład mowy o tym, jakoby musiał zapewniać, że retrospektywa przebiega w pozytywnej atmosferze. Czyli co, kawę miał parzyć?
Daily Scrum to 15‐minutowe wydarzenie dla Developerów danego Scrum Teamu. Aby ograniczyć złożoność, odbywa się ono o tej samej porze i w tym samym miejscu w każdy dzień roboczy w trakcie trwania Sprintu.
Jak dobrze, że nie ma już wzmianki o tych trzech drętwych pytaniach. Tak, wiem, że były one tylko przykładem/propozycją, ale szły w poprzek idei samoorganizacji, o samozarządzaniu nie wspominając.
Cel Produktu opisuje przyszły stan produktu, który może posłużyć Scrum Teamowi jako punkt odniesienia w procesie planowania. Cel Produktu jest odzwierciedlony w Product Backlogu. Pozostała część Product Backlogu ewoluuje, aby określić „co” przyczyni się do osiągnięcia Celu Produktu. Cel Produktu to długoterminowe zamierzenie Scrum Teamu. Zespół musi zrealizować jeden cel (lub z niego zrezygnować), zanim przystąpi do realizacji kolejnego.
Spotkałem się z interpretacją, wedle której Cel Produktu to taka właściwie wizja tegoż. Pewnie można i tak, choć dla mnie to coś bardziej od wizji namacalnego – to taki kręgosłup/spoiwo backlogu, tak jak spoiwem i drogowskazem sprintu jest Cel Sprintu. Bardzo ciekawa wydaje mi się koncepcja wprowadzenia kolejnego Celu Produktu po zrealizowaniu poprzedniego. Wydaje mi się to niezłym narzędziem weryfikacji sensowności dalszego rozwoju produktu. Papierkiem lakmusowym dla jego dalszych losów. Nijak nie przychodzi do głowy kolejny Cel? To może przed nami już tylko przyszłość w trybie utrzymaniowym?
Increment to konkretny krok w kierunku osiągnięcia Celu Produktu. Każdy kolejny Increment rozbudowuje wszystkie wcześniejsze, jest też skrupulatnie weryfikowany po to, aby zapewnić, że wszystkie Incrementy są do siebie dopasowane. Aby dostarczyć wartość, Increment musi być użyteczny.
Kolejny bardzo ciekawy zwrot akcji. Jest mowa o użyteczności, ale nigdzie nie pada już w dokumencie wzmianka o potencjalnej wydawalności. Oczywiście może być to pokłosiem ambicji do uniwersalizacji Scruma i potencjału wykorzystywania go poza branżą rozwoju oprogramowania, ale może jest też cichą aprobatą dla myślenia, w którym wartość zaklęta jest nie tylko w gotowym produkcie. Czyżby sam backend również był wartościowy?;))
Ogólne wrażenia? Cieszę się, że dokument się skrócił, co dobrze świadczy o zastosowaniu praktyk lean. Jeszcze bardziej się cieszę, że Schwaber i Sutherland zdają się porzucać ścieżki rygoryzmu. Swego czasu funkcjonowała taka narracja – chyba zresztą przez nich wspierana – że jeśli ignorujesz któryś z elementów Scruma, nie masz prawa utrzymywać, że się nim posługujesz. Nowa wersja pozostawia większe pole manewru, co niejako oddaje po latach sprawiedliwość tym, którzy opisane w tym roku modyfikacje praktykowali już wcześniej, skazując się na ostracyzm ortodoksów. Fajnie, że Ken i Jeff na stare lata wyluzowali.