W marcu 2024 pisałem, że Agile żyje i ma się dobrze na przekór tym, którzy usilnie próbują wepchnąć go do grobu (zachęcam do lektury tego artykułu). Niewiele się w tej kwestii zmieniło, poza tym, że do listy rzeczy, jakie mają zastąpić metody zwinne i raz na zawsze rozwiązać wszystkie problemy, dopisane zostały narzędzia oparte o tzw. sztuczną inteligencję.

Jednym z najczęściej powtarzanych argumentów za tezą o porażce metod zwinnych jest ten o nierealnych założeniach, na których opiera się ich mechanika. Praca w krótkich iteracjach? Przecież to nie pozwala zrobić nic naprawdę dużego. Zespoły dostarczające w pełni ukończone produkty w ciągu maksymalnie miesiąca? Tak nie da się rozwijać złożonych rozwiązań, które wymagają pracy dziesiątek ludzi naraz. Wyłaniający się w trakcie prac plan rozwoju produktów? Utopia, bo nikt nie będzie inwestował w ciemno pieniędzy, jeśli nie wie, co za nie dostanie.

Powyższe stwierdzenia i wiele im podobnych nie są niczym nowym. Każdy Scrum Master zabiegający o zmianę status quo w swojej organizacji na pewno słyszał je więcej niż raz. Każdy trener uczący podstaw metod zwinnych również słyszy, że „to wszystko teoria, ale wiadomo, że nikt tak w praktyce nie pracuje”. Wiadomo? Skąd?

Najpopularniejsza metoda Agile, czyli Scrum, też jest od jakiegoś czasu pod ostrzałem jako framework zbyt idealistyczny, by dało się go użyć do czegoś więcej, niż rozwoju niewielkich produktów. Daje się słyszeć, że organizacje, które sięgnęły po Scrum, zawiodły się na nim. Zamiast spodziewanych korzyści biznesowych, są problemy z ukończeniem czegokolwiek w Sprintach i wydaje się, że Zespoły ciągle czegoś się domagają, a gdy to dostają, Scrum dalej nie działa i pojawiają się kolejne żądania…

Brak przy tym rzetelnych badań, które pozwoliłyby uzyskać w miarę obiektywny obraz sytuacji, nie mówiąc już o ustaleniu jej przyczyn. Te zresztą mogą być różne w każdej organizacji, która dziś odwraca się od metod zwinnych, a jeszcze kilka lat temu inwestowała w ich wprowadzenie.

Jestem przekonany, że spadek zainteresowania Scrumem i ogólnie metodami Agile jest przejściowy, bo nic lepszego ich nie zastępuje. Obrazowo mówiąc, zaplątały się we własne sznurowadła i padły ofiarą wcześniejszej popularności. Zbyt wielu ludzi sięgało po takiego np. Scruma, nie mając nie tylko zrozumienia, jak działa to narzędzie, ale nawet ustalonego celu, jaki z jego pomocą chciało osiągnąć.

Poniżej opisuję różne scenariusze, które wiodą do przekonania, że tak Scrum, jak i cały Agile to teoria, która nie działa. Przekonania z gruntu błędnego, bo w każdym z nich to decyzje podejmowane przez ludzi zatrudnionych w organizacjach prowadzą do porażki. Metody zwinne, jak każde narzędzie, są skuteczne tylko we wprawnych rękach.

Scenariusz 1: wiemy lepiej, jak to zrobić

Najbardziej oczywisty przypadek to ten, gdy organizacja celowo modyfikuje zasady lub elementy stosowanej metody w przekonaniu, że dokonuje w ten sposób jej usprawnień.

Niezależnie od intencji, jest to postępowanie aroganckie, bo jakie jest prawdopodobieństwo, że narzędzie użyte wcześniej przez tysiące Zespołów, ewoluujące przez kilkadziesiąt lat, poprawić z dnia na dzień może ktoś, kto dopiero zaczyna z niego korzystać?

Z reguły kończy się to pełnym dysfunkcji sposobem pracy, który zachowuje jedynie pozory podobieństwa do metody, którą był początkowo inspirowany.

Samo odejście od ustandaryzowanej metody na rzecz własnego podejścia ma oczywiście sens, ale dopiero wtedy, gdy Zespół (lub organizacja) potrafi tę metodę wykorzystać do maksimum. Jak bowiem zrozumieć dobrze ograniczenia narzędzia (o ile one istnieją), jeśli się go nigdy nie użyło poprawnie?

Scenariusz 2: jesteśmy wyjątkowi

