Zwinnoodporność

Data: 2020-12-16
Autor: Sebastian Konkol
Zwinnoodporność

Termin zwinności (agile, agility) robi karierę. Zachwycamy się podejściem zwinnym, w coraz to nowych obszarach. Wręcz zaczynamy to traktować jak nowe lekarstwo na „całe zło”. Jestem absolutnym fanem włączania cech zwinności w każdy z obszarów moich zawodowych zainteresowań. Agile jednak ponosi klęskę za klęską i wcale nie wynika to z tych cech, lecz z praktyki ich wykorzystania. No więc jak to jest w praktyce?

W kolebce zwinności, czyli software development

Od czasu Agile Manifesto wiadomo, że lepiej idzie skupiając się na ludziach i komunikacji, działających rozwiązaniach, współpracy z klientem i zmianie. Taka zmiana nastawienia była jednak podyktowana jedną prostą konstatacją: niskokosztowe eksperymenty są możliwe do realizacji w realiach IT. Wiara w skuteczność agile w tworzeniu oprogramowania opiera się na tym, że można zrobić coś małego (czyli ryzykując relatywnie mało), co będzie miało realną wartość biznesową, a co – w razie pomyłki – będzie można bez żalu wyrzucić do kosza.

Praktyka tymczasem pokazuje, że w agile został postawiony na głowie. Zamiast niskokosztowych eksperymentów mamy jedynie eksperymenty. Są one zrobione tak, że później nikt nie chce ich już ruszać (bo przecież zrobione „na szybko”), a ich poprawienie okazuje się być bardzo kosztowne. BTW, kto ostatnio uczestniczył w realizacji software’u, w którym regularnie robiony był cykl refaktoringu? Jakoś nie wydaje mi się, że udało się wszystkim genialnie trafiać w ostateczne rozwiązania za każdym razem od razu… Do tego, zamiast współpracy biznesu z technologią jest dogmat frameworku i bezrefleksyjnego stosowania „fajnych wzorców”. Już przestałem reagować na rozpoczynanie dyskusji od tego, czy będziemy robić mikroserwisy (z dogmatycznie oddzielnymi bazami danych) i w ilu miejscach będzie CQRS (bo wszyscy – jak twierdzą – robią DDD), zanim jeszcze w ogóle ustalimy, o co tak naprawdę chodzi biznesowo.

Jeśli rzeczywiście mamy uzyskać zwinność w tworzeniu oprogramowania, to myślenie przez pryzmat realnej wartości biznesowej musi obowiązywać absolutnie bezwzględnie, bo trzeba wiedzieć, w jakim kierunku nawigować.

Krok poza, czyli zwinne projekty

Dość szybko, w dużej mierze za sprawą Jima Highsmitha, Agile weszło do kanonu podejścia projektowego (mam skromny wkład w tłumaczenie jego Agile Project Management na język polski). Zakładano krótkie przyrosty z wartością biznesową, szybki feedback i pracę zespołową. To tyle, jeśli chodzi o szczytne ideały metodyki pracy, teraz do realiów.

Coraz częściej widzę nie tyle potknięcia, co wypaczenia „projektów realizowanych zwinnie”. To, że mamy sprinty nie przynoszące kompletnie żadnej wartości biznesowej („w tym sprincie kontynuujemy analizę”, „w tym sprincie uzgadniamy zakres dokumentacji technicznej”), już nawet nikogo nie dziwi (sic!). Mamy jednak projekty zwinne realizowane bez Product Ownera (zamiast tego zespół wybiera sobie, co będzie robił i nie bardzo rozumiem kontrolę wartości biznesowej w ten sposób tworzonej). Mamy także robienie kolejnych sprintów dla dorobienia wszystkich elementów „z zakresu” („wszak było w planie, więc trzeba dowieźć”) i nikt nawet nie zająknie się o wartości biznesowej. Mamy też „zespoły projektowe” nadal najlepiej czujące się w podziale na biznes i IT, z tym podziałem zakodowanym chyba na poziomie gadziego mózgu i odruchów bezwarunkowych.

Realizacja projektu nie stanie się zwinna dzięki nazwaniu projektu w ten sposób. Zwinny projekt obiecuje zrealizować największą wartość biznesową, jaką da się osiągnąć, optymalnym wysiłkiem – oraz zaprzestać prac z chwilą braku wymiernych korzyści uzasadniających kolejny krok. Temu służy feedback, a jego rola jest po prostu fundamentalna. Bo trzeba umieć skorygować kierunek tak szybko, jak tylko się da.

Awangarda, czyli zwinna architektura IT

