Poprzednie części przedstawiające mity Scruma:

Witam ponownie w trzeciej części mojego cyklu artykułów, w których to rozprawiam się z mitami Scruma. Jeśli nie czytałeś poprzedniego epizodu, to w każdym materiale rozprawiam się z czterema mitami, a więc rozchodzącymi się środowisku IT “prawdami” na temat frameworka, które raz są faktycznie prawdą, natomiast częściej zupełnie wyssanymi z palca fantasmagoriami. Zanim zabierzesz się za lekturę, polecam spróbować zakwalifikować każdy z poniższych mitów jako FAŁSZ lub PRAWDĘ - w formie zabawy i sprawdzenia swojej wiedzy o Scrum.

PRAWDA! / FAŁSZ! - W Scrumie i Agile rezygnujemy z dokumentacji
PRAWDA! / FAŁSZ! - Możliwe jest budowanie backlogu produktu bez user story
PRAWDA! / FAŁSZ! - W Scrumie nie ma miejsca dla ekspertów - jest jeden, „krosfunkcjonalny” zespół developerski
PRAWDA! / FAŁSZ! - Scrum się nie rozwija

W Scrumie i Agile rezygnujemy z dokumentacji

FAŁSZ! Mit nawet częściej używany w dyskusjach o Agile, aniżeli Scrumie, aczkolwiek spokojnie się nadaje. Słyszany przeze mnie zarówno od developerów, jak i klientów. Obie grupy na wiadomość o tym, że „będziemy teraz pracować agileowo”, podskakują z radości - pierwsza grupa, ponieważ pisanie dokumentów to żaden fun i więcej będzie można spędzić czasu na programowaniu, a drudzy cieszą się, że developerzy będą spędzać więcej czasu z kodem, czyli z tym, co przynosi pieniądze. Umówmy się: dokumentacja to ból w czterech literach. Nawet jeśli się uda nam się ja sporządzić - co już jest sukcesem - to jej aktualizacja i utrzymywanie, to prawdziwe wyzwanie. Prawdopodobnie każdy z nas spojrzał niegdyś w dokumentację, aby po chwili sfrustrować się jej oderwaniem od stanu rzeczywistego produktu. Gorzej, gdy w sytuacji newralgicznej decyzji projektowej nie mamy żadnej dokumentacji, aby chociażby odpowiedzieć sobie na pytanie: „czym dokładnie zajmuje się ten moduł?”. Tak to już jest z dokumentacją, że jak bardzo trzeba ją cenić, ten tylko się dowie, kto ją stracił, nie prowadził czy nie aktualizował. Jednak z czego wynika przeświadczenie o jej braku w zwinnym dostarczaniu?

Otóż pierwszym winowajcom takowego stanu jest brak JAKIEJKOLWIEK wzmianki o dokumentacji w samym Scrum Guidzie. Aczkolwiek za spust w tej zbrodni pociąga manifest Agile, w którym przeczytać możemy: Working software over comprehensive documentation****, i tak się jakoś dziwnie składa, że często entuzjaści braku marnowania czasu na dokumentacje, pomijają w powyższym słówko comprehensive. Tak przypadkiem. A przecież nieco niżej w manifeście mamy dwie wskazówki, które mówią, że jest wartość w dokumentacji, oraz że zespół powinien w regularnych odstępach czasu analizować możliwości poprawy swojej wydajności, a następnie dostrajać i dostosowywać swoje działania do wyciągniętych wniosków. Szczególnie ta druga część, będąca jedną z dwunastu zasad zwinnego tworzenia oprogramowania, powinna być bliska zespołom scrumowym. Dokumentacja wspiera każdy z trzech filarów frameworka: buduje transparentność, a jej być albo nie być powinno być wynikiem inspekcji i adaptacji zespołu. Jak wiele, jak szczegółowa i jak sporządzana powinna być dokumentacja? Czymś, co na pewno byłoby bodźcem do włączenia dokumentacji do życia projektu, jest umieszczenie konieczności sporządzenia jej w Definition of Done. Zespół przy umieszczaniu wpisu o niej powinien również ustalić poziom szczegółowości, jaki uważa za sensowny. Tutaj też należy pamiętać, że dokumentacja może posiadać wiele form: od diagramów, sensownych nazw commitów do repo, po komentarze w kodzie czy samodzielnie generującą się doku w np. Swaggerze. Ostatnią radą, jaką mogę dać to YAGNI ("You aren’t gonna need it") dla podejmowania decyzji o konieczności i rodzaju dokumentacji. Zasada wywodząca się z XP, najlepiej opisuje współtwórca metodologii Ron Jeffries: „Zawsze wdrażaj rzeczy, kiedy ich naprawdę potrzebujesz, nigdy wtedy, gdy po prostu przewidujesz, że ich potrzebujesz”.

