Mówienie o tym, że Agile się kończy a Scrum leży już w grobie, zrobiło się ostatnio modne, więc zamierzam pójść pod prąd i pokazać, czemu to bzdura.
Autopsja domniemanego denata
Agile to użycie empiryzmu jako narzędzia ułatwiającego rozwiązywanie złożonych problemów. Zdaję sobie sprawę, że ta definicja może nie być zrozumiała dla każdego, więc na wszelki wypadek ją rozwinę.
Zacznijmy od końca, czyli od wyjaśnienia, czym są złożone problemy. Najprościej rzecz ujmując, to problemy, które mają przynajmniej jedną z poniższych cech:
- zmieniają się z upływem czasu w sposób nieprzewidywalny,
- występują w nich takie związki między przyczynami i skutkami, których nie da się w pełni zrozumieć,
- liczba zmiennych, od których zależą, jest zbyt duża, by posłużyć się nimi jednocześnie przy tworzeniu modeli i analiz albo przy podejmowaniu decyzji.
Przykładem problemu złożonego jest rozgrywka szachowa. Gra ma prostą mechanikę, równie proste zasady i zaledwie dwóch uczestników, a mimo to nie da się zagwarantować któremukolwiek z nich wygranej, ani nawet przewidzieć ze stuprocentową pewnością, kto będzie zwycięzcą.
Rozwiązanie każdego problemu (nie tylko złożonego) wymaga podejmowania decyzji, które skutkują wykonaniem różnych czynności. Układają się one w proces, a decyzje pozwalają kontrolować jego przebieg. Jeśli kontrola będzie nieskuteczna, problem pozostanie nierozwiązany lub stanie się to na tyle późno, że rozwiązanie będzie bezużyteczne.
Jak kontrolować procesy rozwiązywania problemów złożonych, które zmieniają się zbyt szybko, nie dają się w pełni zrozumieć, albo podlegają wpływom zbyt wielu czynników naraz? Można podzielić problemy na szereg prostszych zagadnień i zająć się nimi po kolei. Niestety złożoność nie wyparuje od tego magicznie i nigdy nie ma pewności, czy przyjęty sposób dekompozycji jest właściwy.
Dlatego po zakończeniu prac nad każdym z takich małych zagadnień trzeba sprawdzić:
- czy oryginalny problem się nie zmienił,
- czy zakończone prace pozwoliły przybliżyć się do jego rozwiązania,
- czy podział problemu na mniejsze zagadnienia nadal jest właściwy,
- czy ujawnione zostały czynniki, które wymagają zmiany planów dalszego działania.
Każde takie sprawdzenie może skutkować podjęciem nowych decyzji lub zmianą decyzji podjętych wcześniej. To pozwala zachować wystarczającą kontrolę nad procesem, o ile sprawdzenia i dostosowania przeprowadzane są dostatecznie często w prawidłowy sposób.
I tak dochodzimy do empiryzmu. W filozofii to teoria, wedle której cała wiedza pochodzi z doświadczenia lub obserwacji za pomocą przynajmniej jednego zmysłu. Ma ona praktyczne zastosowanie przy kontrolowaniu procesu rozwiązywania różnych problemów: skoro do podjęcia dobrych decyzji potrzeba wiedzy, aby ją pozyskać, trzeba ustalić fakty.
Dlatego zawsze, gdy jest to możliwe, zamiast teoretycznych rozważań o tym, co może się stać na skutek jakiegoś działania i budowania planów na tej podstawie, należy wykonać te działania, by dowiedzieć się na pewno, jaki jest ich rezultat, zanim zaplanuje się dalsze kroki. Dzięki temu nieuniknione błędy decyzyjne korygować można na tyle szybko, że proces nigdy nie zajdzie za daleko w złą stronę (nie wymknie się spod kontroli).
Empiryczna kontrola procesu jest podstawową mechaniką wszystkich metod Agile. Dlatego są one zawsze iteracyjne, żeby sprawdzenie i dostosowanie następowało wystarczająco często. Dlatego są też zawsze inkrementalne, czyli rozwiązywanie problemu odbywa się małymi kroczkami, żeby możliwe było korygowanie procesu i planów działania po każdym z nich.
To również z tego powodu w najpopularniejszej metodzie zwinnej, czyli w Scrumie (też rzekomym nieboszczyku w opinii niektórych) tak ważna jest Definicja Ukończenia. Określa kryteria, jakie musi spełnić produkt, żeby było wiadomo, czy w ogóle powstał i czy nadaje się do użycia. Jeśli tak, możliwe jest empiryczne sprawdzenie, jaki ten produkt jest i w jakim stopniu odpowiada aktualnym potrzebom użytkowników. Jeśli nie, wiadomo na pewno, że produktu lub jego nowej wersji nie ma.
Wszelkie dywagowanie o tym, co by było, gdyby prace udało się ukończyć, jest bezprzedmiotowe. Dopóki nie powstanie działający produkt, nie wiadomo nawet, czy da się go w ogóle wytworzyć. Jedyne, co w takiej sytuacji wiadomo na pewno, to że jeszcze nie powstał.
Albowiem, wbrew przekonaniu wielu osób, nie ma żadnego problemu z ustaleniem, jaki jest rzeczywisty postęp w rozwoju produktu, o ile przestaniemy się oszukiwać. Zamiast mówić, że „idzie dobrze, bo 40% planu wykonaliśmy w zakładanym czasie”, wystarczy porównać listę cech i możliwości najnowszej działającej wersji produktu z listą potrzeb użytkowników. Wszystko stanie się jasne. Oczywiście najpierw trzeba w ogóle dysponować produktem, który działa, więc może stąd biorą się problemy z mierzeniem postępu prac…
Przyczyny zgonu
Jeśli Agile jest już martwy, to znaczy, że stał się bezużyteczny. Ponieważ wszystkie metody zwinne opierają się na jednej mechanice, jaką jest opisana powyżej empiryczna kontrola procesu, najwyraźniej musiała ona przestać działać. Jeszcze do niedawna – gdy Agile wciąż żył i wierzgał zajadle – decyzje podejmowane na podstawie wiedzy o faktycznym stanie spraw były częściej trafne niż chybione, a teraz jest na odwrót.
Czy ktokolwiek o zdrowych zmysłach jest gotów bronić publicznie takich tez?
Poza tym, jeśli empiryzm przestał działać, jakie są tego przyczyny? Co się zmieniło? Działał przez wiele lat, po czym nagle mu się odwidziało? Zmienił branżę? Na emeryturę poszedł? Pewnie też zmarł i pociągnął za sobą Agile do grobu…
Coś brzydko pachnie
Nie, to nie Agile, czy też jego zwłoki. To gnijące złudzenia, niespełnione obietnice i nieetyczne rady pseudoekspertów. Smród ten zaczyna być niemożebny.
Rzekomy Agile, o którym mowa, faktycznie jest trupem od dawna, bo nigdy się nie narodził – być może to zombie. Stanowił grę pozorów, w której najbardziej brakowało tego, co powinno być podstawą zwinności. Empiryzm nie tyle przestał dziś działać w wielu firmach i Zespołach, ile nigdy w nich działać nie zaczął. Brakło wiedzy, że jest potrzebny, brakło ochoty albo odwagi, by o niego zadbać… przyczyn można wskazać mnóstwo.
Czy można twierdzić, że prawdziwy Agile jest martwy, bo jakaś jego karykatura nie przyniosła posługującym się nią ludziom żadnych korzyści? To mniej więcej tak, jakby uznać, że lotnictwo jest martwe, bo choć wielu ludzi skleciło niby-samoloty w szopie, nie zdołały one nigdy wzbić się w powietrze. Ewidentnie jest to dowód na to, że „samoloty nie działają”, czyż nie?
Kto i dlaczego rozwiesza klepsydry
Popularne powiedzenie głosi, że jeśli nie wiadomo, o co chodzi, to musi chodzić o pieniądze. I tak jest po części z doniesieniami o śmierci Agile.
Spora rzesza osób głoszących tę smutną i zupełnie nieprawdziwą nowinę to ci sami ludzie, którzy kilkanaście lat temu kładli do grobu tradycyjne projekty i najgłośniej krzyczeli, że pomogą każdemu uzyskać zwinność. Moda na Agile szybko rosła, gorzej było z korzyściami organizacji, które uzyskały często jedynie pozory zwinności. Gdy gospodarka światowa zaczęła trzeszczeć, przyszło otrzeźwienie i pseudo-Agile zaczyna gwałtownie obumierać. Sprzedawcom złudzeń biznes się sypie, więc mówią, że „Agile jest martwy”, bo chcą w ten sposób przyciągnąć uwagę do tego, co teraz mają do zaoferowania.
Zachęcam do przejrzenia różnych wpisów na ten temat w mediach społecznościowych i publikacji w Internecie. Dowiedzieć się z nich można, że tak naprawdę zbawi nas wszystkich Kanban. Albo ogólniej zarządzanie przepływem. A może Teoria Ograniczeń. Lub ewentualnie Lean. Oczywiście każde z tych narzędzi pozwoli nareszcie poradzić sobie z każdym możliwym problemem, jakżeby inaczej! Czyli zrobi to, na co rzekomo pozwalać miał Agile przez wiele lat, zanim nieszczęśnikowi się zmarło. I dokładnie to samo, co ponoć umożliwiały projekty lat temu kilkanaście, zanim jeszcze wredny Agile zabił je bezlitośnie.
Szydzę, ale cóż pozostaje w zderzeniu z absurdem? Oczywiście projekty mają się dobrze, o ile używa się ich tam, gdzie ma to sens, a nie dlatego, że są modne. I tak samo będzie z metodami zwinnymi.
Jest też nieco mniejsza grupa ludzi, którzy autentycznie wpadają w żałobę po Agile i nie próbują niczego sprzedać zamiast niego. To ci, dla których stanowił on nie narzędzie, ale filozofię lub niemal styl życia. Oni również zaczynają przebąkiwać, że coś się kończy i trudno się im dziwić – tak rozumiany Agile będzie się mocno kurczyć, a może zawsze istniał jedynie w ich wyobraźni.
Wszyscy pozostali mają dyskusję o tym, czy Agile umiera, czy ma się dobrze, głęboko gdzieś, bo zajęci są robieniem czegoś istotnego. Jeśli uznają, że empiryzm może im pomóc, posłużą się metodami zwinnymi. Jeśli nie, sięgną po inne narzędzia.
Całkiem żywotny nieboszczyk
Dla każdego, kto podchodzi do Agile w sposób praktyczny, nic się nie kończy ani nawet nie zmienia. Empiryzm jak działał, tak działa i działał będzie. Metody zwinne nie znikną, choć ich popularność może nieco zmaleć. Ja twierdzę, że zredukuje się ona w naturalny sposób do poziomu, który odzwierciedlał będzie realny obszar ich sensownego stosowania.
Tym, co rzeczywiście mogłoby uczynić Agile narzędziem nieprzydatnym, byłaby jakaś nowa, do tej pory nieznana metoda lepszego radzenia sobie ze złożonością. Na razie nie ma niczego takiego na horyzoncie i niewykluczone, że nie pojawi się w przyszłości. Przy czym mam tu na myśli rzeczywiście nową ideę, a nie coś, co istnieje już od dawna i przedstawiane jest pod nową nazwą.
A skoro o tym mowa, to spodziewam się prób zastąpienia etykiety Agile przez nowy termin, który pozwoli rozkręcić na nowo modę na użycie empirycznej kontroli procesu. Gdy już kolejne puste obietnice o tym, jak to Kanban, Lean itd. „na pewno zbawią świat” okażą się oszustwem, znajdą się bez wątpienia chętni, by jeszcze raz zaoferować światu Agile w świeżym opakowaniu.
Na wszelki wypadek dodam, że nie próbuję tu sugerować, jakoby Kanban czy Lean użyty wprost były bezwartościowe. Wręcz przeciwnie: każde narzędzie wybrane świadomie i zastosowane w sposób właściwy daje duże możliwości i potencjalne korzyści.
Natomiast nie uważam, by Kanban, Lean czy Teoria Ograniczeń były zawsze realną alternatywą dla metod zwinnych lub choćby tradycyjnych projektów. A już absolutnie oburza mnie, gdy ktoś twierdzi, że pomogą rozwiązać wszelkie dotychczasowe problemy każdej organizacji. Jestem zwolennikiem łączenia różnych narzędzi w taki zestaw, który pozwoli skutecznie działać. Zamiast wybierać np. między Scrumem lub Kanbanem, wolę użyć tego Kanbana jako strategii w Scrumie.