Wiele dyskusji prowadzonych przez nas na warsztatach i szkoleniach kręci się wokół „problemów agile’a”. Bo nagle okazuje się, że wymagania się zmieniają, że zakres się poszerza albo że próbujemy zabrać się za coś, co tak naprawdę nie wiemy jak zrobić. Tylko czy to rzeczywiście jest problem zwinności?
Obnażanie problemów
„Dlaczego agile?” Odpowiadaliśmy na to pytanie wielokrotnie. Przede wszystkim dlatego, że nie potrafimy przewidzieć przyszłości. Co więcej, odbiorca naszych produktów bardzo często nie wie, czego chce, zanim nie zacznie tego używać. Dodajmy do tego problemy komunikacyjne i błędy poznawcze, a dostaniemy wystarczająco dużo argumentów „za”.
Gorzej, jeśli ktoś spodziewa się, że wszystkie wymienione problemy znikną wraz z nastaniem „ery agile’a”. I wtedy pojawiają się oskarżenia „przecież pracując zwinnie mieliśmy nie mieć problemów ze zmiennymi wymaganiami, a i tak musimy renegocjować nasz kontrakt!”. To dość typowy problem.
Nikt nigdy nie mówił, że dzięki agile’owi unikniemy wszystkich wspomnianych trudności. Wręcz przeciwnie – dzięki zwinnemu podejściu wyciągniemy je na światło dzienne i będziemy zmuszeni je zaadresować. To w klasycznym podejściu odkładamy je na później lub udajemy, że ich nie ma.
Czymże jest podpisywanie kontraktu „fixed price, fixed scope, fixed time”, jeśli nie powiedzeniem „nasz klient doskonale zna wszystkie swoje potrzeby, nie zmieni zdania w trakcie, a my nie napotkamy na żadne nieprzewidziane trudności”? O ile nie odkryliśmy nagle jakiegoś sposobu na czytanie w myślach i podróże w czasie, to takie założenie zawsze będzie fałszywe.
Dopiero w trakcie prac i w trakcie użytkowania naszego produktu powstaną szczegółowe wymagania co do tego, jak ma wyglądać docelowe rozwiązanie. Wcześniej to tylko wróżenie z fusów. Nie wiedzieć czemu, od zwinnego podejścia wymaga się jakiegoś obejścia tego problemu.
„To po co nam ten agile, skoro tylko ukazuje nam nasze problemy?”
No tak, lepiej o nich nie wiedzieć…
Agile unaocznia problemy, abyśmy mogli rozwiązać je w najlepszy dostępny dla nas sposób. Część z nich podpowiada jak zaadresować, ale większość pracy i tak spoczywa na nas.
Ach, te zespoły
Tak wiele uwagi poświęcamy „samoorganizującym się zespołom”, że nie sposób poruszyć tego tematu i przy tej okazji. Wiemy, że najlepsze rozwiązania pochodzą od osób, które odczuwają konsekwencje podejmowanych decyzji („skin in the game„). Wiemy też, że sztuczne podziały powodują myślenie „my kontra oni” oraz zanik odpowiedzialności i zaufania.
Skoro „zespoły analityczne” przygotowują dla nas wymagania, to naturalne jest, że za wszelkie błędy obwiniać będziemy „ich”. Nawet jeśli, zgodnie z tym co powiedzieliśmy sobie wcześniej, to niekoniecznie musi być ich wina. Przecież to klient mógł dopiero odkryć, że coś jest potrzebne albo nasze MVP uświadomiło mu jego prawdziwe potrzeby. To znaczy, że nasz „agile” zadziałał i powinniśmy świętować sukces, a nie obwiniać analityków.
Dziesiątki godzin spędziliśmy nad próbami zaplanowania struktur organizacyjnych zawierających oddzielne zespoły funkcyjne (analityków, testerów, architektów, itd.). Jeżeli chodzi o zwinne środowisko – nie da się tego zrobić. Nie możemy rozdzielić grupy ludzi pracujących nad jednym zadaniem na kilka zespołów. Za każdym razem gdy się to dzieje, komunikacja ulega pogorszeniu i pojawiają się „my kontra oni”.
Jeżeli w jednym zespole znajdują się osoby przygotowujące architekturę, wymagania, testy oraz programiści (czyli wszystkie osoby potrzebne do realizacji backlogu) to nie mamy już możliwości narzekania na to, że „oni źle zrobili to czy tamto”. Pozostajemy już tylko „my”. To jest idea scrumowego Development Team.
Nie bądźmy zdziwieni, że „Scrum nie działa”, jeżeli próbujemy stworzyć osobne zespoły do spraw analizy, testów, dewelopmentu, itd. Problem nie jest ze Scrumem, ale z naszą organizacją pracy!
Scrum to nie cały agile
Wiele podnoszonych „problemów agile’a” spowodowane jest złym doborem narzędzi. Wspominaliśmy o tym przy omawianiu metod podejmowania decyzji takich jak Model Stacey czy Cynefin Framework. Często w ramach metodyk agile jesteśmy w stanie wybrać lepiej lub gorzej. Czasami nawet najlepszym wyborem okaże się… waterfall, który również ma swoje zalety.
Nie powinniśmy też się dziwić, że napotykamy na masę problemów, jeżeli próbujemy wcisnąć na siłę kaskadowy model pracy w iteracyjne podejście. To nie zadziała.
Typowym przykładem niedostosowania sposobu pracy są zespoły utrzymaniowe i wsparcia. Często na siłę wtłaczane są one w takie konstrukcje jak Scrum. Ale wybór nigdy nie brzmi „Scrum albo Waterfall”, bo mamy też takie możliwości jak np. Kanban. Ten w przypadku utrzymania sprawdzi się o wiele lepiej. Ale i on nie uchroni nas przed całym złem tego świata.
I tu znów wracamy do myśli przewodniej dzisiejszego tekstu. To, że cały czas wpadają nam krytyczne błędy z produkcji i tablica kanbanowa pęka w szwach, a limity Work In Progress idą do kosza, to nie jest problem z Kanbanem. To jest symptom niskiej jakości naszego produktu i braków w zarządzaniu.
Agile prawdę Ci powie
Nie ma ani jednej organizacji, która z sukcesem wdrożyłaby podejście zwinne samemu pozostając „betonową”. Agile mindset powinien przejawiać się na każdym szczeblu. Wszystkie problemy, które napotkamy odkrywają już istniejące dysfunkcje. Kilka powyższych przykładów to tylko czubek góry lodowej.
Brak transparentności, karanie za eksperymenty, nietrafiona motywacja, dział handlowy kompletnie oderwany od rzeczywistości produktowej, zespoły nadmiernie rozproszone, itd., itp. Im bardziej jesteśmy nie-agile (albo anty-agile), tym bardziej próby wprowadzenia elementów zwinności wyjdą nam bokiem.
Nie powinien to być jednak zarzut kierowany w stronę metodyk i metod zwinnych. Jeżeli wprowadzamy „agile” kierując się modą albo chęcią zysku, to sami jesteśmy sobie winni problemów, jakie to spowoduje. Jak przecież już wielokrotnie podkreślaliśmy, nie taki jest cel zwinności.
Zamiast narzekać na pojawiające się problemy, powinniśmy się cieszyć, że możemy je rozwiązać. Bo aż strach pomyśleć jak wyglądałaby nasza przyszłość, gdybyśmy się o nich nie dowiedzieli.