Możliwe jest budowanie backlogu produktu bez user story

PRAWDA! Wracamy do tematyki ściśle związanej ze Scrumem. Jednym z najzabawniejszych abominacji w samozwańczych zespołach scrumowych, jakie widziałem, były backlogi budowane wyłącznie z oklepanego formatu ‘As a…I want…so that…’, który jest oczywiście standardem tworzenia user story. Doprowadziło to do wypełnienia backlogu przeróżnymi karykaturami wymagań, w których to starano się absolutnie wszystko wpasować w format historyjek. Od nowych funkcji produktu, po aktualizację wtyczki w edytorze, kończąc na bugach. Aczkolwiek, aby być całkowicie szczerym: takie działanie, samo w sobie, nie jest zupełnym szaleństwem czy katastrofą dla projektu, aczkolwiek bardzo ważne jest, co doprowadziło nas do takowego działania. Jeśli zdrowy rozsądek i świadome działanie zespołu, który sam określa, co dla niego jest efektywne. Znacznie gorzej, aniżeli właśnie przeświadczenie, że wymagania pod postacią User Story są jednoznaczne ze stosowaniem Scruma, czy jakiegokolwiek procesu zwinnego. Doprowadza to do nie tylko do kuriozalnych sytuacji w backlogu, ale także jest frustrujące dla zespołu developerskiego, który nie może zapisać w backlogu ‘Aktualizacja Jenkinsa do wersji 4.12’, czy ‘Sprawdzenie kompatybilności nowej wersji Gatlinga z naszymi testami’, tylko musi rozpoczynać “litanie” od „Jako programista…” - nie mówiąc już o negatywnym postrzeganiu całego frameworka i innych jego elementów przez pryzmat tego absurdu.

Aby rozprawić się tym mitem, trzeba przypomnieć skąd wzięło się pojęcie User Story - spokojnie, będzie skrócona lekcja historii. Otóż historyjki wzięły się z Extreme Programming (jak wszystko, co dobre!), a osobami, którym przypisuje się największe zasługi ich rozpowszechnieniu, są m.in. Kent Beck i Jeff Patton. Jeśli wierzyć opowieścią panów, któregoś dnia mieli oni dość tworzenia oprogramowania z trzydziestostronicowych ksiąg wymagań, które dodatkowo nie rzadko kończyły się brakiem realizacji faktycznego celu. W końcu podszedł do osoby, która tworzyła dokumentację i poprosiła, by jej powiedziała, co chce uzyskać i jakie będzie miała tego korzyści. User Story to format do budowania wymagań, u którego epicentrum jest prostota, jednoznaczność zrozumienia dla każdej ze stron oraz motywowanie konwersacji o realizowanym zadaniu. Z czasem utarł się schemat ich budowania, aczkolwiek i on nie jest absolutem. User Story często łączone są jednoznacznie ze Scrumem, choć w Scrum Guide zwrot ‘user story’ występuje dokładnie 0 razy. Ba! Epic, Feature, Spike, Task czy Bug - żadnego z tych zwrotów nie znajdziecie w przewodniku po Scrumie. Zaskoczeni? Podziękujecie JIRZE. Scrum Guide natomiast mówi wyraźnie, że wszystkie elementy backlogu mają być jasne i zwięzłe, zrozumiałe dla każdego członka zespołu Scrumowego. Nie mniej, nie więcej.

W Scrumie nie ma miejsca dla ekspertów - jest jeden, „krosfunkcjonalny” zespół developerski