Jedną z motywacji do wprowadzania zmian i robienia rzeczy po swojemu podczas korzystania ze zdefiniowanych metod jest przekonanie o wyjątkowym charakterze pracy wykonywanej w jakiejś organizacji. Ta wyjątkowość ma rzekomo czynić niektóre zasady i elementy metod zbędnymi lub niemożliwymi do zastosowania.

Źródłem wspomnianej wyjątkowości jest najczęściej rozmiar (skala) rozwijanego produktu albo wysoki stopień jego skomplikowania technologicznego. Zdarza się jednak, że chodzi głównie o pokrętną strukturę organizacji i sposób zarządzania jej pracownikami.

W równym stopniu bawi mnie to i smuci zarazem. Bawi, bo ciągle słyszę te deklaracje o wyjątkowości, a potem, gdy poznaję więcej szczegółów, nie dostrzegam niczego, z czym nie zetknąłem się już wielokrotnie wcześniej (no, ale wiadomo: „nie rozumiesz, Rafale, jak u nas jest”). Smuci, bo przekonania takie są murem, który bardzo trudno skruszyć, a jednocześnie stanowią dobrą wymówkę, by uniknąć zmiany status quo i zamiast tego trzymać się go jako jedynego możliwego sposobu pracy.

Scenariusz 3: zmiany, które niczego nie zmieniają

Kolejna droga do rozczarowania to generowanie pozornych zmian, np. użycie innego nazewnictwa na istniejące wcześniej elementy procesu i role w nim. Najczęściej dzieje się tak wtedy, gdy z jakiegoś powodu organizacja chce przylepić sobie łatkę „jesteśmy Agile!”, ale nawet nie ma pojęcia, z czym to się wiąże. Lub wie i ocenia, że z jakiegoś powodu nie warto uzyskać nic więcej, poza pozorami zwinności.

Zjawisko takie można było zaobserwować w dużej liczbie firm, które pospiesznie dołączały do rosnącej fali popularności podejścia zwinnego kilka lat temu. Niemal wszyscy wtedy „transformowali się ku zwinności”, a wiele z tych inicjatyw z Agile miało tyle samo wspólnego, ile ma szpadel.

Ten scenariusz realizuje się też zwykle tam, gdzie opór ludzi przed zmianą jest duży, np. ze względu na obawy o utratę pozycji zawodowej, wpływów, władzy albo i pracy.

Efektem pozorowania pracy zwinnej jest marnowanie potencjału osób, które mogą doprowadzić do wymiernych usprawnień i tym samym korzyści, ale nikt ich w tym nie wspiera (w najlepszym razie) lub wręcz ich wysiłki bywają torpedowane.

Scenariusz 4: projekt uzyskiwania zwinności

A skoro o „transformacjach zwinnych” mowa, to niejedna zakończyła się katastrofą, bo została zrealizowana na modłę czysto projektową: opracowano plan, wyznaczono termin „stania się zwinnym” i maszyna ruszyła, mieląc po drodze wszystkich opornych.

Tymczasem uzyskanie zwinności biznesowej to rzecz skrajnie złożona, opierająca się o granice chaosu. Na wszelki wypadek wyjaśniam, że przez zwinność biznesową rozumiem zdolność organizacji do użycia empiryzmu, aby wywierać pożądany wpływ na środowisko, w którym organizacja ta działa (np. uzyskać lepszą pozycję na rynku lub wyprzedzić w czymś konkurencję).

Inaczej mówiąc, nikt nie jest w stanie trafnie zdefiniować docelowego stanu organizacji zwinnej (o ile coś takiego w ogóle istnieje) z dużym wyprzedzeniem, nie mówiąc już o sporządzeniu planu jego osiągnięcia. A jeśli spróbuje i będzie się go trzymał, niemal na pewno zada swej organizacji serię ciosów, być może śmiertelnych. Dlatego ten proces też wymaga inkrementalnego i iteracyjnego podejścia oraz empirycznej kontroli (a więc musi być zwinny).

Scenariusz 5: rewolucja Agile

Warto przy tej okazji wspomnieć o kolejnym przepisie na porażkę, jakim jest próba stania się zwinnym raz-a-dobrze. Najczęściej podejście to opiera się o wybranie jakiegoś „modelu”, zaplanowanie sposobu jego implementacji w możliwie krótkim czasie i wdrożenie tych planów w życie.

To oczywiście nie może się udać, nawet jeśli mówimy o niewielkiej firmie, w której pracuje jeden Zespół. Wszystkie „modele” mają to do siebie, że opisują w wyidealizowany lub uproszczony sposób coś, co zadziałało gdzieś indziej. Aby organizacja uzyskała zwinność, może się nimi inspirować, ale i tak musi poszukać własnej drogi.

