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 raz po raz udaje się wdrażać Scruma w taki sposób, że zespoły stają się wszystkim innym, tylko nie zwinne. Często mówi się wtedy o “Zombie Scrum”.

Czym jest “Fake Agile”?

“Fake Agile” odnosi się do zespołów, które oficjalnie pracują z wykorzystaniem zwinnych frameworków i metod, ale nie przechodzą rzeczywistych pętli uczenia się z klientami. Fake Agile oznacza zatem, że albo a) w ogóle nie dostarcza się klientom przyrostów w sposób iteracyjny, albo b) bezpośrednie opinie klientów dotyczące przyrostu nie są wykorzystywane do krótkoterminowego ustalania priorytetów.

Jakie są przyczyny Fake Agile?

Przyczyn “Fake Agile” jest wiele. Z mojego doświadczenia najczęstszymi przyczynami Fake Agile w praktyce są:

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

“Kiedy miara staje się celem, przestaje być dobrą miarą”.

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ć.

A co by było, gdybyśmy całkowicie określili nasze sposoby pracy za pomocą reguł - czyż nie byłoby wspaniale? 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