Niedawno obejrzałem wystąpienie jednego z sygnatariuszy Manifestu Agile – Martina Fowler – na konferencji Agile Australia 2018 (tutaj możecie zobaczyć wideo, a tutaj transkrypcję przemówienia). Potem przeczytałem ciekawą 'dyskusję’ na jego temat na blogu innego uczestnika sławnego spotkania w Utah w 2001 – Roberta C. Martin (zwanego również Wujkiem Bob) – możecie przeczytać ją na blogu Clean Code.
Gdybym miał podsumować to co przeczytałem – wydaje mi się, że autorzy Manifestu po kilkunastu latach od jego opublikowania chcą powiedzieć społeczności Agile, że ruch który zapoczątkowali rozminął się z pierwotnymi założeniami i celami. Zbiór zasad mający służyć lepszemu dostarczania oprogramowania został opakowany w pudełko 'metodyki’, oklejony kolorowymi logami i sprzedawany jako produkt zajmujący miejsce kaskadowego podejścia do zarządzania projektami informatycznymi, albo 'przynętą’ pomocną w upolowaniu kolejnego klienta. W podobnym tonie wypowiedział się w ubiegłym roku na ABE2017 inny współautor Manifestu – Alistair Cockburn w przemówieniu „The Heart of Agile” (co prawda na YT nie ma filmu z tego wystąpienia, ale możecie znaleźć tą prezentację z innych konferencji np. tu lub tu).
Programiści – którzy pierwotnie napisali Manifest – aktualnie są mało widoczni w tzw. społeczności Agile. Na pytanie Martina ilu programistów jest na sali podczas konferencji, tylko kilka osób podniosło rękę. Podobna refleksja pojawiła się na zakończenie tegorocznej edycji Agile By Example. Dlaczego? – może nie znajdują tam wystarczająco dużo ciekawych treści. Podjąłem się 'trudu’ przejrzenia agendy 3 ostatnich edycji tej konferencji w poszukiwaniu wystąpień, które potencjalnie mogłyby zainteresować programistów – i nie znalazłem za wiele. Zerknijcie proszę na tematy sesji – Leadership, Scrum, Kanban, Product, Team Building, Projects, People, Transformation, Organization, Coaching itd, itp. W tym roku pojawiła się sesja Remote & Craftsmanship, która w jakiejś mierze nawiązywała do wytwarzania oprogramowania, ale są to raczej nieliczne wyjątki.
Ktoś może stwierdzić – programiści mają swoje konferencje, na których omawiają zagadnienia techniczne, dzielą się wiedzą i doświadczeniami, a na konferencjach Agile rozmawiamy o Scrumie, Kanbanie, produktach, zarządzaniu zespołami, projektami itp, itd. Błąd! Właśnie taki sposób myślenia m.in. doprowadził do … powstania Manifestu Agile. „Programiści są od programowania, najlepiej niech nie odchodzą od swoich komputerów, a już w żadnym wypadku nie bierzmy ich na spotkanie z klientem (przecież wszyscy programiści chodzą w t-shirtach uwalanych ketchupem).” Ale to programiści przecież napisali: „Business people and developers must work together daily throughout the project.” Tymczasem w niektórych organizacjach, które twierdzą, że przeszły transformację Agile, nadal programiści nie wychodzą ze swoich boxów i przez cały czas trwania projektu nie poznali np. przyszłych użytkowników systemu. Ewentualnie można im zrobić kilkugodzinną pogadankę o Agile, pobawić się w Lego Scrum i Kanban Pizzę, a potem pokazać proces Scrumowy, wskazać palcem na kółko po środku i powiedzieć – „tu jest Twoje miejsce”.
Dlaczego tak się dzieje? Moja obserwacja jest taka, że wśród osób, które są Agile coachami (trenerami zwinności ?) jakaś część (może nawet większa?) nie ma o programowaniu większego pojęcia i nigdy się tym nie zajmowała. A powinna? – zapytacie. To przeprowadźmy pewien eksperyment myślowy – przyjmijmy, że Agile Coach to osoba, która ma za zadanie zaszczepić w organizacji (o dokładnie w ludziach, którzy w tej organizacji pracują) zasady i pryncypia Agile. 12 pryncypiów Agile możesz znaleźć tu (ktoś tam w ogóle zagląda?). Skoro tak – to taki 'trener zwinności’ powinien m.in. potrafić nauczyć jak dostarczać działające oprogramowanie często („Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale„). Oczywiście wykorzystanie frameworku takie jak Scrum jest tu bardzo pomocne, ale do tego dochodzi jeszcze np. ciągła integracja (CI – continuous integration), ciągłe dostarczanie (CD – continuous delivery) – co to jest i jakie narzędzia mogą być wykorzystane? – Agile coach powinien wiedzieć. Albo w jaki sposób pisać dobry, czytelny kod oraz doskonalić sztukę programowania („Continuous attention to technical excellence and good design enhances agility„) – co to jest refaktor kodu i czemu służy? jak pisać samokomentujący się kod? Co to „code review”? Po co i jak pisać testy jednostkowe oraz testy integracji? – Agile coach powinien wiedzieć 🙂
Pamiętam czasy, kiedy w modzie były metodyki prowadzenia projektów takie jak Prince2 lub PMBoK (który jest bardziej zbiorem dobrych praktyk niż metodyką). Za prowadzenie projektów informatycznych brały się czasami osoby z certyfikatem np. Prince2 (po 3 dniowym szkoleniu – zdawalność na poziomie foundation powyżej 75%) ale nie mające pojęcia o IT. Słabo się to kończyło … Czy nie macie wrażenia, że coś podobnego powtarza się teraz w związku z modę na Agile? Agile jest trendy, Agile jest cool – zrobię 2 dniowe szkolenie PSM, certyfikat i jestem Scrum Masterem lub Agile Coach … Chociaż sam nie jestem programistą (ale też nie nazywam siebie Agile Coachem), to piszę to z perspektywy osoby, która zanim zaczęła zajmować się zarządzaniem zespołami IT i ich budowaniem, przez kilka lat ubrudziła sobie ręce typowo 'informatyczną’ pracą – administrowaniem bazami danych i aplikacjami, wsparciem użytkowników systemów IT, instalowaniem Windowsa na PCecie i nurkowaniem pod biurka, żeby sprawdzić, czy patchcord jest dobrze wpięty w gniazdko. To doświadczenie bardzo mi potem pomogło. Uważam, że ma to zastosowanie w innych obszarach – jeśli chcesz czymś zarządzać, lub jeśli chcesz kogoś uczyć/trenować – musisz samemu znać (przynajmniej w jakimś zakresie) rzemiosło, 'ubrudzić sobie ręce pracą’.
Co o tym sądzicie? Czy Waszym zdaniem obecnie Agile rozminął się z pierwotnym celem i założeniami? Czy trzeba znać się na programistycznym rzemiośle, żeby być Agile Coachem?
ps. Być może zastanawiacie się, co robią wyroby z gliny jako ilustracja tego artykułu? Pomyślałem, że to ciekawa metafora łącząca słowo „rzemiosło” i „ubrudzić sobie ręce pracą” 🙂