FAŁSZ! Już w trakcie formułowania nagłówka tego mitu, wiedziałem, że będę miał z nim najwięcej roboty, jeśli chodzi o udowodnienie niesłuszności postrzegania zespołu developerskiego, jako gromady „wszystko-ogarniających” osób. Zatem, aby przedstawić, dlaczego uważam tezę, że w Scrumie nie ma ról i miejsca dla ekspertów w danym obszarze, przytoczę rozmowę ze znajomym, w jednej z kuchni poprzedniego miejsca pracy. W trakcie rozmowy o tematyce, której dokładnie nie pamiętam padło stwierdzenie, że: „…z rozmowy z zespołem wyszło, że analityk biznesowy by się im przydał bardzo, ale pracują w Scrumie, a tam nie ma BA”. - choć nie uczestniczyłem w rozmowie wcześniej, obróciłem się na pięcie i powiedziałem: „Hola, hola! To nie tak!”. 

Faktycznie jest tak, że w Scrumie Guide nie ma mowy o rolach w zespole developerskim, ALE nie ma również wzmianki o tym, że są one zabronione. Dokładnie o Dev Teamach mówi w następujący sposób: „…są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu”, kontynuując podkreśleniem, że Scrum nie wyróżnia żadnych ról czy grup wewnątrz zespołu, aczkolwiek kończąc czymś bardzo istotnym: „Mimo iż pojedynczy członkowie Zespołu Deweloperskiego mogą posiadać wyspecjalizowane umiejętności i mogą skupiać się na konkretnych dziedzinach, odpowiedzialność za wykonywaną pracę ponosi cały Zespół Deweloperski”. Dorzućmy to tego, oklepaną już wzmiankę o tym, że to zespół jako samo organizująca się jednostka podejmuje decyzje o tym, jak będzie maksymalizował swoją efektywność, powinno być dla nas jasne, że jeśli stwierdza on, że potrzebuje w zespole umiejętności analityka biznesowego, to taka osoba powinna się w nim znaleźć - przy czym alternatywą byłoby zbudowanie tych zdolności u członków zespołu.

Popatrzcie na to, jak na drużynę piłkarską. Cel drużyny jest jasny: wygranie meczu. I choć drużyna składa się z bramkarza, obrońców, pomocników i napastników, to cel pozostaje bez zmian. Wiadomo również, że obrońcy są od bronienia dostępu do pola karnego (skrót myślowy), napastnicy za strzelanie bramek, a bramkarz do ich obrony. Ale czy nie zdarza się, że gdy mamy kilka minut do końca meczu to i bramkarz próbuje swoich sił przy stałych fragmentach, bo wymaga tego sytuacja. Czy przeszkadza to obrońcom włączyć się do ataku, stwarzając przewagę na połowie przeciwnika - przypomina mi się powiedzenie komentatorów z Canal+: „Jak idzie z nami obrońca, to gramy z nim do końca!”? Dobrze funkcjonująca drużyna, która rozumie, że sukces osiągnie wyłącznie jako kolektyw, który się wspiera i podejmuje decyzje korzystne dla drużyny, pomimo konieczności odejście w nich od swojej nominalnej roli.

Wspomniałem natomiast, że z tym mitem nie jest tak łatwo, albowiem w samym środowisku scrumowym jest sporo dyskusji na temat ról. Jedna strona konfliktu uważa, że to zupełnie nie przeszkadza, aby w zespole były jasne role, gdzie druga w zupełnym przeciwieństwie mówi o rolach jako przeszkodzie dla zespołu w osiągnięciu maksymalnej produktywności. Biorąc pod uwagę moje doświadczenie w pracy z zespołami, w których aspirowaliśmy do tworzenia prawdziwie scrumowych procesów i funkcjonowania zgodnie z wartościami frameworka, powiem tak: w zespole, w którym funkcjonują wartości otwartości, skupienia, wzajemnego szacunku, odwagi i zaangażowania, nigdy nie dostrzegłem problemów identyfikowania się członków teamu jako konkretna rola czy specjalizacja. Jednocześnie znacznie większą krzywdę pracy zespołowej i wspólnego dążenia do osiągnięcia celu, zaobserwowałem w momencie ortodoksyjnego narzucania braku ról. Uważam, że jeśli posiadanie ról w zespole jest dla niego problemem, to u fundamentu jego jest brak funkcjonowania ww. wartości w owym zespole i to tym powinniśmy się zająć. A zatem jakbym miał dać radę Scrum Masterom pracującym w zespołach dążących do bycia scrumowanymi, byłoby to: skupcie się na fundamentach, a role same przestaną mieć znaczenie. Skierujcie działania bezpośrednio na wartościach, a “krosfunkcjonalność” pojawi się sama.