Ten scenariusz jest skrajnym przypadkiem scenariusza poprzedniego. Prowadzi najczęściej do zdemolowania w organizacji tego, co działało wcześniej i zastąpienia wszystkiego albo chaosem, albo pozorami zwinności. Wymiernych korzyści raczej nie należy się spodziewać i bynajmniej nie jest to dowód na to, że „Agile nie działa”.

Scenariusz 6: brak celu użycia metod zwinnych

Kolejna droga donikąd zaczyna się od sięgnięcia po metody zwinne przez organizacje, które skupiają się na utrzymywaniu w działaniu różnych procesów, ale nie potrafią określić, co też dzięki zwinności zamierzają osiągnąć lub nie informują o tym Zespołów.

Zdarza się też, że celem jest samo „stanie się zwinnym”, ale brak wskazówki, co to znaczy w kontekście konkretnej organizacji. Nie brak też firm, które co prawda określają jakiś cel, ale jest on tak ogólny, że i tak nie wiadomo, co właściwie oznacza.

Sprowadzenie wszystkiego do haseł w rodzaju „musimy zwiększyć efektywność” albo „trzeba zwiększyć tempo dostarczania rozwiązań” też nie rozwiązuje problemu. Kryje się w tym niedopowiedziane zwykle (choć zdarza się, że artykułowane bardzo dosadnie) oskarżenie Zespołów o to, że marnują możliwości i środki oraz pracują za wolno.

Przekłada się to na próbę zwiększenia tempa przebiegu procesu bez jego istotnego usprawnienia, nierzadko stanowi negatywną motywację dla Zespołów, a bardzo często wśród kadry zarządzającej nie ma nawet chęci sprawdzenia, czy aby ich sposób podejmowania decyzji również nie wymaga zmiany.

Poza tym brak jasnego celu i niekoniecznie dobry sposób motywowania ludzi utrudniają samozarządzanie w Zespołach, co skutecznie upośledza działanie każdej z popularnych metod zwinnych. Opierają się one przecież na idei działania autonomicznych agentów zdolnych do szybkiego podejmowania decyzji i tym samym niezwłocznego reagowania na zmieniającą się sytuację. A nie da się samodzielnie podejmować decyzji, jeśli nie rozumie się, do czego dąży organizacja (przyjmując litościwie, że ona sama to wie).

Scenariusz 7: brak kryterium sukcesu

Równie szkodliwa, jak brak jasnego celu użycie metod zwinnych jest niemożność ustalenia, czy coś one organizacji dają. W wielu organizacjach nie mierzy się niczego poza kosztami i zyskami operacyjnymi, co skutecznie uniemożliwia przeprowadzenie zmian będących inwestycją na przyszłość, a nie czymś, co da się przełożyć na pieniądze w krótkim czasie. Gdzie indziej zbiera się mnóstwo miar bez przemyślenia, czy są one w ogóle adekwatne do procesów, jakie opisują i co wynika z wartości poszczególnych wskaźników.

Z ustaleniem kryterium sukcesu jest też ten problem, że sukces nigdy nie jest stanem stabilnym, który raz osiągnięty da się utrzymywać. Coś, co jest korzystne dziś, za miesiąc może być stanem alarmowym, jeśli nie krytycznym. Dlatego nieporozumieniem jest ustanawianie pożądanych wskazań różnych miar i oczekiwanie, że Zespoły doprowadzą do ich uzyskania. Skoro rzeczywistość jest zmienna, podążać za nią muszą również kryteria sukcesu, który osiągany jest często i zawsze tylko na chwilę.

Niestety organizacje lubują się w ustanawianiu różnych targetów do osiągnięcia, najczęściej niezrozumiałych dla Zespołów i niezmiennych przez dłuższy czas. Prowadzi to do różnych lokalnych optymalizacji albo wręcz kierowania procesów na manowce. Na koniec okazuje się nierzadko, że target został osiągnięty, a jest równie źle, o ile nie gorzej niż wcześniej. I wtedy pada rzecz jasna stwierdzenie, że Agile nie działa.

Scenariusz 8: więcej, szybciej, taniej!

A skoro mowa o celach i kryteriach sukcesu, to kolejny przepis na katastrofę wiąże się z oczekiwaniem, że dzięki Agile organizacja zdoła uzyskać wszystko to, co robiła do tej pory, w krótszym czasie, w większej ilości i po niższej cenie. Inaczej mówiąc, oczekują one od metod zwinnych, że pomogą wydusić z Zespołów i zainwestowanych środków więcej.

