Cześć!

Halloween nadchodzi! Niektórzy wycinają dynie, inni biegają po sklepach w poszukiwaniu idealnego stroju zombie, a ekipa Brass Willow zamienia się w reżyserów pokroju Stanleya Kubricka i przedstawia Wam Horrory Scruma, czyli jak tego całego Scruma NIE robić.

  1. Scrum Master z piekła rodem

Scrum Master, który podejmuje decyzje za zespół, nie pomaga w rozwiązywaniu problemów, czy też zaprasza bez zgody zespołu menadżera na Retrospekcję Sprintu. Tacy Scrum Masterzy mogą sprawić, że ludzie kojarzą Scruma ze “złem koniecznym” i z pracą bardziej uciążliwą niż w starym, dobrym waterfallu.

  1. Scrum Master Duch

Skrajne przeciwieństwo Scrum Mastera z piekła rodem. Jest, ale jakoby go nie było. Z konceptu servant leadership wziął sobie do serca tylko servant. Pracuje tylko z Development Teamem, ale pracę tę ogranicza do uciekania do cienia i robienia niczego, bo przecież zespół jest samoorganizujący się i da sobie radę, prawda?

  1.  Product Owner Bez Głowy!

Nieobecny Product Owner – albo nie rozumie swojej roli, albo nie potrafi jej łączyć z innymi obowiązkami (np. PO i menedżer w jednej osobie). Odzwierciedleniem takiej sytuacji jest stan Product Backlogu, w którym brakuje informacji odnośnie jego elementów, a Sprint Planning trwa wieczność, bo PO albo traci czas na zorientowanie się, o co chodzi, albo… go nie ma.

  1. Zombie Scrum

“Przeżyliśmy Kanbana, przeżyjemy i Scruma.”, “To już czwarte wdrożenia Scruma w naszej firmie. W tym drugie w tym roku!” Słyszeliście podobne stwierdzenia? Niby coś się zmienia (przeważnie tylko nazwy stanowisk), ale tak naprawdę wszystko zostaje po staremu. Ten symptom został poruszony przez Kate Terlecką w jej ostatnim poście na LinkedIn Pulse, odnośnie modnego teraz tak zwanego “modelu Spotify”: Zachęcamy do lektury, zanim nazwiecie zespoły “trajbami” i powołacie “czapter lida”.

  1. Scrum Taliban

Scrum Master ewangelizator, Scrum Evangelist, Agilist, Scrum Master Dogmatyczny. Przychodzi, puka do Twoich drzwi i mówi, że to, co robiliście całe swoje zawodowe życie jest złe. W ręce trzyma książkę (“The Scrum Guide”) – jedyne źródło prawdy. Powinniście znać ją na pamięć i się stosować.

Agile i Scrum to nie religie. Mimo skupienia na wartościach i zasadach, podejściu do pracy, są to nadal jedynie środki do osiągnięcia celów biznesowych firmy. Scrum Master którego jedyną odpowiedzią na wszystkie pytania o Scruma jest “Bo w Scrum Guidzie jest tak napisane” lub ewentualnie “Scrum Guide nic o tym nie mówi” – to d..a nie Scrum Master.

W takich przypadkach zachęcamy do wywiezienia pacjenta na taczce lub kontaktu z nami.

 

  1. Klient minionego lata

Współpraca zapowiada się bardzo obiecująco – klient rozumie korzyści jakie daje zwinny rozwój produktu oraz jest otwarty na współpracę. Moment euforii trwa do pierwszego Sprint Review, gdzie niezadowolenie i oburzenie klienta spotyka się ze zdziwieniem i dezorientacją Zespołu Scrumowego. Kolejny klient, któremu zwinność pomyliła się z szybkością, niestety często koszmar software house’ów.

  1. Daily Standup

Klasyka gatunku, niczym “Lśnienie” w historii światowego horroru. Poziom adrenaliny przed takim “standupem” jest taki, że kawy nie trzeba. Często jest na nim obecny menadżer, a samo spotkanie zwane jest statusem albo spowiedzią. Wszyscy muszą stać, bo nazwa spotkania zobowiązuje, a poza tym szybciej idzie. Nieważne, że nie osiągamy celu spotkania, ale ważne, że się w czasie wyrabiamy, mamy Scruma!

  1. Estimates = deadline

Tak, estymaty to najlepiej robić w godzinach, albo jeszcze lepiej – estymować w story pointach (bo przecież są w Scrumie), a potem przeliczyć na godziny, żeby się w Excelu zgadzało. A na deser wyciągać konsekwencje od Zespołu Deweloperskiego, który nie zmieścił się w podanym czasie. No coż, w niektórych organizacjach ciężko jest zrozumieć, że nawet głupi remont łazienki zawsze przekracza zakres, budżet i deadline, a co dopiero rozwój oprogramowania. Estymowanie w Scrumie to narzędzie pomocnicze, a nie zaklinanie przyszłości.

9. “Intro to Scrum in 10 minutes”

W organizacji została podjęta decyzja, że “idziemy Scrumem”. Zarząd wybiera młodego, ambitnego człowieka, któremu zamiast podwyżki daje zaszczytne zadanie “wdrożenia Scruma”. Budżetu na szkolenia nie ma, więc Free On-line 100% quality ScrumHeroCertified zaliczony, człowiek zaczyna zabierać się do pracy.  W przypadku, gdy wybrany zostaje ktoś, kto rozumie Scruma i mówi zarządowi o zmianie myślenia słyszy “The mindest was already decided.”

  1. Imposed deadlines, scope & budget 

Mamy terminy, zakres i budżet, można zaczynać projekt! Wszystko to, jest spisane w cyrografie podpisanym krwią, a wywalczonego blizną. Empiryzm? Transparencja? Kto by się tym przejmował. 

 

  1. Dług techniczny

Ten moment, kiedy Twój stary bierze kredyt, coś tam podłubie na szybko i zwinie się na Karaiby, a Ty zostajesz z przeciekającym zlewem i komornikiem pukającym do drzwi.

Scrum nie jest wylewny w sprawie jakości i praktyk inżynierskich. (I słusznie, bo jest tylko frameworkiem.) Więcej o długu technicznym, jak zabić to zombie i czemu warto płacić swoje długi pisał Paweł Zajączkowski.

  1. Demo zamiast Sprint Review

Demo to nie Sprint Review. Demo to jedynie element Sprint Review, raczej najkrótszy, a do tego nie zawsze zresztą. Celem Sprint Review jest zebranie feedbacku od interesariuszy, dyskusja o wartości Incrementu i o dalszych krokach. Podczas Przeglądu Sprintu aktualizujemy plan projektu, sprawdzamy zmiany w jego otoczeniu. Demo jest dobrym otwarciem do tych dyskusji, ale jeśli Sprint Review = Demo, to nie róbcie tego, szkoda czasu.

 

  1. Ghost DoD

– Robicie Scruma? To pokażcie mi Wasze Definition of Done.

– Nie mamy, ale wszyscy wiemy, co musi być zrobione.

Nie ma Definition of Done, nie ma Scruma. Ale nie tylko o takie formalności chodzi. DoD to nie wish-lista czy check-lista, ale określenie standardu jakości. Bez zapisanego standardu trudno się go trzymać, a pokazując Increment podczas Sprint Review nikt nie może być do końca pewien, co to właściwie znaczy “Increment” w tym przypadku.