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 realizujemy plan na modłę projektową i monitorujemy jego przebieg…

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, a sam proces modelowany będzie jako zestaw workflowów określających, co i w jakiej kolejności osoby pełniące poszczególne role mogą robić z artefaktami. Starannie przemyślane rozwiązanie uwzględni wszystkie dopuszczalne przypadki zachowania się uczestników procesu, wymuszając określoną kolejność podejmowanych kroków. Na deser otrzymamy możliwość generowania rozbudowanego zestawu statystyk na podstawie równie obfitego zbioru miar i zgromadzonych dla nich wartości.

Brzmi znajomo? Jeśli kojarzy się to komuś z TFS-em, Rallym lub Jirą, 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. Sukces niemal gwarantowany. Czyżby?

Nie ma gotowej recepty na Agile

Zła wiadomość brzmi tak: to, że używacie Jiry 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 są 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 workflowem 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 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 trudna

Załóżmy jednak, że mamy narzędzie z uprawnieniami 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 (wspólny workflow się skomplikuje) 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 workflowu. Dlaczego tak robią? 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 zdusić 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 oprogramowanie (Jira lub Rally) wyposażone jest w mechanizmy ułatwiające współpracę Zespołom zdalnym i w tym kontekście może 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ą się zastosować w ten sposób.

Pojawi się od razu pytanie: a co ze zbieraniem miar, 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 lub Rally to jedyny sposób, by te dane zebrać. I czy aby na pewno możecie zaufać, że dane zbierane przez narzędzia 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żniejsze zaś jest pytanie: czy wszystkie miary, które dziś zbieracie przy pomocy Jiry, Rally’ego lub innego narzędzia, 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… To już jednakże temat na zupełnie inny artykuł.