Problem w tym, że Agile nie jest sztuką robienia szybciej tego samego co zawsze, ale sztuką uzyskiwania maksimum wartości poprzez zaniechanie robienia rzeczy niepotrzebnych. Nie da się uzyskać korzyści z metod zwinnych, jeśli nie jest się gotowym ani zdolnym do bardzo krytycznego wybierania tego, co będzie realizowane.

Świadomie użyte podejście zwinne da efekt taki, że więcej wartości wykreowane zostanie szybciej i w niższej cenie, ale nie dlatego, że tempo prac wzrośnie, tylko dlatego, że większość rzeczy nie zostanie w ogóle podjęta do realizacji (bo nie warto na nie tracić czasu).

Jest to jednak coś, z czym bardzo ciężko przebić się w organizacjach. Zamiast lepiej wybierać, co warto robić, wolą one inwestować w kolejne Zespoły, a potem sięgać po tzw. metody skalowania Agile, by jakoś zorganizować pracę nad ciągle rozrastającą się stertą tematów oczekujących na realizację. Po czym, gdy już dojdą do granic absurdu, wyciągają błędny wniosek, że to Agile jest przyczyną klęski.

Scenariusz 9: Agile – sposób organizacji pracy Zespołów

Podobnym nieporozumieniem jest uznanie metod zwinnych wyłącznie za jakiś nowy sposób zarządzania pracą ludzi. Ot, bierzemy zasady, „wdrażamy” je w Zespołach i będzie zwinność. Prowadzi to do ograniczenia zmian do poziomu Zespołów i ewentualnego dopasowania do nich wszystkiego, co funkcjonuje na wyższych poziomach, ale tak, by za wiele się nie zmieniło.

Efekt: Zespoły być może w inny sposób, niż wcześniej, realizują to, co zleca im kierownictwo. To, że są mniej lub bardziej zwinne w obszarze, na który mają realny wpływ, nie czyni całej organizacji zwinną.

Metody zwinne są narzędziem ograniczania ryzyka biznesowego polegającego na zbyt długim inwestowaniu w coś, co nie przynosi korzyści. Nie da się tego efektu uzyskać, jeśli organizacja nie zastosuje podejścia opartego o empiryzm na wszystkich poziomach, na których podejmowane są decyzje odnośnie do tego, co robić, a czego nie robić.

W przypadku porażki biznesowej pada zarzut, że mimo „wdrożenia metod zwinnych” jak nie udawało się nadążyć za potrzebami interesariuszy, tak nadal jest z tym kłopot, bo Zespoły nie zaczęły pracować efektywniej…

Scenariusz 10: projekty, a nie produkty lub strumienie wartości

Mnóstwo organizacji, które posługują się metodami zwinnymi do rozwoju produktów, traktuje wszystkie takie inicjatywy jako projekty biznesowe. Oznacza to, że sposób zarządzania nimi, kontrolowania, nierzadko struktura organizacyjna i wszystko inne podporządkowane jest myśleniu w kategoriach projektów, a nie produktów.

I tu pojawia się potężny problem, bo projekt jest inicjatywą tymczasową, która dąży do osiągnięcia zdefiniowanych celów przy zachowaniu różnych warunków, najczęściej związanych z czasem trwania i budżetem przedsięwzięcia. Tymczasem metody zwinne opierają się o ideę rozwoju czegoś (np. produktu), dopóki istnieje potrzeba dokonania w tym czymś kolejnej zmiany i jest ona opłacalna.

Jeśli organizacja nie będzie w stanie przestawić się na myślenie w kategoriach produktowych i strumieni wartości, zastosowanie podejścia Agile będzie w nich co najmniej trudne, o ile nie niemożliwe. Wiele z opisywanych przeze mnie scenariuszy ma swoją genezę w myśleniu wyłącznie o projektach, np. prowadzi ono do stosowania miar typowo projektowych, przywiązywania większej wagi do terminowości niż do generowanej wartości itd.

Scenariusz 11: zacementowana kultura organizacji

Zwinność wymaga gotowości do zmiany, bo w istocie jest zdolnością do szybkiego reagowania na zmienną rzeczywistość. Przy czym często nie wiadomo, co będzie dobrym rozwiązaniem w zaistniałej sytuacji i jeśli nie chce się grzęznąć w długotrwałych rozważaniach i analizach bez gwarancji, że dadzą one trafne wskazówki, trzeba eksperymentować.

