To będzie krótki i chyba dość smutny tekst.
Do jego stworzenia zainspirowała mnie krótka i chyba dość smutna konwersacja ze znajomym znajomego, którą odbyłem w ostatnich dniach. Jak to zwykle bywa w przypadku rozmów z osobami, z którymi nie łączy nas pogłębiona zażyłość, było na początku o zagadnieniach z klasycznego arsenału small talku: Dawno tyle śniegu nie napadało. Sanki jednak przydadzą się nie tylko jako dodatkowa półka na słoje z przetworami. Ale wolno szczepią… Może się jesienią doczekam. Tylko, kurczę, wolałbym ten mikrochip jednak od Apple… Takie tam pierdoły, wiadomo.
Ostatecznie osunęliśmy się na tematy zawodowe. Jako że znajomy znajomego jest menedżerem średniego szczebla w firmie, która świadczy innym podmiotom usługi IT, podzielił się ze mną swoimi doświadczeniami z zastosowaniami scruma. Okazuje się, że niektórzy klienci życzą sobie wprost, by rozwijane dla nich produkty, usługi albo projekty – darujmy sobie na moment nomenklaturowe zawiłości, bo nie są istotą rzeczy – rozwijano za pomocą scruma. Podobno klient nasza pan, więc się – według relacji znajomego mojego znajomego – w takich wypadkach nie dyskutuje, tylko przyjmuje zlecenie z całym dobrodziejstwem inwentarza. Podobno bywa, że zlecenia takie mogą dotyczyć choćby i postawienia data center. Potrzebowałem kilku chwil, by data center zlokalizowane u mnie we łbie przeprocesowało te informacje. Kiedy dane zostały wreszcie obrobione, wyświetliło się wspomnienie kwestii wypowiadanej przez miernego aktora w głupim filmie: Jak cię złapią za rękę, to mów, że to nie twoja ręka. Jak chcą scruma, to daj, choćbyś nawet nie chciał i miał argumenty na korzyść innych metod.
Oczywiście ten biedny znajomy znajomego nie powinien być w centrum opowieści, bo przypadków zbliżonych do opisywanego przez niego jest na pęczki. Czego się czepiasz? – moglibyście zapytać. Przecież można by wznieść toast za powodzenie scruma, za jego rosnącą popularność. Mam zresztą wrażenie, że listopadowa aktualizacja Scrum Guide, w której sama definicja scruma zarzuca wzmiankę o produktach na rzecz dostarczania wartości, a cały dokument dystansuje się od nomenklatury zakorzenionej w budowaniu oprogramowania, jest na takie tendencje odpowiedzią. Bo nie śmiałbym jako żuczek mały sugerować, że jest poszukiwaniem rynków zbytu dla scruma poza terytoriami IT…
Przypomina mi się, poza miernym aktorem i głupim filmem, szkielet Cynefin. W największym skrócie chodzi o koncepcję, która ma udrażniać proces decyzyjny, i proponuje klasyfikację kontekstów, w jakich owe decyzje należy podjąć, na następujące: oczywisty, skomplikowany, złożony, chaotyczny i zanurzony w nieładzie.
W kontekście oczywistym znane są związki przyczynowo-skutkowe, panuje stabilizacja, znana akcja wywołuje znaną reakcję.
W kontekście skomplikowanym przed podjęciem akcji należy dokonać analizy katalogu dostępnych rozwiązań, bo nie każda dostępna praktyka okaże się odpowiednią. Nie zmienia to faktu, że wiedza ekspercka i wycyzelowany osąd w etapie analizy poprowadzą nas właściwą ścieżką
W kontekście złożonym nie wiadomo, czego się spodziewać. Nie można być pewnym, że podłoga się nie zawali, dopóki nie postawi się pierwszego kroku. Można jednak postawić ten krok, zastosowawszy uprząż bezpieczeństwa; kontrolowany eksperyment da bezpieczną odpowiedź, która zdeterminuje kolejne ruchy – również ostrożne.
W kontekście chaosu nie ma komfortu analizy ani eksperymentu. Trzeba zadziałać, by pożar nie pochłonął kolejnych ofiar. Zwykle zadziałać na oślep, by zobaczyć, co się wydarzy, a następnie – z tą wiedzą – usiłować przepchnąć chaos w obszar złożoności.
Kiedy jesteś zanurzony w nieładzie, nie wiesz nawet, który z powyższych kontekstów bierze górę.
Scrum został zaprojektowany do – jak głosi jego definicja zaczerpnięta ze Scrum Guide – rozwiązywania złożonych problemów. Oczywiście zdaję sobie sprawę, że ciężar znaczeniowy złożoności w definicji scruma i w koncepcji Cynefin może się różnić, nie wydaje mi się jednak, by różnice były drastyczne. Ostatecznie rzeczywistość rynkowa ze względu na mnogość wpływów, którymi jest kształtowana – wymieńmy chociażby konkurencję, makroekonomiczny ekosystem albo trendy konsumenckie – nie daje komfortu, w którym utrwalony schemat działania sprawdzałby się w ciągłym trybie. I tu właśnie zespołom, organizacjom, przedsiębiorcom przychodzi w sukurs scrum: postawmy jeden krok i zwlekajmy najwyżej miesiąc, by dowiedzieć się, dokąd może on nas doprowadzić.
Oczywiście scrum wstrzyknięty w złożony kontekst może zawieść i często zawodzi – z setek różnych powodów. Jeśli jednak metoda rozwiązania problemu jest dobrana stosownie do wagi tego problemu, to furtki transparencji, inspekcji oraz adaptacji pozostają otwarte i wstępne fiasko wciąż można przekuć w sukces. Zgoła inaczej sprawy się mają, jeśli scrum forsowany jest z uporem godnym lepszej sprawy – bo klient sobie zażyczył, bo wszystkie zespoły u nas funkcjonują w ten sposób, bo przecież nie wrócimy do starego przeklętego waterfalla, bo taki mamy klimat – gdy problem można rozwiązać prościej, skuteczniej i szybciej. Istnieje wówczas duże prawdopodobieństwo, że scrum przedzierzgnie się w pusty mechanizm, w przeklętą ceremonię, w chocholi taniec lub własną parodię. W jednym z komentarzy zamieszczonych na portalu społecznościowym natknąłem się na dosadne sformułowanie inżyniera oprogramowania, który stwierdził, że – cytuję – scrum master to największy rak w IT. Zdaje się, że to inna, przepełniona goryczą i frustracją, wersja coraz częściej pojawiającego się w dyskursie o zwinności stwierdzenia, że scrum staje się czymś, co robi się developerom. Bo klient sobie zażyczył. Bo wszystkie zespoły u nas funkcjonują w ten sposób. Bo przecież nie wrócimy do starego przeklętego waterfalla. Bo taki mamy klimat.
Jakie mogą być konsekwencje, gdy wytaczamy armaty przeciwko wróblom? Bezpiecznie – i trafnie! – zaplanowane harmonogramy pocięte na sprinty, daily scrum w formie statusów, przeglądy sprintów w formie sesji aktualizacji Jira, retrospektywy sprintów w formie pogaduszek o samopoczuciu, etc… Zdemotywowane zespoły. Wyszydzani scrum masterzy. Figuranci w roli product ownerów. Feedback wyparty raportami. Strata czasu i pieniędzy – tym boleśniejsza, że generowana metodą, która wyrosła na glebie lean. „Scrum”, który boli. Scrum that sucks.