„Nie rozumiesz Agile!”

Data: 2017-07-18
Autor: Sebastian Konkol
„Nie rozumiesz Agile!”

Jestem absolutnym fanem zwinnego (ang. Agile) podejścia do realizacji przedsięwzięć niestandardowych, często nazywanych projektami. Przez LinkedIn przetoczyła się niedawno fala artykułów, że agile nie działa i nigdy nie działał. W swojej praktyce spotykam się także ze sformułowaniami, że ci lub tamci nie rozumieją, co to jest agile. Cóż takiego jest w tym agile, że budzi takie kontrowersje?

Chyba nie można zrobić nic sensowniejszego, niż wyjść od Agile Manifesto. Cała reszta metod pracy to jedynie unarzędziawianie i interpretacje podstawowych tez ruchu agile. Moje poszukiwania nie kierują się jednak w stronę doszczegóławiania tego, co zostało zapisane w manifeście, ale w kierunku założeń dla stosowania takich metod. W mojej ocenie w treści manifestu zapisano kilka takich fundamentalnych założeń:

  • “Individuals and interactions over processes and tools”. Procesy i narzędzia zostały wymyślone dlatego, że nie ludzie są omylni i z natury leniwi. Postawienie na ludzi i interakcje w miejsce procesów i narzędzi oznacza nawrót do humanizacji. W konsekwencji musimy jednak pamiętać, że ludzie – nawet działając w dobrej wierze, ale subiektywnie oceniając sytuacje – popełniają błędy, także błędy zaniechania. Agile wymaga wyrozumiałości dla popełniania błędów, ale także uczciwości w relacjach z ludźmi, nawet stojącymi „z drugiej strony barykady”. Stawiać na ludzi – nic trudniejszego…
  • “Working software over comprehensive documentation”. Dokumentacja ma służyć zrozumieniu i jednoznaczności. Tak długo, jak wspólne i bezsprzeczne zrozumienie – wymagań, uwarunkowań, podejmowanych decyzji – jest utrzymywane, tak długo dokumentacja jest rzeczą wtórną. Nie jest to jednak stan stały, bo nieudokumentowane zrozumienie odchodzi razem z ludźmi i jest poddawane erozji z upływem czasu. To, że zespół – w ramach jednego projektu – doskonale się rozumie nie oznacza, że inny zespół, w ramach innego projektu, będzie dysponował tym samym zrozumieniem. Homo Sapiens nie mają takiej zdolności – wiedzę muszą z czegoś czerpać. Nad dokumentacją można pracować stopniowo i „na końcu”, ale odpowiedzialność nakazuje pozostawienie jej po własnych pracach – bo nasi następcy muszą się z czegoś uczyć o tym, czego my dokonaliśmy. Gorzej, jeśli „nagębizm” stosowany jest świadomie dla rozmycia odpowiedzialności…
  • “Customer collaboration over contract negotiation”. Znajomy prawnik powtarza, że umowy nie są na łatwe czasy – są na takie sytuacje, w których relacje się psują. Jeśli mamy pewność, że współpraca będzie odzwierciedlać zawsze relacje partnerskie, umowy można olać. Z mojego doświadczenia to jednak sytuacja tak samo realna, jak Opowieści z Narni. Umowa jest po to, aby ustalić uprawnienia i obowiązki stron, których interesy są obiektywnie sprzeczne. Współpraca między stronami – oczywiście – ale w zakresie, w którym jedna strona nie będzie ponosić konsekwencji błędów lub nieuczciwości działań drugiej strony…
  • “Responding to change over following a plan”. Prawdziwe projekty w realnym świecie niemalże nigdy nie są czysto software’owe. Oprogramowanie czemuś służy, jest częścią czegoś większego. Czy to otoczenie jest równie podatne na zmienność? Jeśli otoczenie jest dopasowanie, ma możliwość dostosowania do zmienności w takim samym zakresie, jak tworzenie oprogramowania, to luz. Zwykle jednak tak nie jest – otoczenie (legislacja, kampanie marketingowe, zobowiązania wobec innych podmiotów) nie jest tak wyrozumiałe. Podatność na zmiany jest dobra, ale nie wszystko jest tak samo na nie podatne, jak zwinne metody rozwoju oprogramowania…

