Witam ponownie w drugiej 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! - Przez scruma spędzamy “połowę” czasu sprintu na spotkaniach

PRAWDA! / FAŁSZ! - Porządek backlogu = priorytety zadań

PRAWDA! / FAŁSZ! - Scrum pozwala na release aplikacji w dowolnym momencie sprintu

PRAWDA! / FAŁSZ! - Sprint Review to demo wyniku sprintu

Przez Scruma spędzamy “połowę” czasu sprintu na spotkaniach

FAŁSZ! To jeden z moich ulubionych mitów, albowiem z jednej strony jest słyszę go najwięcej w narzekaniach na temat Scruma, a jednocześnie jest dziecinnie prosty do obalenia dzięki….nauce! Dokładnie dzięki matematyce.

Słyszałem to setki razy: “Przez ten cały Scrum częściej siedzimy na spotkaniach i gadamy, aniżeli zajmujemy się faktyczną robotą!”. Wykazując empatię dla członków teamów - są projekty, w których faktycznie tak jest, jednak Scrum nie jest winny takiemu stanowi rzeczy. Kolejny raz zajrzyjmy do Scrum Guide’a: “Scrum przewiduje cztery formalne punkty przeprowadzania inspekcji i okazje do dokonania adaptacji (korekty)…Planowanie Sprintu (ang. Sprint Planning), Codzienny Scrum (ang. Daily Scrum), Przegląd Sprintu (ang. Sprint Review) i Retrospektywa Sprintu (ang. Sprint Retrospective)”. Nie mniej, nie więcej. Wszystkie inne spotkania, które macie w projekcie nie są związane ze Scrumem. Mając to ustalone, przejdźmy do matematyki. Zakładając, że nasz sprint zajmuje (maksymalne dla frameworks) cztery miesiące, to wszystkie powyższe spotkanie zajmują nam odpowiednio:

  • Daily Scrum: 20 x 15 minut (timebox) = 5 godzin,
  • Sprint Planning: 8 godzin (timebox),
  • Sprint Review: 4 godziny (timebox),
  • Sprint Retrospective: 3 godziny (timebox),

Sumarycznie daje to 21 godzin. Przyjmując, że pracujemy po osiem godzin dziennie i brak dni wolnych dla przykładu, to taki miesiąc ma 160 godzin roboczych. Zatem spotkania nie powinny nam zajmować więcej niż 12,5% czasu sprintu. Gdybyśmy dorzucili do powyższej kalkulacji czas spędzony przez Dev Team nad wymaganiami z Product Ownerem, który zgodnie z dobrymi praktykami nie powinien przekroczyć 10% czasu sprintu (16 godzin), to wciąż zamykamy się ze wszystkim w 22,5%. To wszystko, co powinno nam wystarczyć w projekcie na jego prawidłowe funkcjonowanie i osiąganie celów sprintu. Przyznacie zatem, że nijak ma się to do większości czasu w sprincie oraz, że czasu na “faktyczną pracę” jest CAŁKIEM sporo - prawda? “Scrum zapewnia minimalny zestaw ram (pięć zdarzeń, trzy role, trzy artefakty), umożliwiający prowadzenie odpowiednich rozmów w odpowiednim czasie z odpowiednimi osobami.” - Barry Overeem_._