Gotowość do wprowadzania zmian i eksperymentowania wymaga przyzwolenia na popełnianie błędów (bo te są nieuchronne) oraz wyciągania z nich wniosków (uczenia się). A zarówno to przyzwolenie, jak i uczenie się opierają się na zaufaniu. Kierownictwo musi ufać, że Zespoły działają na jej korzyść, bo inaczej zacznie ludzi karać za błędy popełnione w dobrych intencjach, co skutecznie zniechęci wszystkich do eksperymentowania. Zespoły muszą ufać, że ujawniając problemy, uzyskają wsparcie w ich rozwiązaniu, a nie reprymendę i oskarżenie o nieefektywność lub brak kompetencji.

Tymczasem w wielu organizacjach, które przeprowadziły „transformację do Agile”, zmieniło się wiele, ale niekoniecznie wewnętrzna kultura. A jeśli się zmieniła, to nie zawsze w korzystny sposób. Nie brakuje miejsc, gdzie wprowadzono np. Scrum siłą do Zespołów, nie pytając ich nawet o zdanie ani nie zapewniając wystarczającej wiedzy i wsparcia, po czym, gdy zakończyło się to jakimś kulawym pseudo-Scrumem, który generuje więcej problemów niż wymiernych korzyści, o skutki oskarżono po równo samą metodę, jak i Zespoły.

Scenariusz 12: stała struktura organizacji i produktów

Skoro wspomniałem o zacementowanej kulturze, to równie skuteczna w upośledzaniu zwinności jest niemożliwa do zmiany struktura Zespołów i całej organizacji oraz jej produktów. I mam tu na myśli dwie różne sytuacje, skutkujące jednak podobnymi problemami.

Jedna sytuacja to tłoczenie metod zwinnych do Zespołów, które w miernym stopniu lub w ogóle nie są przygotowane do pracy w ten sposób, bo powstawały na potrzeby projektów albo grupowały specjalistów o jednej kompetencji i brak im wielu innych, żeby sobie poradzić samodzielnie.

Przy czym nierzadko te Zespoły muszą pracować z produktami zdefiniowanymi w ten sposób, że nieustannie pojawiają się zależności między nimi, albo wszyscy grzebać muszą w tych samych rozwiązaniach, wchodząc sobie w drogę.

Druga sytuacja to zaprojektowanie z góry „docelowego” stanu organizacji i pospieszne dokonanie zmian, by go uzyskać, a potem w nim już tylko trwać. O ile przez jakiś czas (przy odrobinie szczęścia) struktura Zespołów będzie względnie dopasowana do tego, co mają robić, bardzo szybko pojawiać się zaczną takie same problemy, jakie wystąpiłyby, gdyby nie zmieniono nic. Przy czym ta rewolucja organizacyjna często rozwala po drodze to, co działało, nie zastępując tego niczym efektywnym, więc jest jeszcze gorzej, niż mogłoby być…

W obu sytuacjach Zespoły staną przed problemem: jak robić coś z sensem, skoro nie da się zmienić tego, co nieustannie utrudnia im wszystkim pracę. Zwinność wymaga od organizacji gotowości nie tylko do zmiany tego, co będą realizować jej Zespoły, ale też definicji produktów i samej struktury organizacyjnej, gdy jasne staje się, że przestała być adekwatna do potrzeb.

Scenariusz 13: „nauczymy się wszystkiego w trakcie”

W wielu miejscach metody zwinne zostały wprowadzone ukazowo: szefostwo kazało je zastosować i Zespoły mają sobie jakoś poradzić. O ile poświęcono w ogóle jakiś czas na przygotowanie do takiej zmiany i dostarczenie choćby podstawowej wiedzy, zwykle było go za mało. Ludzie mają w praktyce sami nauczyć się, jak pracować zwinnie, przy czym jedynie przez jakiś czas obowiązuje taryfa ulgowa i szybko zaczyna się twarde rozliczanie z efektów.

Jaką zwinność można tak uzyskać? Najczęściej są to jedynie pozory, a tam, gdzie nie brak osób odnoszących się wrogo do Agile, pojawią się możliwości wykorzystania wszelkich problemów do udowadniania, że „Agile nie działa”. Tymczasem metody zwinne, choć proste, są w istocie trudne do zastosowania, bo wymagają usunięcia wielu deficytów organizacji, nim zaczną przynosić naprawdę duże korzyści.

Pewnym wariantem tego podejścia jest nakazanie ludziom, by pracowali w jakiejś metodzie, bo to ma jakoby pozwolić im szybko ją poznać. W miarę jak coraz lepiej rozumieją, co robią, będą działać efektywniej, a być może z czasem będą gotowi na to, by pozwolić im na ewentualną zmianę metody na inną, tym razem wybraną samodzielnie.

