Nie każdy zespół Scrumowy jest zwinny: Fake Agile

Fake Agile: Czy każdy zespół Scrum jest zwinny?

Nie, niestety nie każdy zespół Scrumowy jest faktycznie zwinny.

Pozwól mi wyjaśnić: Zespół Scrumowy definiuje się poprzez pracę zgodnie z frameworkiem Scrum: Ma więc sprinty, określone role i rytuały. A ponieważ celem frameworka Scrum jest pomoc zespołom w pracy w zwinny sposób, Scrum powinien automatycznie uczynić każdy zespół zwinnym, prawda?

Niestety, w praktyce organizacjom wciąż zdarza się wprowadzać Scruma, przez co zespoły stają się wszystkim, tylko nie zwinne. Często mówi się wtedy o “Zombie Scrum”.

Co to jest “Fake Agile”?

“Fake Agile” odnosi się do zespołów, które oficjalnie pracują z wykorzystaniem zwinnych ram i metod, ale bez faktycznych pętli uczenia się z klientami. Fake Agile oznacza więc, że albo a) w ogóle nie dostarcza się iteracyjnie inkrementów klientom, albo b) bezpośrednie informacje zwrotne od klientów na temat inkrementu nie są wykorzystywane do krótkoterminowego ustalania priorytetów.

Jakie są przyczyny Fake Agile?

Przyczyn “Fake Agile” jest wiele. Z mojego doświadczenia wynika, że najczęstsze przyczyny Fake Agile w praktyce są następujące:

Fałszywy Agile Przyczyna #1: Brak opinii klientów

Jeśli zwinny zespół nie otrzymuje bezpośredniej informacji zwrotnej od użytkowników, nie może pracować w zwinny sposób. W praktyce żądania klientów są często formułowane przez kierownictwo i przekazywane zespołom za pośrednictwem właścicieli produktów – Prawdziwe pętle informacji zwrotnych z klientami zanikają lub nawet nie istnieją.

Zwinny zespół potrzebuje bezpośredniego kontaktu z klientem!

Fake Agile Cause #2: Skoncentruj się na szybkości i punktach fabularnych

Uff, czy musimy mówić więcej o story pointach w 2025 roku? Myślę, że wszyscy mamy wystarczająco dużo doświadczenia w tym, jak bardzo skupienie się na szybkości i story pointach stoi na drodze do korzyści dla klienta.

Przykład: Co się dzieje, jeśli funkcja jest formalnie gotowa po pierwszej iteracji, ale nie osiąga jeszcze korzyści dla klienta? Jeśli korzyść dla klienta jest dla nas ważna, pracujemy nad nią, aż korzyść dla klienta zostanie faktycznie osiągnięta. Ostatecznie może to zająć 3 iteracje, ale przynajmniej klient jest teraz zadowolony.

Ale zaraz, teraz mój menedżer nagle pojawia się za rogiem i narzeka, że mój zespół zrealizował mniej story points w ostatnim sprincie. Więc byłoby lepiej dla mojej prędkości, gdybyśmy po prostu opuścili niewartościową funkcję i pracowali bezpośrednio nad następną funkcją, abyśmy mogli stworzyć więcej punktów historii.

Co za bzdury, prawda? Jeśli powtórzymy ten proces jeszcze przez kilka miesięcy, otrzymamy produkt z wieloma funkcjami, które przynoszą bardzo niewielkie korzyści klientom.

Nie powinno więc dziwić, że zarówno klienci, jak i zespoły programistów stają się niezadowoleni i odchodzą.

Mówiąc bardziej ogólnie, chodzi o dobrze znane prawo: Prawo Goodhardta

“When a measure becomes a target, it ceases to be a good measure.”

Fałszywy Agile Przyczyna #3: Dyktatura dogmatów

Inżynierowie uwielbiają, gdy istnieją stałe zasady dotyczące wszystkiego. To sprawia, że procesy można planować.

Jak by było, gdybyśmy nasze sposoby pracy również całkowicie ustalili za pomocą zasad – czyż to nie byłoby wspaniałe? Nie, nie byłoby.

Dzięki samemu Scrumowi i jego wielu zasadom i wytycznym, praca zwinna już teraz dla wielu zespołów wydaje się pracą według sztywnych wytycznych. Nie powinno tak być. Nie należy więc pogarszać tej sytuacji poprzez dodawanie kolejnych zasad i wytycznych do pracy zwinnej.

W najlepszych zwinnych zespołach, jakie znam, praca jest ludzka, żywa, spontaniczna i oparta na współpracy. Trzeba przyznać, że w większości zwinnych zespołów tak nie jest.

Zespoły Agile muszą mieć przynajmniej wystarczającą swobodę, aby móc elastycznie współpracować z klientami. Jeśli zasady i procesy to uniemożliwiają, należy je przeanalizować.

W tym poście pisałem już konkretnie o krokach wymaganych do ochrony zespołów Scrumowych przed Zombie Scrumem: Fix Zombie Scrum

Fałszywy Agile jest prawdziwy: jak się chronić?

Nic nie chroni w pełni przed fałszywą zwinnością. Jest jednak jedna rzecz, która może chronić najlepiej jak to możliwe: Skuteczny proces skoncentrowany na ciągłym doskonaleniu.

Oczywiście zaczyna się to od dobrych retrospektyw, w których członkowie zespołu mogą otwarcie dzielić się swoimi poglądami oraz skutecznie opracowywać i wdrażać środki poprawy.

Tak długo, jak ten proces działa, potencjał prawdziwej zwinności w zespole nie jest stracony.

Jeśli chcesz przenieść swoje zwinne retrospektywy na wyższy poziom, polecam –naturalnie – Echometer, nasze narzędzie do retrospektyw. Możesz je wypróbować za darmo tutaj: Wypróbuj Echometer