Scream Guide – Gdy Scrum wymagałby zbyt wielu zmian!

W lutym tego roku Michael Küsters opublikował „Scream Guide” – doskonały antyporadnik Scruma napisany w podobnym stylu co Scrum Guide z tą różnicą, że uwypukla całą masę antywzorców. Antywzorców, które możemy spotkać w firmach na co dzień.

Zacznijmy od początku:

Scream – ramy postępowania (ang. framework), w których organizacja tworzy iluzję zaimplementowania Scruma, bez rozwiązywania znaczących problemów. Scream zapewnia złudzenie „Agile”, daje menedżerom dobre przeczucie, że wszystko jest pod kontrolą, egzekwuje surowe terminy i zmusza deweloperów do złych praktyk programistycznych.

Brzmi znajomo?

Scream to framework zbudowany jako imitacja Scruma, wprowadzający nieświadomych obserwatorów w błąd, że organizacja może używać Scruma. Scream jest strukturą umacniającą status quo, zachowującą istniejące nastawienie i tworzącą iluzję, że poszczególne aspekty w firmie lub w zespołach się poprawiają.

Ważne jest przy tym wszystkim, aby używać terminologii Scrumowej, aby ludzie nie zdawali sobie sprawy, że nie jest to Scrum.

Zespół Screamowy

Zespoły Screamowe budują frustrację iteracyjnie i przyrostowo, maksymalizując możliwości wybuchów gniewu. Przyrostowe dostawy „Prawie zrealizowanych” elementów produktu (choć całkowicie bezużyteczne) zapewniają ciągłe poczucie winy i zagrożenia w zespole, podczas gdy biznes nie otrzymuje nic wartościowego.

Menedżer wybiera, jak najlepiej zespół powinien wykonać swoją pracę, zamiast pozwolić zespołowi decydować o sobie. Menedżer dodaje lub odejmuje ludzi w zależności od potrzeb, aby otrzymać „prawie gotowe” funkcjonalności.
Model zespołu w Screamie został zaprojektowany w celu optymalizacji kontroli, uległości i bycia zajętym. Zespół Scremowy udowodnił, że jest lojalny wobec wszystkich wcześniejszych i dalszych nadużyć.

Optymalny rozmiar zespołu jest wystarczająco mały, aby pozostawać pod kontrolą lub wystarczająco duży, aby wyglądało, jakby wykonał znaczną pracę w ramach sprintu.

Product Owner

Właściciel produktu jest odpowiedzialny za maksymalizację obciążenia zespołu deweloperskiego. Sposób, w jaki to się robi, może się znacznie różnić w zależności od organizacji lub zespołów Screamowych.

Właściciel produktu jest główną osobą odpowiedzialną za zarządzanie Backlogiem Produktu i pracą zespołu.

Zarządzanie Backlogiem Produktu obejmuje:

• Przedstawianie elementów Backlogu Produktu w taki sposób, aby ludzie myśleli, że są one jasno opisane, podczas gdy nadal brakuje ważnych faktów;
• Maksymalizację ilości pracy wykonywanej przez zespół deweloperski bez generowania wartości;
• Przenoszenie sztywnych i ustalonych wcześniej wymagań na szablon historyjek użytkownika (ang. User Stories) wypełniając przy tym wszystkie obowiązkowe pola w narzędziu typu Jira lub Trello;
• Zapewnienie, że Backlog Produktu jest tak zaciemniony i mylący, jak to tylko możliwe, a jednocześnie pozornie zrozumiały dla wszystkich i niewiele pokazujący, co tak naprawdę dzieje się w Screamowym zespole
• Podział pracy na odpowiednio małe elementy, aby umożliwić mikrozarządzanie.

Właściciel produktu może wykonać powyższe czynności samodzielnie lub zostać poinformowany przez swojego menedżera, aby to zrobił. Każdy menedżer wyższego szczebla może dodawać, zmieniać lub usuwać elementy z Backlogu produktu bez powiadomienia. Jednak właściciel produktu pozostaje odpowiedzialny.

Właściciel produktu jest marionetką innej osoby lub komitetu sterującego. Właściciel produktu musi poddać się woli tych menedżerów, którzy chcą zmienić priorytet produktu Backlog. Ponieważ z założenie właściciel produktu nie może odnieść sukcesu, cała organizacja może zignorować jego decyzje. Decyzje właściciela produktu są nieistotne dla treści i kolejności Backlogu produktu. Każdy menedżer wyższego szczebla może zmusić zespół programistów do pracy z innym zestawem wymagań w dowolnym momencie.

Podsumowanie

W artykule skupiłem się tylko na kilku ciekawszych aspektach Screamowego poradnika, natomiast zdecydowanie polecam przeczytać go w całości. Gdy prowadzę warsztaty lub wspieram zespoły w ich codziennej pracy, często korzystam z narzędzi typu „antywzorzec” jako metody na przepracowanie konkretnego tematu. A zatem, jeśli cokolwiek z tego artykułu (lub z samego już Scream Guida) wydało się znajome – gorąco polecam na prawdziwej już Retrospektywie porozmawiać o konkretnych sytuacjach i tego, jak wpływają one na generowanie wartości przez Wasz zespół.

Więcej o tym, jak można ciekawie poprowadzić retrospektywę znajdziesz tutaj!