Wszystko to brzmi pięknie, ale opiera się o wątpliwe założenie, że nawet nie wiedząc, o co chodzi w używanej metodzie, do tego narzuconej siłą, Zespoły będą używać jej na tyle poprawnie, że zaczną dostrzegać w niej sens i wartość. Kto ma to spowodować? Wtłoczeni do Zespołów ludzie, którzy będą im „robić Agile”? A nawet jeśli, skąd wziąć takie osoby w organizacji, która doświadczenia z metodami zwinnymi nie ma?

Oczywiście to może zadziałać, ale nie musi. Moim zdaniem jest spora szansa, że efektem będzie wygenerowanie wtrętu do Agile u osób, którym go narzucono. Jest to też dobry sposób na zbudowanie przekonania u ludzi, którzy pracowali np. w jakimś patologicznym pseudo-Scrumie, że to, z czym się zetknęli, to właśnie Scrum. I idą potem do innych organizacji, wlokąc za sobą zarazę nieporozumień i uprzedzeń…

Scenariusz 14: zwinność oparta o konsultantów

A dlaczego ludzie mają się uczyć i przygotowywać do użycia metod zwinnych, skoro można zatrudnić specjalistów, którzy się na tym znają i powiedzą, jak to wszystko działa?

Wiele organizacji wyszło z tego założenia i rozpoczęło „transformację zwinną”, która opierała się w znacznym stopniu albo i całkowicie na zewnętrznych ekspertach i firmach konsultingowych. Samo doradztwo jest oczywiście wartościowe, ale ciężko mówić o doradzaniu, jeśli to konsultanci w praktyce podejmują kluczowe decyzje. W ten sposób nikt się niczego nie uczy, tak jak nie da się nauczyć jazdy na rowerze, wyłącznie obserwując mistrza kolarskiego – trzeba samemu wskoczyć na siodełko.

Biznes doradztwa w zakresie Agile kwitł, póki panowała moda na zwinność. Moda się skończyła, więc nierzadko te same firmy teraz doradzają, jak wycofać się z Agile na rzecz czegoś innego lub wrócić do klasycznych metod zarządzania projektami.

Czy to Agile nie zadziałał? Nie, to kierownictwo organizacji na różnych poziomach abdykowało ze swej odpowiedzialności, licząc na to, że ktoś im uzwinni firmę. Gdy brakło wsparcia albo gdy uznali, że dalej sami sobie poradzą, doszło do szybkiego regresu, bo odeszły osoby, które napędzały proces transformacji.

Scenariusz 15: kult cargo

Można oczywiście w kopiowaniu gotowych rozwiązań iść jeszcze dalej, czyli próbować wdrożyć na siłę w organizację to, co zadziałało gdzieś indziej, z minimalnymi tylko zmianami.

Tu też z gotowymi strategiami pędzą firmy doradcze, które „wiedzą”, co będzie dobre i jak to wdrożyć w życie, bo już to zrobiły w dziesiątkach innych firm. Ta strategia przypomina trochę piramidę finansową: w końcu zaczyna być widać, że to nie działa. I nie chodzi mi o Agile, tylko o takie bezmyślne kopiowanie gotowych recept w nadziei, że „nam też dadzą korzyści”.

Tych korzyści prawie na pewno nie będzie, aczkolwiek kopiowanie zadziała – tego nie będę negował: podobnie jak poprzednie ofiary tego procederu, każda kolejna organizacja w najlepszym razie zmarnuje czas i pieniądze na wygenerowanie zamieszania, z którego nic pozytywnego nie będzie wynikać. A przy odrobinie pecha podważy podstawy swej egzystencji.

Scenariusz 16: użycie niewłaściwych metod

W połączeniu z wieloma wcześniej opisanymi scenariuszami, ale również zupełnie niezależnie, zdarza się organizacjom sięgać po metody kompletnie niedopasowane do tego, co próbują za ich pomocą osiągnąć. Albo nieprzystające do środowiska, w którym działają Zespoły, a którego żadną miarą nie da się zmienić, bo organizacja nie ma na niego wpływu.

Klasycznym przykładem tego jest sięgnięcie po Scrum przy wykonywaniu prac innych niż rozwój produktów i usług, podczas gdy jest to metoda produktowa i miernie nadaje się do inicjatyw o innym charakterze (pisałem o tym jakiś czas temu).

Skutki muszą być opłakane, bo Zespoły borykają się z procesem, który utrudnia im pracę, zamiast ją ułatwiać. W najlepszym razie wytworzą one wolniej i drożej to, co przynosi korzyści organizacji, a często nie dostarczą niczego wartościowego. Nie mówiąc już o degradacji Zespołów, które w takiej sytuacji będą bardziej sfrustrowane, niż zmotywowane do działania.