Scrum się nie rozwija

FAŁSZ! Po dosyć ciężkim micie, materiał zakończę czymś lekkim, albowiem krążącym argumentem, że Scrum jest przestarzały. Spotkałem się kilka razy w swoim życiu z osobami, które zarzucały frameworkowi archaiczność, jakoby to „nienadające się do współczesnego świata IT, bo przecież Scrum to w latach dziewięćdziesiątych powstał” - czy coś w ten deseń. Jest to oczywiście nieprawdą, albowiem od momentu publikacji pierwszej wersji Scrum Guide’a w 2010 roku (a nie tam jakieś lata 90.), przeszedł on kilka naprawdę solidnych zmian. Ostatnią z nich, która miała miejsce miesiące temu, komentowaliśmy wspólnie z Bartkiem na łamach podcastu Dostarczaj Wartość, więc jeśli was to interesuje, to zachęcam do odsłuchania.

Pierwszą zmianę Scrum Guide przeszedł w 2011 roku, kiedy to Ken i Jeff odchudzili nieco zasady gry. Z wymaganych elementów Scruma zniknęły takie praktyki, jak wykresy Burndown/Burnup czy Release Planning, natomiast refinement (wtedy jeszcze nazywany groomingiem) awansował z roli zalecanej aktywności do integralnej części frameworka - co zresztą stało się normą kolejnych aktualizacji. W 2013 roku doszło do zmiany nazewnictwa „polerowania” elementów backlogu, czyli refinementu, który nazwą są zmienił po wcześniejszym groomingu. Zwrot ten okazał się być niezbyt korzystny, a zainteresowanych kieruje do słownika miejskiego. Poza tą zmianą aktualizacji doczekały się trzy pytania standupu, które to już w 2013 zostały ukierunkowane na cel sprintu i kontrybucje każdego z członków zespołu do jego osiągnięcia. Trzy lata później w Scrum Guide pojawiają się Wartości Scrum, choć nie był to ich debiut światowy, albowiem na początku XXI w. pojawiły się one w książce „Agile Software Development with Scrum”. W 2016 zostały dodane do Scrum Guide jako epicentrum funkcjonowania Zespołu Scrumowego. Rok później miała miejsce mniejsza aktualizacja, która rozbawiła mnie szczegółowym wytłumaczeniem, co oznacza ‘timebox’ jako cecha spotkań, ale także ucieszyła, dzięki wpisowi mówiącemu o tym, że retrospektywa powinna się kończyć (minimum) jednym „ulepszaczem” procesu jako część kolejnego sprintu.

Sami zatem widzicie, że Scrum Guide się nieustannie zmienia, dostosowuje i reaguje na otoczenie, ALE nie zmienia się sam Scrum, którego idee i cele pozostają nienaruszone. Odpowiadają za to bezpośrednio Jeff Sutherland i Ken Schawber, i choć w sieci ostatnio pojawiła się dyskusja, czy takie odgórne sterowanie frameworkiem jest najlepsze - z mojej strony uważam, że panowie robią świetną robotę, odpowiednio balansując mniejsze zmiany z większymi, pozwalając każdej na odpowiedni czas sprawdzenia. Jak znam framework, który reprezentują, wierzę, że stosują podobne zasady do jego rozwoju.

I to by było na tyle z serii o mitach i legendach, krążących w świecie IT o Scrumie. Dzięki za przeczytanie wszystkich (no ja myślę, że wszyscy czytali!) odsłon i mam szczerą nadzieję, że rozwiałem wątpliwości dotyczące Scruma, które w was siedziały. Tych, którzy sami powyższe mity brali za prawdę (lub fałsz) sprowadziłem na odpowiednie tory i przekonałem Was, że: „Scrum is simple, just use it as is!!” - Ken Schwaber