Z Agile zetknąłem się równo dziesięć lat temu, w roku 2006. Taka okrągła rocznica to dobra okazja, żeby podzielić się tą historią.

Aby o tym opowiedzieć muszę się jednak cofnąć do roku 2005. Wtedy właśnie zostałem menedżerem w nieistniejącej już firmie Air Bites Polska. Firma ta utworzona przez Swisscom (szwajcarski odpowiednik TP S.A. z tą różnicą, że nadal kontrolowany przez państwo Helwetów) była nowym ISP oferującym tani, prosty dostęp do Internetu. Był to zasadniczo startup, a ja odpowiadałem tam za stworzenie pionu technicznego. Od zera. Obejmowało to budowanie i konserwację sieci, podłączanie nowych klientów, bieżące operowanie siecią – i rozliczenia. By nie przedłużać tej historii skupię się tylko na tym ostatnim elemencie, ponieważ system bilingowy pisaliśmy sobie sami, także od zera.

Zaczęło się to od zatrudnienia pierwszego programisty, Adama (zresztą świetnego gościa, który obecnie po paroletnim pobycie w Google i wzięciu udziału w rejsie żeglarskim dookoła świata kreuje technikę w pewnym londyńskim startupie), który położył podwaliny pod system. Powoli rekrutowałem kolejnych aż doszliśmy do zespołu liczącego 5 czy 6 osób (było to 10 lat temu, nie pamiętam już dokładnie) w skład którego poza programistami wchodziła także testerka która dbała również o dokumentację. Jak zespół ten pracował?

Ano, ponieważ miałem pełnię władzy nad obszarem techniki i dużo swobody (żadnych narzuconych procesów i standardów) zorganizowałem pracę w sposób, który był dla mnie najbardziej naturalny i normalny:

• prowadziłem w narzędziu zwanym OmniOutliner listę funkcjonalności, które powinny się w systemie znaleźć w najbliższym czasie,
• raz na miesiąc spotykałem się z zespołem i dyskutowaliśmy o tym co dodamy do systemu w tym miesiącu – lista była przy tych dyskusjach wyświetlana z rzutnika na ścianę i dynamicznie zmieniana/edytowana w razie potrzeby,
• potem zespół dyskutował jeszcze dodatkowo jak to zrobi, w późniejszym okresie przyklejali do ściany w swoim pokoju karteczki z zadaniami,
• z inicjatywy Adama zespół codziennie się spotykał i omawiał co będzie robił, mieli także uzgodnione standardy kodowania i testów, część testów – zwłaszcza API – była zautomatyzowana,
• na bieżąco był dostępny system testowy zasilany wprost z repozytorium (wtedy w nowoczesnym narzędziu pt. Subversion), gdzie często zaglądałem patrząc co się pozmieniało,
• pod koniec miesiąca spotykaliśmy się, zespół pokazywał co zrobił, po czym robiliśmy wydanie – i dzień po wydaniu proces się powtarzał.

Tak to działało, kiedy to pewnego dnia w 2006 roku Adam przyniósł mi tą książkę i powiedział, że koniecznie muszę ją przeczytać. Tak też zrobiłem i wtedy odkryłem, że to co robiliśmy w zasadzie ma nazwę – jest to mianowicie Scrum. Brakowało nam tak naprawdę trzech rzeczy:

• sztywnej długości sprintu (czasem wydawaliśmy wcześniej a czasem później o parę dni),
• formalnie określonego kryterium ukończenia (Definition of Done),
• retrospekcji.

Oczywiście natychmiast te elementy wprowadziliśmy i można powiedzieć, że od razu, bez wielkich bóli i problemów pracowaliśmy już w pełnym Scrumie. Dość szybko też okazało się, że miesięczny sprint jest stanowczo zbyt długi – i skróciliśmy sprinty do dwóch tygodni, co znacznie poprawiło nam relacje z biznesem. Potem na bazie tego zespołu powstało Code Sprinters, gdzie tradycje pracy w ten sposób były kontynuowane w pracy dla zewnętrznych klientów – ale to już inna historia.

Dlaczego zdecydowałem się podzielić historią mojego osobistego zetknięcia z Agile na blogu?

Po pierwsze dlatego, że jak wiem z doświadczenia jest ona dość niezwykła – dla większości ludzi, z którymi spotykam się w mojej pracy Agile (Scrum czy Kanban) było odkryciem idącym w poprzek tego co wcześniej znali i co robiono u nich pracy. Tymczasem dla mnie to było na zasadzie: „o rany, to to ma już nazwę?” – nazwanie, uzupełnienie tego co już stosowałem, w czym już pracowałem.
Po drugie dlatego, że to doświadczenie – jak i kolejne lata pracy z zespołami Code Sprinters budującymi oprogramowanie dla klientów – dały mi jedną rzecz, której wielu nawet praktyków Agile nie ma: doświadczenie pracy w tak zwanym „pełnym” albo „książkowym” Scrumie.

Przydaje się to kiedy pojawiają pytania z gatunku „ale czy to gdzieś może tak działać?”. Wiem, że może, bo sam tego doświadczyłem, co więcej, to dla mnie naturalny i normalny sposób pracy. Jest oczywiście wiele czynników, które spowodowały, że było to dla nas możliwe, wśród których warto wyróżnić ten oto, że organizacja była tak zrobiona od samego początku nie musieliśmy zatem mozolnie wychodzić z dysfunkcji i walczyć z zaszłościami. Niemniej – da się – i fajnie wiedzieć to z własnego życia, a nie z książek czy konferencji.

Ale jeszcze bardziej przydaje się to przy „leczeniu” ułomnego Agile, nieudanych „wdrożeń”, pomaganiu zespołom i firmom z problemami. Nie idzie nawet o to, żeby wszystkich doprowadzić do takiego idealnego stanu – bo to z różnych powodów nie zawsze jest możliwe – ale o to, by mieć go jako punkt odniesienia i przypomnienie, że to jest jednak możliwe.

Każdemu życzę takiego doświadczenia – zetknięcia ze „zdrowym Agile”, zdrową kulturą – a już zwłaszcza tym, którzy myślą o byciu Agile Coachami czy trenerami.