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 zawsze udaje się wprowadzić Scrum i sprawić, że ich zespoły nie są zwinne. Jest to często określane jako "Zombie Scrum".
Co to jest "Fake Agile"?
"Fałszywy Agile" odnosi się do zespołów, które oficjalnie pracują z wykorzystaniem zwinnych frameworków i metod bez rzeczywistych pętli uczenia się z klientami. Fałszywe Agile oznacza zatem, że a) przyrosty nie są iteracyjnie dostarczane klientom w pierwszej kolejności lub b) bezpośrednie informacje zwrotne od klientów na temat przyrostu nie są wykorzystywane do krótkoterminowej priorytetyzacji.
Jakie są przyczyny Fake Agile?
Istnieje wiele przyczyn "fałszywego Agile". Z mojego doświadczenia wynika, że najczęstsze przyczyny fałszywych 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
"Kiedy środek staje się celem, przestaje być dobrym środkiem".
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 to było, gdybyśmy mogli również całkowicie zdefiniować nasze metody pracy za pomocą reguł –, czy nie byłoby to 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