Scenariusz 17: „Agile powoduje problemy”

Metody zwinne mają duży potencjał ujawniania problemów, które istnieją w organizacji, ale niekoniecznie są widoczne i łatwe do zidentyfikowania.

Nie jest więc niczym niezwykłym, że Zespoły, które uznawane były za wyjątkowo sprawne i efektywne w pracy nad projektami, po zastosowaniu np. Scruma mają kłopoty z ukończeniem czegokolwiek w trakcie pojedynczego krótkiego Sprintu.

A przecież Zespoły te próbują w krótkim czasie zrealizować coś naprawdę gotowego do użycia i w pełni ukończonego, a nie tylko wykonać w terminie jakąś część planu. I nagle okazuje się, że to niemożliwe, bo procesy decyzyjne są rozwlekłe, bo brak niezbędnych narzędzi, bo nie sposób doprosić się kluczowych informacji itd.

To nie metoda zwinna (w tym przykładzie Scrum) powoduje te problemy, lecz środowisko, w jakim jest użyta. A mimo to ich wystąpienie bywa użyte jako argument przeciwko Agile.

Scenariusz 18: oczekiwanie na szybkie efekty

Żadna z metod zwinnych nie zakłada istnienia warunków idealnych do jej zastosowania. Ba, w ogóle żadne warunki nie są potrzebne, bo cała idea pracy zwinnej sprowadza się do udoskonalania stanu spraw tak, by zwiększać skuteczność Zespołów iteracja po iteracji.

Wspomniana wcześniej zdolność do ujawniania deficytów organizacji, Zespołów, procesów, narzędzi itd. właśnie po to się przydaje: jeśli widać, że coś utrudnia skuteczne działanie, można pomyśleć o tym, jak to zmienić. Nie wszystko naraz, nie z dnia na dzień.

Niestety w wielu firmach panuje przekonanie, że metody zwinne powinny dać efekty od razu, najlepiej już po pierwszej krótkiej iteracji. I to nie efekty jakiekolwiek, ale takie, jakby organizacja i jej Zespoły już były w pełni zwinne i zdolne do maksymalnego wykorzystania potencjału stosowanych metod.

Przy czym to przekonanie niekoniecznie pojawia się od razu, bo z początku wszyscy mają świadomość, że trzeba czasu na nauczenie się postępowania w nowy sposób. Tyle że bardzo szybko cierpliwość się kończy i zaczyna się presja, pretensje o to, że efektów zwinności nie widać itd.

A za tym idzie szybko próba „poprawienia” metod albo podkręcania tempa prac. Lub dochodzi do regresu, bo ludzie zaczynają wycofywać się z podejścia zwinnego, które uznali za nieskuteczne.

Scenariusz 19: brak liderów

Uzyskanie zwinności biznesowej, a więc umiejętności wykorzystania empiryzmu do osiągania celów całej organizacji, wymaga zaangażowania wszystkich jej poziomów, a nie tylko Zespołów, o czym już wcześniej pisałem.

A że nauczenie się, jak korzystać z metod zwinnych i usunięcie utrudnień, na które natrafiają Zespoły, zabiera sporo czasu, dość często zdarza się, że inicjująca transformację organizacji kadra kierownicza przestaje dbać o to, by proces ten się nie zatrzymał. W skrajnych przypadkach to wycofanie się następuje tuż po szumnym ogłoszeniu rozpoczęcia transformacji, co jest czytelnym sygnałem, że kierownictwu mało na niej zależy.

Brak zainteresowania szefostwa przekłada się na erozję przywództwa na niższych poziomach i to samo dotyczy procesu przyswajania podejścia Agile. Z czasem zatrzyma się on, a potem zacznie się regres w poczuciu, że „to od początku było niepotrzebne zamieszanie”.

Scenariuszy 20: brak kompetencji i narzędzi

Bardzo prostym i niestety stosunkowo częstym sposobem na ograniczenie lub zredukowanie do zera szansy na uzyskanie korzyści z użycia metod zwinnych jest pozbawienie Zespołów niezbędnych środków do działania.

Równie destrukcyjny będzie brak kompetencji, rozumiany dwojako: albo jako zbyt niski poziom umiejętności ludzi tworzących Zespoły, albo pozbawienie ich prawa do samodzielnego decydowania o czymkolwiek.

Aby osiągnąć zwinność, organizacja musi inwestować w rozwój Zespołów i zapewnić im to, czego potrzebują one tak do pracy, jak i do poszerzania swych kompetencji. A w wielu miejscach tak się nie dzieje, bo na naukę brak czasu, a popełnianie błędów (będące częścią procesu uczenia) jest karane. Skutkiem tego bywa kurczowe trzymanie się przez członków Zespołu tego, na czym się znają, nie ma więc prawdziwej wspólnoty pracy, synergii kompetencji – są za to silosy i konflikty o to, kto jest winny, jeśli coś pójdzie nie tak.

