Blog

Kulty cargo są często używanym przykładem (metaforą?), więc nie będę poświęcał zbyt wiele miejsca na objaśnienie tego pojęcia. Potocznie opisuje ono sytuację, którą zaobserwowano m.in. wśród dzikich plemion na wysepkach Pacyfiku wkrótce po zakończeniu tam II wojny światowej. Podczas wojny na wyspach pojawili się Amerykanie, zbudowali lotniska i obsługiwali je. Przy okazji dawali tubylcom jedzenie i różne rzeczy. Po wojnie spakowali się i odlecieli, a wraz z nimi zniknęła żywność i inne rzeczy, które dawali tubylcom. Tubylcy zaczeli więc wykonywać zaobserwowane wcześniej u Amerykanów czynności (np. musztra, budowa pasów startowych z bambusowymi wieżami kontroli lotów itp.) w nadziei, że ich wykonywanie sprowadzi owe rzeczy (czyli cargo) z powrotem, czyniąc z owych czynności element swoich wierzeń.

Co to ma do Agile?

Nasunęła mi się refleksja kiedy wracałem pociągiem z kolejnej polskiej konferencji Agile (nb. charakterystyczną cechą polskich konferencji Agile jest to, że Polacy mówią na nich do Polaków po angielsku, zresztą zazwyczaj całkiem nieźle), że w praktyce ten Agile bardzo często funkcjonuje tak, jak owe kulty cargo. Rytualne spotkania codzienne na stojąco. Rytualne karteczki różnokolorowe przylepiane do ścian. Biura urządzone wzorem Google, niczym przedszkola dla dorosłych. W nich często różne obowiązkowe wygłupy pod przykrywką „grywalizacji”, Rytualny język z użyciem słów japońskich, które potrafią nadać rzeczom całkiem zwyczajnym posmak wzniosłej mądrości Wschodu. (Pewien prelegent opowiadał z przejęciem, jak to poprawiły się spotkania, od kiedy usunął z pokoju najpierw stół a potem krzesła, zmuszając uczestników do siedzenia na podłodze. Nazwał to „dojo”. Prawda że „dojo” brzmi zdecydowanie wznioślej niż „siądźmy na podłodze”?)

Wszystko to jest przyjmowaniem zewnętrznych znamion dobrych zespołów z wiodących firm  w nadziei, że staniemy się tacy jak oni. Że dzięki tym rytuałom magicznie będzie super. Niestety, najczęściej nie jest super. Nadal jakość kodu – a więc produktów – jest mierna. Nadal w większości firm króluje mikrozarządzanie oparte o “taski” rozdzialane przez kierownika (czasem nazwanego dla niepoznaki Scrum Masterem albo “lidem”). Nadal developerzy nie mają pojęcia po co budują daną funkcjonalność w produkcie, a często nawet jak kod, który im zlecono przekłada się na ową finalnie dostępną funkcjonalność. Za to w “dżirze” czy innym narzędziu muszą zarejestrować codziennie 8 godzin pracy. Retrospekcje to krótkie omówienie co się komu podobało a co nie (“plusy i minusy”), z czego rzadko wynikają jakieś wcielane w życie wnioski. Ale jest. W ogóle wszystkie role, wydarzenia, artefakty i zasady są na swoim miejscu. Tylko jakoś nie jest super, klienci nie są bardziej zadowoleni, wydania nie są częściej, błędów nie jest mniej, koszty utrzymania oprogramowania rosną a zaangażowanie ludzi spada. Zupełnie tak jak u dzikusów z wysp Pacyfiku – pas jest, wieża też jest i nawet antena na niej (z bambusa) tylko niestety samoloty z upragnionymi dobrami jakoś się nie zjawiają. Ale, podobnie jak oni, nie tracimy nadziei szykując kolejną porcję kolorowych karteczek.

Dzieje się tak dlatego, że wciąż brak jest powszechnego zrozumienia fundamentów i istoty Agile. Rutynowo pytam ludzi, z którymi stykam się jako coach czy trener o znajomość Agile Manifesto – jest ona zaskakująco niska, o empirycznej kontroli procesów i zwinności biznesowej mało kto słyszał. Tymczasem Agile to zastosowanie podejścia empirycznego do rozwoju produktów informatycznych z elementami myślenia lean w odniesieniu do procesów. Metody zarządzania (takie jak Scrum) i praktyki techniczne Agile służą temu, by empirycznie rozwijać produkty, a więc często sprawadzać założenia i dopasowywać produkty do realnych potrzeb odbiorców, co przekłada się na przewagę konkurencyjną. Przy okazji, również empirycznie, rozwija się zespoły poprzez stałe samodoskonalnie się ich w każdym obszarze pracy – zarówno technicznym jak i międzyludzkim. Wszystko to wymaga kultury zaufania i otwartości, w której stan produktu jest jawny i znany bez czego nie ma mowy o empiryźmie.

Dopiero kiedy te podstawy, fundamenty są znane i zrozumiane można dostrzec celowość praktyk, a zatem rozumieć po co je stosować (a także które stosować na danym etapie rozwoju itp.). I dopiero wtedy zaczynają one działać. Bez tego zaś zrozumienia same praktyki są równie skuteczne jak musztra na bosaka z bambusowym kijem zamiast karabinu uprawiana na wyspach Pacyfiku.

Dlatego właśnie od przybliżenia tematu empiryzmu jako podejścia oraz zawartości Manifestu Agile jako fundamentu Agile zaczynam zawsze pracę z firmami, którym pomagam w ich drodze ku większej efektywności jak i z tymi, z którymi mam okazję spotkać się przy okazji szkoleń. Nie chcę bowiem tworzyć kolejnych wyznawców bezpłodnego kultu cargo, a przeciwnie, kształcić świadomych użytkowników nowoczesnych metod budowania zespołów, organizacji i produktów.