- Czym jest Refinement Backlogu Produktu? — 27/11/2024
- Czym jest burndown chart? — 22/11/2024
- Czym jest Retrospektywa Sprintu? — 18/11/2024
Choroby trawiące zespoły Scrum #4 — Spady
W Scrum Guide nie ma takiego obowiązku, żeby Zespół Scrum ukończył wszystkie elementy, które wciągnie do Sprintu. Z drugiej strony jednak na koniec Sprintu powinniśmy mieć Przyrost Produktu. Czyli jakieś elementy powinny być ukończone zgodnie z Definition of Done. Elementy, które nie są ukończone, wracają do Backlogu Produktu.
Spady - nieukończone (undone) elementy Backlogu Produktu z poprzedniego Sprintu kontynouwane w kolejnym lub wielu kolejnych Sprintach.
If a Product Backlog item does not meet the Definition of
Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
[Scrum Guide 2020]
Objawy spadów w Scrumie
Wszystko, co zostanie w stanie niedokończonym po zakończeniu Sprintu to spad, obojętnie czy wraca do Backlogu Produktu i tam zostaje, czy od razu pojawia się w kolejnym Sprincie. Nie ma gwarancji, że będziemy kontynuować pracę nad elementem, ponieważ Product Owner może zdecydować, że jest coś ważniejszego do zrobienia.
Jeżeli nie będziemy kontynuować prac, to warto się zastanowić, czy trzeba posprzątać produkt. Pozostawienie niedokończonego kodu może stanowić ryzyko awarii na produkcji po wydaniu. Taki niedokończony spad w Backlogu Produktu może stracić na ważności. Jeśli wrócimy do niego za miesiąc albo później, to produkt może inaczej wyglądać i cały opis oraz praca wykonana nadają się do kosza.
Trudno jest taką pracę zaplanować na Planowaniu Sprintu. Możemy oszacować, ile Story Pointów zostało i tak policzyć, ile możemy jeszcze dobrać z Backlogu Produktu. Możemy też szacować procentowo, ile jeszcze zostało. Tutaj mam nadzieję, że nie będzie to za każdym razem magiczne 10%. Jeżeli element nie został przetestowany, to trzeba pomyśleć, że nie rozmawiamy o wykonaniu testów, tylko bardziej o procesie testy — bugfix — retest — testy regresji z możliwymi powtórkami. I nawet w jednostkach czasu trudno jest oszacować, ile faktycznie zajmie dokończenie tego elementu.
Większy problem może pojawić się, kiedy Zespół Scrum nie dokończy kilku elementów niż to, że został nam jeden spad.
Jeszcze większy problem pojawia się, gdy Zespół Scrum ma nawyk, a wręcz nawet tradycję niedokańczania elementów. Na przykład zawsze zostaje połowa zakresu Backlogu Sprintu i automatycznie przechodzi na kolejny Sprint. Nieoczywistym skutkiem ubocznym staje się to, że Sprinty niczemu nie służą i jest to fikcja. Co najwyżej mamy cykliczne Wydarzenia Scrumowe. Ale skoro zawsze nie kończymy i zawsze jest przecież kolejny Sprint, to po co planować pracę w Sprincie? Ktoś może powiedzieć, że przecież to jest Kanban, ale do Kanbana potrzebujemy limitów i metryk. Więc ani Kanban, ani Scrum. Nie ma presji, która jest kluczowa, żeby pojawiła się samoorganizacja w zespole.
Drugi problem ze spadami, który jest bardziej widoczny, ma Product Owner. Product Owner odpowiada za zarządzanie interesariuszami. Standardowe pytania interesariusza to “Na kiedy to będzie” i “Co będzie w wydaniu”. Jeżeli planowane elementy Backlogu Produktu nie kończą się w Sprincie, to równania Ilość Sprintów = Zakres/Średnie Velocity i Zakres = Ilość Sprintów x Średnie Velocity nie zadziałają. Co robić? Chyba jedynie liczyć na piechotę z założeniem, że Zespół Scrum kończy elementy w drugim Sprincie po ich podjęciu (o ile na drugim Sprincie się kończy).
Najgorsza sytuacja powstaje, kiedy ktoś wpada na pomysł, żeby takie niekończone spady oznaczyć jako Done i wrócić do nich przed wydaniem. Nikt wtedy nie jest w stanie oszacować, ile czasu zajmie dokończenie każdego elementu. Pojawia się okres stabilizacji wersji, który trwa zawsze “jeszcze jeden Sprint i już będzie”.
Do tego wszystkiego dochodzą jeszcze skutki psychologiczne spadów. Cięgle niedokończona praca, bałagan w produkcie mogą działać demotywująco. Zespół Scrum staje się nieprzewidywalny, więc traci zaufanie interesariuszy. Może nawet Product Owner przestanie ufać Developerom. Cała organizacja może przestać wierzyć w skuteczność Scrum na zasadzie “skoro Scrum tak wygląda, to my podziękujemy”.
Przyczyny spadów w Scrum
Zaczynajac od początku, źródło spadów może leżeć w niewłaściwym oszacowaniu wielkości elementów Backlogu Produktu. Jeśli źle oszacujemy element, to może się tak zdarzyć, że w trakcie Sprintu okaże się większy. Może gdybyśmy przeszacowali teraz jego wielkość w oparciu o to, czego się dowiedzieliśmy wykonując pracę, to byśmy mogli lepiej oszacować podobne elementy.
Kolejną przyczyną może być wzięcie zbyt dużej ilości pracy do Sprint Backlogu. Jeżeli widzimy, że Zespół Scrum nie kończy pracy, którą bierze, to Scrum Master powinien interweniować. Przynajmniej powinniśmy porozmawiać o tej sytuacji na Retrospekcji Sprintu i zdecydować, jak działamy w kolejnym Sprincie, żeby to się nie powtórzyło.
Może być też tak, że zakres pracy w każdym elemencie nam rośnie, ponieważ dodajemy zakres przez akceptowanie feedbacku od Product Ownera lub interesariuszy.
Następną przyczyną może być wpadajaca do Sprintu dodatkowa praca. Zespół Scrum zrobił coś innego, niż planował. Najczęściej pojawiają się pilne tematy albo awarie (to już wrzódki).
Brak dobrej współpracy w zespole. Kiedy każdy Developer patrzy tylko na swoje zadania, albo jakiś manager pilnuje, żeby każdy był zajęty (capacity allocation), to szukając pracy, Developerzy niepotrzebnie rozpoczynają nowe elementy zamiast postarać się ukończyć nowe. Może dojść do sytuacji, że różne moduły są rozwijane w różnym tempie i podobnie powstaje architektura systemu. Na przykład back-end znacznie wyprzedza front-end i nie można przetestować całości, a tym bardziej zbudować paczki. Może w następnym Sprincie to wyrównamy, ale czy na pewno?
Często developerzy nie potrafią pracować razem nad jednym elementem i nieświadomie tworzą waterfall w Sprintach. Są rodzaje pacy, których nikt nie lubi i powodują opóźnienia zamknięcia całego elementu (np. przegląd kodu).
Niskie standardy pracy mogą powodować, że element wiele razy wędruje po tablicy w przód i tył. Wraca z przeglądu kodu, wraca z testów, czeka na poprawkę i tak w koło. A czas do końca Sprintu biegnie nieubłagalnie.
Niespodziewane problemy techniczne i napotkanie długu technicznego mogą spowodować, że praca jest zablokowana w oczekiwaniu na rozwiązanie problemu (często wtedy też zaczynamy coś nowego) albo ta praca się zwiększa, bo na przykład dochodzi nam refaktoring, o którym nie wiedzieliśmy na Planowaniu Sprintu.
Zależności poza zespołem też mogą powodować blokadę pracy i konieczność czekania na ukończenie albo poprawki na zewnątrz. Jeżeli inne zespoły mają inne priorytety niż my, to taki element Backlogu Produktu może długo czekać w Sprincie i na długo wrócić do Product Backlogu.
Leczenie w Scrum
Jeżeli mamy problem z planowaniem zakresu Sprintu, to zespół powinien wziąć zdecydowanie mniej pracy, a nawet wziąć tylko elementy do dokończenia i jak je zrobi, to dopiero dobrać nową pracę. W ten sposób możemy odciąć “ogony” i od kolejnego Sprintu planować tak, żeby zmieścić się w Sprincie. Tak, Scrum Master może to nawet wymusić na Zespole i nadal być Servant Leaderem.
Lepsza pielęgnacja Backlogu Produktu (ang. Product Backlog refinement) może pomóc w lepszym oszacowaniu elementów. Bardziej asertywne zarządzanie oczekiwaniami Product Ownera i interesariuszy pomoże zaplanowane elementy ukończyć. Jeżeli pojawią się uwagi, dodatkowe potrzeby, to stwórzmy na nie osobne elementy w Backlogu Produktu. Pytanie, czy w porównaniu z tym, co mamy już na backlogu, te elementy będą teraz tak wartościowe, żeby robić je w kolejnym Sprincie.
Zarządzanie zależnościami z innymi zespołami w postaci przeglądów, wspólnego planowania czy wspólnego pielęgnowania Product Backlogu pomogą nam uniknąć blokady w trakcie Sprintu. Bierzmy do Sprintu tylko te elementy, gdzie zależność jest już rozwiązana. Nie można liczyć na to, że jak weźmiemy coś do Sprintu, to inny zespół dostarczy nam brakujący element wtedy, kiedy będziemy go potrzebowali.
Jeżeli widzimy, że element w Sprincie “puchnie”, albo został za nisko oszacowany, to od razu porozmawiajmy z Product Ownerem. Możemy podzielić element i zrobić tylko część (np. wersja podstawowa), a resztę od razu zwrócić do Backlogu Produktu. Możemy też usuwać elementy ze Sprintu jeśli widzimy, że czegoś nie uda się zrobić. Patrząc na wykres spalania i na tablicę widać w środku sprintu, że nadciągają kłopoty. Inspect & Adapt.
Zespół powinien starać się kończyć elementy jak najszybciej w imię zasady “Start finishing, stop starting”. Warto jest spojrzeć, który element (np. User story) możemy dzisiaj skończyć, a nie jakie taski wezmę na siebie, żeby mieć zajęcie. Przed rozpoczęciem pracy nad nowym elementem warto jest usiąść, zaplanować architekturę i wygląd wspólnie, a może nawet podzielić ten element na mniejsze. Dopiero teraz podzielmy się pracą tak, żeby pracować równolegle. Back end, front end, wygląd, testy automatyczne można robić równocześnie. Można też skorzystać z podejścia BDD (Behavior Driven Development) albo ATDD (Acceptance Test Driven Development)) i zacząć od zaprojektowania testów. W ten sposób czynność testowania w znacznej mierze przesuwamy na tablicy w prawo i nie robimy testów na sam koniec. Kto jest odpowiedzialny za testy? Developerzy, w Scrumie nie ma roli testera.
No i wreszcie wykorzystajmy Retrospekcję Sprintu do szukania i eliminowania przyczyn spadów. Może trzeba zastanowić się nad Definition of Done, może nowe techniki i narzędzia nam pomogą. Może nasz proces i tablica powinny inaczej wyglądać.
Podsumowanie
Spady w Sprincie mogą być codziennością w niektórych Zespołach Scrum, ale to nie znaczy, że jest to sytuacja prawidłowa. Spady niosą ze sobą ryzyko w produkcie i utratę zaufania do zespołu w organizacji. Proste metody pomagają uleczyć Zespół Scrum. Ale najpierw potrzebna jest decyzja, od kiedy zaczynamy czyste Sprinty.
Trackbacks/Pingbacks