Skąd zatem wziął się mit? Powodów, jak to zwykle bywa z takimi mitami, jest wiele. Może być tak, że organizacja czy projekt posiadała już tzw. kulturę spotkań, zanim Scrum pojawił się w środowisku pracy. Menedżerowie i kierownictwo uwielbiały traktować każdy temat czy problem jako okazję do zorganizowania spotkania - nic albowiem nie pokazuje efektywności naszej pracy, jak liczba spotkanio-godzin w kalendarzu! Innym powodem może być frustracja zespołów developerskich z jakości spotkań, która rodzić może się - znów - z wielu powodów. Spotkania to nie jest prosta sprawa, a na pewno nie spotkania w Scrumie, które mają swoje określone dane wejściowe, cele i artefakty na wyjściu - dobrze, że Scrum Guide wszystkie z nich nam opisuje. Przykładem, który momentalnie przychodzi mi do głowy, jest retrospektywa: jeśli w wyniku spotkania zespół nie zidentyfikuje jednego obszaru do poprawy i nie przełoży tego na realizowaną akcję w kolejnym sprincie, spotkanie szybko straci jakikolwiek zaangażowanie zespołu, którego miejsca zajmie frustracja i zniechęcenie. Do jakości spotkań dochodzi również ich timebox, co oznacza, że spotkania nie mogą trwać dłużej aniżeli zostało to ustalone, ale mogą się skończyć szybciej. Scrum Master powinien aktywnie działać, aby zespół scrumowy był w stanie zmieścić się w ramach czasowych spotkań i tłumaczyć, co dlaczego możemy się rozejść wcześniej - bo podobno trzeba to tłumaczyć (tak, to komentarz do aktualizacji SG, w której łopatologicznie wytłumaczony został ‘timebox’).

Porządek backlogu = priorytety zadań

FAŁSZ! Najpewniej widzieliście to w waszych projektach: górna część backlogu pali się krwistoczerwonym kolorem, następnie przechodzi w delikatny pomarańcz czy żółć, natomiast podłoga listy to zielona papka trywialnych zadań. Nie? Zapomniałem, że w JIRZE teraz są te strzałki zamiast kolorów, ale meritum zostaje: lista wymagań w projekcie po układana od zadań krytycznych do tzw. minorów. Pewnie też usłyszeliście odpowiedź nie raz od klienta czy osoby nazywanej Product Ownerem, że: “wszystko dla mnie jest krytyczne, nie chce wybierać, wszystko ma być zrobione”. Taki stan rzeczy bierze się właśnie z nieprawidłowego rozumienia, jak uporządkować Backlog Produktu - postrzegania kolejności na równi z priorytetyzacją.

Z drugiej strony, nie można się temu przesadnie dziwić. Myśląc o kolejności wykonywania kolejnych zadań, przychodzi nam do głowy, że powinniśmy pracować od tych najistotniejszych. Zauważyli to również twórcy Scruma, którzy w 2011 zauważyli problem, jaki wynika z użycia słowa ‘prioritized’ w przewodniku po swoim frameworku, w kontekście ułożenia Product Backlogu i postanowili zastąpić je słówkiem ‘ordered’. Obecnie początek opisu tego artefaktu Scruma rozpoczyna się następująco: “Backlog Produktu to uporządkowana lista…”. Problem bardzo ładnie zobrazował James Coplien, który użył metafory budowania domu w lesie równikowym: gdybyśmy zastanawiali się nad istotą części domu w takich warunkach jak Las Amazonii, to byłby to dach. Zatem wylądowałby na szczycie naszej listy rzeczy do zrobienia. Problem w tym, że bez ścian i fundamentów, będzie to raczej trudne, a z perspektywy “ważności” dla nas, dach byłby nad nimi. A zatem kolejność ułożenia Backlogu Produktu musi brać pod uwagę znacznie więcej, aniżeli jedynie istotność realizacji konkretnego zadania. Do przykładowych składowych wpływających na kolejność, zaliczają się:

  • Zależności pomiędzy PBI (Product Backlog Item)
  • Ryzyka związane z implementacją (bądź nie) konkretnego PBI
  • Zasób wiedzy zespołu developerskiego w danym momencie
  • Warunki biznesowe, jak np. konkurencja na rynku
  • Istotność dla celów organizacji
  • Koszt implementacji
  • Koszt zwlekania z implementacją
    (niezbyt spotykana, a ciekawa metryka)
  • oraz inne zależne od domeny, w której pracujemy

