Kiedyś wszystko było proste – w Sprintach robiło się „potencjalnie wdrażalny przyrost oprogramowania”, który zawierał jakieś działające funkcjonalności. A dziś? Dziś wszystko się skomplikowało i już naprawdę nie wiem, co niektóre zespoły udają, że robią w Sprintach.
Stare dobre czasy
Muszę przyznać, że czasami tęsknię za czasami, kiedy w Scrumie pracowali zapaleńcy i osoby, które doskonale wiedziały, co chcą dzięki niemu osiągnąć. Nikt wtedy się nie zastanawiał po co nam Definition of Done, ani co powinno być efektem pracy w Sprincie. Z kolei Przyrost oprogramowania wyznaczały nowe, działające funkcjonalności.
Mam te wyjątkowe doświadczenia z projektu na którym kilkadziesiąt Zespołów Scrumowych (kilkaset osób) pracowało nad jednym produktem, który można było z grubsza podzielić na kilka systemów. Pamiętam bardzo dobrze, że co Sprint odnotowywaliśmy przyrost możliwości tych aplikacji. Sprint po Sprincie nasze rozwiązanie potrafiło robić coś więcej, lepiej wspierało biznes czy też mówiąc innymi słowami – dostarczało mityczną wartość.
Dlaczego pracowaliśmy wtedy w Scrumie? Ponieważ całość zagadnienia była zbyt skomplikowana, żeby dało się ją zaplanować z góry na kilka lat. Moglibyśmy oczywiście usiąść i wylistować tysiące bądź dziesiątki tysięcy funkcjonalności, które system powinien zawierać. Jednak dobrze wiedzieliśmy, że nie udałoby się nam opisać wszystkich „na sucho”. Po drugie, dopiero w trakcie pracy i na działającym systemie odkrywaliśmy lepsze rozwiązania. Te były planowane i powstawały w kolejnych iteracjach.
Co poszło nie tak?
Gdzieś po drodze Scrum stał się „domyślnym sposobem pracy”. Jest stosowany bezrefleksyjnie i bez znajomości jego prawdziwego celu. To spowodowało, że w ten sposób pracują już nie tylko zapaleńcy, którzy doskonale rozumieją co robią i po co. Nagle robią to wszyscy, także ci którzy się na tym nie znają, nie mają o tym żadnego pojęcia i też nie wiedzą do czego tak naprawdę Scrum nadaje się najlepiej. Co gorsza, są też tacy, którzy pracują w ten sposób, bo im ktoś kazał.
Ślepe stosowanie Scruma powoduje kuriozalne problemy, takie jak np. osobne zespoły testerskie, Zespoły Scrumowe oddzielone od biznesu warstwami procesów do zgłaszania i przetwarzania potrzeb biznesowych na specyfikację oprogramowania czy oddawanie w Sprintach tylko analizy albo samego kodu bez testów.
W „starych dobrych czasach” nikomu by nie przyszło do głowy chwalenie się skończoną analizą albo nieprzetestowanym kodem jako wartościowym produktem wytworzonym w Sprincie. Co więcej, nikomu by nie przyszło do głowy Planowanie Sprintu w którym w ogóle zamierzamy zrobić tylko część funkcjonalności, a nie zamknąć całość od A do Z. „Sama analiza”, „sam backend” – to są jakieś absurdy.
Temat ten poruszałem między innymi w tekście Definition of Almost Done. Nie nam chodzi o to, żeby zbudować cały system albo skomplikowany proces w jeden Sprint. Chodzi o to, żeby podzielić pracę na takie fragmenty, żebyśmy w czasie pojedynczej iteracji byli w stanie zrobić jakiś jeden mały element w całości. Albo jeszcze lepiej – kilka takich elementów.
Co właściwie powstaje w Sprintach?
Scrum Guide 2020 znacząco zmienił używany w materiałach źródłowych język. Chodziło o to, żeby Scrum pasował nie tylko i wyłącznie do wytwarzania oprogramowania. Moim zdaniem to błąd. Jeśli autorzy naprawdę chcieli pójść w tym kierunku, to przykłady związane z IT powinny zostać w podręczniku właśnie jako przykłady bądź jako suplement. Teraz niestety o wiele łatwiej o dowolne interpretacje scrumowych treści.
W dzisiejszych czasach gdzie się nie spojrzy, tam natrafimy na puste dyskusje o wartości dostarczanej w Sprintach, itp. Tymczasem nikt nie jest w stanie powiedzieć, co to tak naprawdę jest ta wartość i czy diagramy opisujące jakieś proces są tą wartością, czy też nie (nie, nie są).
Proponuję cofnąć się do poprzednich wersji Podręcznika Scrum i już na etapie budowy zespołów, a w szczególności na etapie Planowania Sprintu, zadbać o to, żebyśmy potrafili tworzyć skończone i gotowe do użycia, a także potencjalnie wdrażalne przyrosty oprogramowania. Niech nasz Przyrost faktycznie ma chociaż jedną skromną funkcjonalność, której nie było Sprint temu.
Wcale nie znaczy to, że w jeden Sprint musi powstać coś kompletnego i biznesowo użytecznego. Powtarzam to od zawsze i będę powtarzał bez końca – backend bez frontendu nie jest żadną wartością. Tak samo „zamockowany formularz, na którym żadne pole nie działa”. Sama analiza to też nie to. Podobnie nieprzetestowana fukncjonalność, co do której nie mamy pewności czy działa.
Na pewno wartościowe jest prawie wszystko, co jest klikalne i pozwala nam „coś zrobić”. Nawet jeśli to jest np. możliwość samego załadowania dokumentu do przetwarzania, bez jego przetwarzania. Bo „załadowanie dokumentu” to jest jakaś funkcjonalność, która potencjalnie mogłaby się pojawić na tej liście tysięcy czy dziesiątków tysięcy rzeczy, które nasz system miał robić. Tylko pracując scrumowo nie tworzymy takiej listy z góry – powstaje ona w backlogu na podstawie tworzonych Przyrostów, refinementów, a także pracy Product Ownera z Interesariuszami.
I każda taka drobna funkcjonalność, jak już zrobimy, to jest ona zrobiona, skończona, gotowa do użycia i potencjalnego wdrożenia. I o to właśnie chodzi w Sprintach.
