Blog

Przyjmijmy, że jakaś firma łudzi się, że da się edyktem wprowadzić Agile. Jak to zrobi? Opracuje a następnie wdroży proces, który uczyni zespoły „dojrzałymi”, gdy już nauczą się ten idealny proces stosować. Zakrawa na ironię, że taka „transformacja” realizowana jest najczęściej w modelu kaskadowym: analizujemy obecne procesy, projektujemy zmiany, planujemy ich wdrożenie, potem to robimy i monitorujemy efekty…

Niezbędne stają się narzędzia, które ułatwią wdrożenie wybranej metody. Bezwzględnie muszą to być systemy wyposażone w możliwość definiowania artefaktów i ról, zaś proces modelowany będzie jako zestaw workflowów określających co i w jakiej kolejności poszczególne role mogą robić z artefaktami. Starannie przemyślane rozwiązanie uwzględni wszystkie dopuszczalne przypadki zachowania się uczestników procesu, wymuszając zgodność z założonym procesem. Na deser otrzymamy możliwość generowania metryk i statystyk.

Brzmi znajomo? Jeśli kojarzy się to komuś z TFSem, Rallym lub Jirą (z jej rozszerzeniami Agile’owymi) to jak najbardziej słusznie: tego typu narzędzia są de facto niezbędne, by opisany przeze mnie model wdrożenia metod zwinnych przeprowadzić. W praktyce wspomniane wcześniej narzędzia mają nawet gotowe schematy konfiguracyjne pozwalające „przejść na Agile” w ciągu kilku godzin. Odpowiednio ustawione uprawnienia (ograniczające niektóre z ról tak, by każdy zespół nie zaczął działać po swojemu) zagwarantują, że się uda wdrożyć Agile bez większej czkawki. Czyżby?

Nie ma gotowej recepty na Agile

Zła wiadomość brzmi tak: to, że używacie Jiry Agile lub Rally’ego wcale nie oznacza, że jesteście Agile. Już samo przekonanie, że narzędzie może organizację uczynić bardziej zwinną, jest objawem niezrozumienia, czym jest Agile. Dlaczego?

Zwinność to zdolność do szybkiego dostosowywania się do zmieniającej rzeczywistości i ewolucyjnego wypracowywania coraz to nowych, w danym momencie najlepszych sposobów działania. Nie da się z góry zaplanować sposobu bycia zwinnym, a narzędzia nijak tu nie pomogą. Nie ma recepty na zwinność, bo każda organizacja jest inna (inni ludzie, inne uwarunkowania, inne produkty, inna historia). Uniwersalny i jedynie słuszny model nie istnieje, choć wiele firm uparcie próbuje wykazać, że to nieprawda.

Ostrożność zalecana

Nie ma niczego złego w zastosowaniu narzędzi, aby ułatwić sobie pracę, pod warunkiem, że one będą się dostosowywać do nas, a nie my do ich ograniczeń lub wymogów technicznych. Zawsze należy używać narzędzi świadomie.

Katastrofą jest wspomniany przeze mnie wcześniej pomysł, by poprzez narzucony w narzędziu workflow definiować proces, jakim zespoły miałyby się posługiwać. W takim modelu zespół w zasadzie nie będzie w stanie niczego usprawnić, bo nie poczuje odpowiedzialności za organizowanie sobie pracy. Skoro ktoś zdefiniował proces, to niech teraz dokonuje usprawnień, czyż to nie logiczne?

Jeszcze większą katastrofą jest narzucenie narzędzia ze zdefiniowanym workflow i odebranie uprawnień do jego modyfikowania. Niezależnie od tego jak bardzo organizacja będzie zachęcać ludzi do zgłaszania usprawnień, empiryzm (podstawę Agile) diabli wezmą. Zanim proces zatwierdzenia zmian, niezbędnych do przeprowadzenia empirycznego eksperymentu dobiegnie do końca, nikt już nie będzie pewny co te zmiany miały dać, nie mówiąc już o braku możliwości ocenienia realnego ich wpływu na cokolwiek.

Zmiana konfiguracji bywa czasochłonna

Załóżmy jednak, że mamy narzędzie z prawami do robienia w nim wszystkiego, na co mamy ochotę. Jeśli z narzędziem pracować będzie kilka zespołów, dość szybko zacznie się problem z czasochłonnością każdej zmiany w procesie (workflow się komplikuje) i wzajemnym deptaniem sobie po palcach przez zespoły.

Twórcy Jiry czy Rally’ego zapewnią nas, że to nie problem, że wszystko da się w tych narzędziach rozwiązać w sposób, który nie generuje konfliktów i nie ogranicza zespołów. I pewnie to prawda, z tym że wymaga to czasu, dobrego poznania narzędzia (które miało przecież pomóc, a nie dokładać pracy!) i cierpliwości. Innymi słowy może i da się zrobić wszystko, co wymyślimy, ale nie da się tego zrobić najczęściej ani łatwo, ani szybko.

Najczęstszym efektem użycia kombajnów takich jak Rally czy Jira jest powolny spadek przejrzystości tego, co się rzeczywiście dzieje. Bo skoro jest narzędzie, istnieje naturalna tendencja do „zapytania Jiry” o dane, zamiast rozmowy z zespołami. A tymczasem opis procesu w narzędziu mniej lub bardziej rozjeżdża się z rzeczywistością, gdy z powodu ograniczonych uprawnień lub trudności konfiguracyjnych zespoły zaczynają część rzeczy robić bez odzwierciedlenia tego w workflow. Bo tak szybciej i prościej.

Jeśli zaś przymusimy zespoły, by narzędzie pokazywało wszystko, co dzieje się w rzeczywistości, możemy całkiem zgasić ducha zwinności. Zamiast męczyć się z wprowadzeniem zmian do narzędzia, prościej będzie zrezygnować z tych zmian w ogóle i pogodzić się z jedynym słusznym, z góry zdefiniowanym procesem.

Czy narzędzia to samo zło?

Nie, ale należy używać ich rozumnie. Wspomniane Jira lub Rally wyposażone są w mechanizmy ułatwiające współpracę zespołom zdalnym i w tym kontekście mogą być pomocne. Warto trzymać się zasady, że korzysta się z narzędzia w sposób maksymalnie odzwierciedlający „analogowe” tablice i karteczki – jeśli się na to umówimy i będziemy tego trzymać, narzędzie w istocie pozwoli nam efektywniej pracować zdalnie, a nie ograniczy za bardzo możliwości wprowadzania usprawnień. Sami oceńcie, czy używane przez was narzędzia dają sie zastosować w ten sposób.

Pojawi się od razu pytanie: a co z metrykami, jeśli nie użyjemy takiej na przykład Jiry? Co ze statystykami, raportami? Jeśli nasuwają się wam takie pytania zastanówcie się, czy na pewno Jira / Rally to jedyny sposób, by te dane zebrać. I czy aby na pewno ufacie, że zgromadzone dane obrazują rzeczywistość. A jeśli tak, to czy nie zyskaliście tego zaufania do narzędzia poprzez narzucenie ograniczeń zespołom, które na co dzień go używają.

Najważniejszym zaś jest pytanie: czy wszystkie metryki, które dziś zbieracie w oparciu o Jirę, Rally’ego lub inne narzędzie, naprawdę są wam niezbędne i jakkolwiek ułatwiają wam pracę. Bo może zbieracie dane „na wszelki wypadek”, dodając i sobie i innym niepotrzebnej pracy… Ale to już temat na zupełnie inny artykuł.