Zatem, jak widzicie jest tego trochę, a nad wszystkim pieczę trzyma jedna osoba: Product Owner. Mit kolejności równej priorytetom spłyca mocno jego rolę w projekcie do osoby manipulującej dropdownem w JIRZE i generatora historyjek. Gdzie w rzeczywistości Product Owner jest niezwykle kluczowym ogniwem w sukcesie produktu, przed którym stoi nie lada zadania, albowiem jak Scrum Guide opisuje Product Backlog: “Backlog Produktu ewoluuje wraz z produktem i środowiskiem, w którym ten produkt będzie używany. Zmienia się dynamicznie, aby uwzględnić to, czego produkt wymaga, aby stać się odpowiednim, konkurencyjnym i użytecznym.”. Dużo jak na jedną osobę - prawda. Aczkolwiek PO nie musi zajmować się tym wszystkim w pojedynkę. Tak, tak. Doskonale pamiętam, że rola ta to jedna osoba, a nie komitet, aczkolwiek w obronie moich słów przytoczę metaforę trenera drużyny piłkarskiej. Każdy trener posiada swój sztab trenerski, grupę ekspertów, którzy pomagają mu podejmować decyzje i budować odpowiednią jedenastkę na kolejny mecz. Wszyscy natomiast muszą respektować jego zdanie i wyboru, albowiem to on jest ostatecznym głosem decydującym o taktyce drużyny. Dlatego też PO w projekcie musi posiadać moc sprawczą do niezależnego kierowania produktem, a reszta Zespołu Scrumowego powinna mu w tym pomagać - jak najlepiej ze sobą współpracując. W końcu gramy do tej samej bramki.

Scrum pozwala na release aplikacji w dowolnym momencie sprintu

PRAWDA! Nie jestem pewien, skąd wziął się ten mit, ale najczęściej słyszałem go w kontekście argumentowania wyższości Kanbana nad Scrumem. Nie wspominając o będącym coraz bardziej popularnym kierunku DevOps. Zespoły te uważały, że Scrum je hamuje, ponieważ muszą czekać z wypuszczeniem i inspekcją produktu do końca sprintu - oh, drogie dzieci słońca. Jest to oczywiście nieprawdą, albowiem nic w Scrumie oraz Scrum Guidzie nie zabrania zespołowi wypuszczać nowej wersji oprogramowania live, co dzień, co godzinę, co komit. Scrum wspiera continuous integration, tak samo jak i continuous delivery.

Zaglądając do Scrum Guide’a można by oskarżyć dwa miejsca, o nieumyślne spowodowanie zamieszania z releasowaniem w Scrumie. Pierwszym z nich będzie inkrement (‘przyrost’ w SG), który według publikacji jest: “…sumą wszystkich elementów Backlogu Produktu zakończonych podczas Sprintu i wartości Przyrostów ze wszystkich Sprintów poprzednich. Na koniec Sprintu nowy Przyrost musi być „Ukończony”, co oznacza, że musi on być gotowy do użycia i zgodny z definicją „Ukończenia”Zespołu Scrumowego.”. Oznacza to tyle, że na zakończenie sprintu musimy mieć działającą wersję naszego produktu, zawierającą pracę wykonaną w trakcie sprintu. Natomiast nic w definicji Przyrostu nie implikuje brak wypuszczania kolejnych wymagań na produkcje. Drugim podejrzanym winowajcom jest sformułowanie: “potencjalnie wydanego”, które w różnych odmianach występuje blisko dziesięciokrotnie w Scrum Guide, m.in. jako: “Zespół Deweloperski złożony jest z profesjonalistów, których zadaniem jest dostarczenie, na zakończenie każdego Sprintu, „Ukończonego” i gotowego do potencjalnego wydania Przyrostu (ang. Increment) produktu.” czy “Sercem Scruma jest Sprint —ograniczony czasowo do maksymalnie jednego miesiąca, podczas którego wytwarzany jest „Ukończony”, gotowy do użycia i potencjalnego wydania Przyrost Produktu”. Nadinterpretacja doprowadza zespołu do sytuacji, w której to praca skupia się na dostarczeniu TYLKO potencjalnie gotowego na produkcję produktu. A gdybyśmy tak siadając do Sprint Review nie otwierali aplikacji do przeklikania się po User Story, a analizowali rezultaty naszej pracy w konfrontacji z rynkiem, użytkownikami i środowiskiem produkcyjnym, a następnie na podstawie tego podejmowali decyzje o kolejnych krokach dla produktu - intrygujące, prawda?