Oczywiście organizacja ma prawo rozliczać Zespoły z efektów i stawiać różne oczekiwania. Ważne, by zapewniała warunki do ich spełnienia. Formułowanie nierealnych wymogów i późniejsze twierdzenie, że metoda zwinna stosowana w takich warunkach „nie działa”, nie ma sensu.

Pseudo-Agile

Skoro dobrze użyte metody zwinne mogą być oskarżane o powodowanie problemów, które jedynie ujawniają, to co powiedzieć o Agile użytym niepoprawnie, bez zrozumienia?

Właściwie każdy z opisanych przeze mnie scenariuszy może prowadzić do sklejenia nazwy Agile z czymś, co jest jedynie jego karykaturą. Potem nie braknie osób, które z pełnym przekonaniem będą twierdzić, że spróbowali pracy zwinnej i okazało się to złym pomysłem. Zjawisko to istnieje od lat, szyderczo pisał o nim w 2006 Ron Jeffries w artykule We Tried Baseball and It Didn’t Work (zachęcam do lektury, przy czym jest to tekst w języku angielskim).

Można śmiało powiedzieć, że największym wrogiem zwinności i przyczyną spadku zainteresowania nim, a także źródłem argumentów dla osób chcących go obrzucać błotem, jest właśnie źle użyty Agile. Nie dowodzi to, że „Agile nie działa”, ale potwierdza naprawdę oczywistą rzecz: źle użyte narzędzie nie przyniesie spodziewanych korzyści.

Agile to tylko teoria?

Jeśli gdzieś Agile nie działa, to znaczy, że jest źle stosowany – nie ma powodu, by owijać to w bawełnę. Ta niepoprawność użycia może wynikać z niewiedzy, niemożności zmiany skrajnie niekorzystnego status quo, braku chęci do zrobienia czegokolwiek sensownego albo wielu innych czynników.

Natomiast sam Agile, czyli idea zastosowania empiryzmu do kontrolowania procesu wytwarzania czegoś wartościowego, nie może nie działać. Dlaczego? Pozwolę sobie na analizę konsekwencji tego, gdyby faktycznie Agile mógł działać tylko w niektórych sytuacjach.

Oznaczałoby to, że empiryzm również nie wszędzie będzie działał i to z przyczyn obiektywnych, a nie ze względu na nieumiejętność lub niechęć ludzi, by się nim posłużyć. Żeby empiryzm nie działał, musiałyby istnieć warunki, w których podejmowanie decyzji na podstawie faktów i danych opisujących prawdziwy stan spraw jest niekorzystne. Idąc za ciosem, musiałyby więc istnieć takie sytuacje, w których nieprawdziwa informacja jest czymś pożądanym i pozwala podejmować najlepsze decyzje. A to przecież nie ma żadnego sensu.

Empiryczna kontrola jest czymś bardzo naturalnym dla każdego człowieka – nieustannie reagujemy na otoczenie, bo po to wyposażeni zostaliśmy w zestaw zmysłów. Nie posługujemy się sztywnymi algorytmami i nie realizujemy bezmyślnie planów, gdy wiemy, że są nietrafione. Niestety ta nasza wrodzona umiejętność nie przenosi się bezpośrednio na funkcjonowanie organizacji, w których pracujemy, dlatego niezbędne jest kształtowanie tak jej struktury, jak i kultury, by umożliwić umiejętności tej wykorzystanie.

Wracając do oskarżenia, że Agile to piękna teoria oderwana od realiów: czy jest coś bardziej pragmatycznego od ustalenia, co naprawdę się dzieje i podjęcia działań, które mają na celu poprawę bieżącego stanu spraw? A przecież na tym właśnie polega empiryzm: sprawdzamy, jak jest teraz, a jeśli odbiega to od naszych aktualnych oczekiwań, robimy coś, by je spełnić, po czym dokonujemy sprawdzenia raz jeszcze – dopóty, dopóki uznajemy, że warto to robić.

Sądzę, że wiele z opinii o tym, jak to Agile „nie działa” i „jest teorią” wynika z braku zrozumienia, czym jest empiryzm, ale też z obaw przed tym, co ujawni doprowadzenie do niezbędnej przejrzystości. Bo przecież wtedy będzie widać, że trzeba coś zrobić, a to może być trudne, może się nie udać, wymaga wzięcia na siebie odpowiedzialności.