Select Page
Krystian Kaczor
Latest posts by Krystian Kaczor (see all)

dilbert-agile_programming

Dzisiaj an goldenline.pl jeden z członków grupy Scrum zadał mi ciekawe pytanie w prywatnej wiadomości.

co wg Ciebie bądź ludzi których znasz/szkoliłeś jest NIElubiane w Scrum?
Niekoniecznie złe, ale np często zaniedbywane, pomijane bądź traktowane na zasadzie “o nie, znowu to..”. Albo jakieś banalne błędy które potem rozwijają się w duże problemy — np olewa się daily scrum albo spotkania nie są na stojąco lub trwają za długo (wiem wiem, tu powienien SM interweniować).
Ewentualnie możesz napisać co subiektywnie uważasz za nie do końca perfect w scrum.

Zacząłem odpisywać i szło mi to na tyle dobrze, ze wyszedł doskonały materiał na post, którym postanowiłem się niezwłocznie podzielić na moim blogu.

Nazwa całej rodziny metod — Agile

Przede wszystkim dużo psuje nazwa rodziny metod. Agile — zwinne, giętkie, elastyczne, a tak na prawdę jedne z najbardziej rygorystycznych metod wytwarzania oprogramowania. “Aha, czyli teraz nie musimy pisać wymagań, bo jesteśmy agile”, “No ale przecież mogę zmienić zdanie w środku Sprintu, bo jesteśmy agile”, “Ja rozumiem, że zaplanowaliście zadania odpowiednio o posiadanego czasu, ale czy nie możecie być bardziej elastyczni? W końcu jesteśmy agile.” Zrozumienie u managementu często przypomina sytuacje bo cięciu etatów w supermarkecie. “Teraz robimy to samo, ale 2 razy szybciej”.

Brak zrozumienia agile manifesto

Zrozumienie agile manifesto jest małe, raczej używa się go do wymówek. Stąd na przykład fałszywa opinia że w Scrum nie trzeba dokumentować. Jak z każdą zmianą, ludzie automatycznie starają się znaleźć dowody na to, że nie lubiane czynności same się zrobią albo są nie potrzebne. “My robimy Scrum, czyli zadania powinny być już przetestowane.” “Nie wypuszczamy na produkcję, to chyba dokumentacji jeszcze nie trzeba robić.”

Syndrom srebrnej kuli

Syndrom srebrnej kuli odbija się czkawką. Scrum nie nadaje się do każdego projektu, bo czasem wygląda to po prostu sztucznie. Scrum jest prosty frameworkiem dla skomplikowanych środowisk. Scrum niczego nie rozwiązuje sam z siebie, Scrum robi wszystkie problemy bardziej wyraźne. Czyli jeżeli macie kiepskiego Product Ownera (lub analityka Biznesowego) i nie dostarcza jasnych wymagań, to teraz będzie to bardziej kuło w oczy i feedback z Retrospective Meeting będzie politycznie niepoprawny. Niektórzy nawet próbują wpłynąć na jego treść sugerując, żeby nie wskazywać palcami, albo etykietki zmienić z Good/Bad na Good/Almost Good.

Scrum automatycznie tworzy wrogów

Scrum automatycznie tworzy wrogów, z którymi Scrum Master będzie walczył. Są 3 role: Product Owner, Scrum Master i Team. Okazuje się, że niektóre osoby, to właściwie nie wiadomo co robią w projekcie. PM musi przestać uzurpować sobie władze i rozdziela zadania. Team na ogół nie chce mieć PMa jako SM. Nie ma fajnych ról i procesów tak jak w RUP, ITIL, Prince2, żeby każdemu znaleźć coś do dłubania. No i znowu stanie się to bardzo wyraźne.

Pomijanie części założeń i praktyk.

User Stories same się nie napiszą, nie wystarczy podmienić “System shall” na “As a user” i trzeba jeszcze zarezerwować czas na Release Planning i szacowanie User Stories znajdujących się w Product Backlog. O tym często się zapomina i Planning Meeting trwa 2 dni zamiast 4h, a czas potrzebny na te czynności nie jest brany pod uwagę.

Z banalnych błędów to wymieniłbym rozsadzenie zespołu przynajmniej w obrębie jednego piętra, tak że naturalnie nie che się ludziom podejść do PO i jego/ją spytać o zdanie, albo porozmawiać z członkiem zespołu. Wrzucanie więcej niż jednego projektu do jednego Scrum Teamu. Context switching i zerwanie pętli feedbacku zabijają produktywność.

Inspect & Adapt — cała podstawa tego podejścia jest czasem pomijana. Team się spóźnia albo nie chce mieć Daily Scrum. Retrospective Meeting jest widziane jako coś dziwnego z założeniem “Po co nam to? Przecież i tak nic się nie zmieni.”, “To my też musimy to mieć?”. A przecież robienie zawsze tego samego i oczekiwanie innych wyników to definicja szaleństwa.