Sprint Review to demo wyniku sprintu

FAŁSZ! Początkowo miał tu się znaleźć zupełnie inny mit, natomiast po zakończeniu poprzedniego, momentalnie przyszedł mi do głowy anty-wzorzec, z którym spotkałem się w każdym projekcie mojej kariery w IT. Z rozmów z kolegami i koleżankami z branży, dostrzegam, że problem ten jest raczej globalny. Pewnie i wam się taki scenariusz przytrafił:

  1. Zespół w pocie czoła dociska ostatnie zmiany w User Story
  2. Gdzie potrzeba, stawiamy makiety i odpowiednie dane testowe
  3. Wybija 14:00, siadamy na Google Meets i każda ze stron zadaje min. dwa razy pytanie. czy ją dobrze słychać
  4. Zaczyna się udostępnianie ekranu i najwięcej zarabiająca osoba przy stole rzuca: “Jazda ekipa!”
  5. Zespół trzyma kciuki, osoba klikająca recytuje przygotowany scenariusz, wszystko działa, nie ma pytań z drugiej strony, zamykamy ostatnie User Story - działa!
  6. Oklaski
  7. Żegnamy się i życzymy sobie udanego popołudnia, do zobaczenia na planowaniu
  8. Wszyscy są zadowoleni ze świetnego Sprint Review

Jest to niezwykle smutne, albowiem Sprint Review to tak wiele więcej, aniżeli zaprezentowanie Przyrostu. Jednocześnie robienie z Review dema funkcjonalności, pozbawia zespół scrumowy szansy na prawidłowe przeprowadzenie procesu inspekcji i adaptacji, który jest u sedna Scrum i Agile. Jak opisuje to sam Scrum Guide: “Podczas Przeglądu Sprintu Zespół Scrumowy i interesariusze wspólnie analizują to,co zostało ukończone w Sprincie. Na tej podstawie oraz na podstawie zmian wprowadzonych do Backlogu Produktu w trakcie trwania Sprintu, uczestnicy spotkania wspólnie rozważają, co mogłoby być wykonane w następnej kolejności, aby zoptymalizować wartość”. Prezentacja wykonanej pracy jest zaledwie jednym z ośmiu składowych spotkania, według przewodnika. Jeśli przypomnicie sobie mity wyżej, mówiący o kolejności ułożenia Backlogu Produktu, to właśnie Sprint Review jest idealnym miejscem na rozmowę o każdym z czynników decydującym o ułożeniu kolejnych prac i celów dla zespołu developerskiego.

W jaki sposób jesteśmy w stanie pomóc, aby zmienić tę sytuację? Działania, przez których wprowadzenie udało mi się udało mi się zwiększyć jakość Sprint Review były m.in. przygotowanie agendy i ustalonego formatu spotkania, a w nim miejsce na prezentacje zmian, feedback, miejsce na podzielenie się przez PO sytuacją biznesu i planami na przyszłość. Już to spowodowało, że chociażby mój zespół, uważał, że wyciąga z tych spotkań znacznie więcej i czuje się częścią zespołu z “biznesem”. Kolejną rzeczą, która fajnie zadziałała to aktywne zapraszanie gości do prezentowania zmian - nie uwierzycie, jak wiele może dać świadomość, że to nie nasz QA będzie klikał po aplikacji, a ktoś spoza Dev Teamu.

I to by było na tyle z pierwszej części serii o mitach i legendach, krążących w świecie IT o Scrumie. Do zobaczenia następnym razem! A, i pamiętajcie: “Scrum is simple, just use it as is!!” - Ken Schwaber