A jak wygląda zwinność w centrum mojego zawodowego świata? Zacznijmy od rozróżnienia zwinnego „robienia architektury” od zwinnej architektury (wynik robienia architektury, wcale nie koniecznie w zwinnym procesie). W tej pierwszej sferze jest słabo. Trochę ciekawych inicjatyw (np. Achitectural Thinking Association) przeciera drogę, ale do „standardów branżowych” to jeszcze daleko. „Uznane ciała” branżowe raczej nie rozumieją, o co chodzi – dla przykładu The Open Group opublikowało draft Agile Architecture Framework, z którego wynika, że w zasadzie należy robić TOGAF (zwinny jak supertankowiec), tylko szybciej. W drugiej sferze jest niemalże kompletna plaża, choć da się znaleźć takie perełki, jak Jason Bloomberg (autor The Agile Architecture Revolution), który pokazuje, że zwinność w architekturze IT polega na tym, żeby rozwiązania dały się użytkować w scenariuszach innych niż te, do których zostały zaprojektowane i to bez konieczności wprowadzania w nich zmian (zwinnie, czy otherwise).

W przestrzeni architektury IT najjaskrawiej widać rozdźwięk między ideą zwinności i jej praktykowaniem. Jak to ujął jeden mój kolega po fachu (Wolfgang, Vielen Dank!), zające są szybkie, ale nie czyni ich zwinnymi – nie przeszkadza to drapieżnikom uczynić z zajęcy głównego składnika pożywienia. O zdolności zajęcy do adaptacji decydują ich siły rozmnażania – to właśnie rozmnażanie czyni je zwinnymi. Jeśli będziemy robić złe rzeczy szybciej, to jedynie szybciej napsujemy, ale w żaden sposób nie będziemy wiedzieć, jak zrobić dobrze. Zwinność to zdolność do adaptacji, a nie bezrefleksyjnego przyspieszania.

Szerokie wody, czyli zwinny biznes

Zwinność biznesowa, pozwolę sobie na odrobinę złośliwości, jest terminem tak wieloznacznym, że chyba nawet bardziej, niż termin „architektura”. Od wielu już lat wiadomo, że trzeba się dobrze orientować i sprawnie podejmować decyzje. Sam opowiadałem wielokrotnie o pułkowniku United States Air Force Johnie Boyd i jego OODA. Opowiadałem także o 宮本 武蔵 (Musashi Miyamoto) i jego filozofii wyrażonej w 五輪書 (The Book of Five Rings). W praktyce sfery biznesowej Agile najczęściej oznacza „zacznijmy coś robić, a reszta wyjdzie w praniu” – i choć taka odwaga jest często bardzo właściwą postawą, znacznie częściej świadczy o kompletnym braku pomysłu, a nawet przekonania, że wartość biznesową w ogóle da się uzyskać (nie wiem, co myśleć o zarządach, które dają się w ten sposób przekonywać).

Zachłyśnięcie się Agile, szczególnie właśnie w sferze zwinności biznesowej, stało się możliwe dzięki trzem faktom. Po pierwsze, przez lata wcześniejszych wysiłków firmy dopracowały się podstaw na tyle stabilnych, że jeden czy drugi projekt „edżajlowy” nie jest w stanie ich zawalić, a jedynie obciąża. Po drugie, po jakimś czasie „edżajlowe” efekty są naprawiane w trybie rutynowych, odpowiedzialnych działań. Po trzecie, sprzątanie się dzieje już po pewnym czasie – kiedy „edżajlowi guru” (wraz z wianuszkiem oportunistów żądnych poklasku) już zebrali swoje chwile w błyskach lamp i poszli „edżajlowić” dalej, zanim „edżajlowe” efekty objawiły się w pełnej krasie. Jestem złośliwy, ale – biorąc pod uwagę doświadczenia – raczej oszczędnie.

Zwinność biznesowa, czyli zdolność do adekwatnej reakcji, jest nie do osiągnięcia, jeśli nie wiemy, jak działamy i na czym się opieramy. Działać biznesowo zwinnie to nie wskakiwać bez zastanowienia w nowy obszar, tylko zrozumieć szerokie spektrum scenariuszy. To jak partia szachów, w których jesteśmy w stanie przewidzieć kilka następnych posunięć. Zwinność przesuwa bowiem nacisk zarządczy z „dumne dążenia w kierunku” na „orientowanie się w zmianie”. Nie znaczy, że planowanie strategiczne zastępujemy „rozpoznaniem bojem” – znaczy, że zmieniamy narzędzie planowania strategicznego na scenariusze i interakcje z otoczeniem, przestajemy „realizować słuszny plan” a zaczynamy „rutynowo korygować codzienne działania”.

Stara maksyma inwestorów kapitałowych, że „jeśli nawet portier mówi, żeby kupować, to trzeba sprzedawać” może także mieć tutaj zastosowanie – jeśli już wszyscy mówią, że Agile jest dobry na wszystko, to wypadałoby się zatrzymać i krytycznie zastanowić, bo obecna praktyka „edżajlu” jest doskonałą receptą na chaos i widowiskową porażkę. Nie chodzi bowiem o szybkość, zwrotność czy brawurę lecz o zdolność do adaptacji do nowych warunków dokonywanej bez ponoszenia znaczących kosztów i straty czasu… Może więc jednak warto poświęcić chwilę na refleksję, o co tak naprawdę chodzi w filozofii Agile w konkretnym, Waszym przypadku – do czego macie się adaptować i jakie mechanizmy adaptacji są dla Was właściwe?

Pozostaw komentarz