Procesy, narzędzia, dokumentacja, kontrakty, realizacja planu – to są wszystko rzeczy, które niosą wartość. Realną wartość. Agile opiera się na pewnym wyważeniu powodów i ograniczeń stosowania podejścia z lewej i z prawej strony manifestu. Agile nie opiera się na porzuceniu prawej strony. Jednak stosowanie lewej strony „przepisu na sukces” wymaga respektowania założeń. Im mniej założeń może być spełnionych tym bardziej przesuwamy się na prawą stronę, ale to przesunięcie także jest elementem Agile (sic!). Jeśli ktoś tego nie dostrzega, to – rzeczywiście – nie rozumie prawdopodobnie najważniejszego zdania z całego manifestu: “That is, while there is value in the items on the right, we value the items on the left more.” Agile nie oznacza „brak prawej strony” – oznacza „mniej prawej strony”, ale dokładnie tyle, ile jest potrzebne. Co najważniejsze, nie bezwzględnie, lecz w odniesieniu do konkretnej sytuacji.

Na czym opiera się to wyważenie, będące absolutnym fundamentem zwinności? Zaufaniem! Raz popełniony błąd, do którego nikt się nie przyznał, albo – co częstsze – odpowiedzialność została przerzucona na „następnego w łańcuszku” i wzmacniamy stosowanie procesów. Jedna „dopuszczalna nadinterpretacja” minimalistycznej dokumentacji lub próba realizacji „własnej agendy” i zaczynamy się okopywać notatkami i dokumentami. Jedno „naciągnięcie” partnerskich relacji między zlecającym a realizującym oprogramowanie i bez mrugnięcia okiem łapiemy za kontrakt oraz telefon do prawnika. Jedno zderzenie z szefostwem („Dlaczego to jeszcze nie jest zrobione?!”) i atmosferę akceptacji zmienności diabli biorą. Każde z takich zdarzeń podważa zaufanie, a bez zaufania Agile nie ma szans. Żadnych. A przecież typowym środowiskiem kultury organizacyjnej każdej większej firmy (korporacji?) są przede wszystkim działania nadwątlania zaufania. Własne cele „monarchów” przekładają się na cele forsowane przez ich podwładnych. Są równi i równiejsi. W każdym projekcie następuje w końcu okres szukania winnych i karania niewinnych. Przykłady można mnożyć, ale nie w tym rzecz – rzecz w założeniach i ich respektowaniu. Rzecz w dopuszczalnej dawce zaufania, które łatwo stracić, ale trudno odzyskać.

Jak z każdą metodą, jej wykorzystanie wymaga respektowania jej fundamentów i założeń. Bez spełnienia fundamentów agile, stosowanie jej metod działania przynosi jedynie frustrację. Na braku fundamentów zaufania nie da się budować metod pracy jego wymagających. Agile stawia na ludzi i ujawnia, wywleka wszystkie ich słabości. Fundament dla Agile może zostać nadwątlony lub nawet unicestwiony w organizacji niezwykle łatwo – buduje się go latami, a zniszczyć można w czasie jednego spotkania. Nie wierzę w istnienie organizacji, w której istnieje niekwestionowany fundament zaufania. To jest prawdziwe założenie ruchu Agile i jednocześnie miara wykonalności – na ile zaufania i wiary w ludzi nas stać? Bo tylko o tyle możemy przesunąć się od prawej strony Agile Manifesto.

BTW, za podszeptem przyjaciela (dzięki, Tomku!) zagłębiłem się kiedyś w lekturę: Piotr Sztompka „Zaufanie. Fundament społeczeństwa”. To naprawdę zaskakujące, jak konstytutywnym pojęciem jest zaufanie. Kto chce zrozumieć siłę zaufania i tragedię konsekwencji jego braku, a nie czytał – lektura obowiązkowa.

Pozostaw komentarz