Zwinność i „bycie agile” wywodzą się z IT. Najszybciej za tą modą zaczęły podążać zespoły wytwórcze, które dostarczają skomplikowane rozwiązania, czyli oprogramowanie. Reszta świata nie zawsze nadąża za postępem w informatyce, nawet jeżeli chodzi o tak nietechniczne rzeczy jak zwinne metodyki.
Dla kogo jest agile?
I chociaż zdarzają się krzyki „Zostawcie programistów w spokoju!„, to jednak światek IT wymyślił agile po to, aby lepiej i skuteczniej zorganizować sobie pracę. Była to inicjatywa oddolna, stworzona żeby rozprawić się ze zmieniającymi się wymaganiami, nieprzewidywalnością klienta i brakiem precyzji w informacjach przekazywanych między ludźmi.
I tak nikt chyba nie ma wątpliwości, że iteracyjne wytwarzanie oprogramowania to najlepszy możliwy sposób pracy. Oczywiście, samo iteracyjne oddawanie do testów nie wystarczy.
Użytkownicy końcowi muszą z naszego dzieła faktycznie korzystać. Bez tego nie otrzymamy bezcennej informacji zwrotnej. Wtedy zamiast z pracy iteracyjnej, zrobi nam się praca etapowa, która prawie niczym nie różni się od podejścia waterfallowego.
Ale my to wszystko wiemy. Ale co, gdy nie wie tego klient?
Znów ten waterfallowy klient…
Tworzenie oprogramowania byłoby naprawdę bezproblemowe, gdyby nie ten nieszczęsny klient. Nie tylko nie wie czego chce, ale nawet w sytuacjach w których wydaje się, że wie – i tak później zmienia zdanie. Z jednej strony jesteśmy w stanie to zrozumieć, ale z drugiej – strasznie to irytuje.
W tym miejscu zawsze podaję przykład oprogramowania open source, które tworzone jest „po prostu”, bez zamawiającego i płacącego za nie klienta. I niestety 99% rozwiązań opensource’owych ma totalnie nieintuicyjne interfejsy, bardzo kiepski UX oraz jest obiektywnie gorsza od płatnych odpowiedników. Może więc ten klient po coś jest nam potrzebny?
Nie da się tworzyć wartościowego oprogramowania bez kogoś, na rzecz kogo pracujemy, bo wtedy nie bardzo wiemy, co tworzy tę „wartość„.
Tworząc software dla siebie powstaną fascynujące technicznie, ale nieużyteczne wodotryski. A skoro mamy do czynienia z ludzkim odbiorcą, to musimy zaakceptować to, że nie jest on w stanie przewidzieć przyszłości i wymagania będą się zmieniały. A co za tym idzie, najlepiej podążać agile’ową ścieżką. I dobrze by było, gdyby klient to rozumiał i zaakceptował.
Jak to jednak w życiu bywa, nic nie jest idealne. Często trafimy na kogoś, kto nie jest świadomy tego, jak przebiega rozwiązywanie złożonych problemów, czyli np. wytwarzanie oprogramowania.
Agile albo nic
W tekście „A co, gdy klient się myli?” podałem kilka przykładów na to, jak Product Owner może rozmawiać z klientem, który obstaje przy gorszym rozwiązaniu. Tu jednak mamy inną sytuację, bo różnice pojawiają się na szczeblu organizacyjnym. Nasz zamawiający nie jest zainteresowany metodykami agile, nie chce zmieniać wymagań i nie chce odbierać oprogramowania iteracyjnie. I co teraz?
Tradycyjne postępowanie w takiej sytuacji to eskalacja, czyli przeniesienie rozmów na poziom wyżej. Jeżeli dyrektor z ramienia klienta nie jest zainteresowany korzyściami płynącymi z podejścia zwinnego, to może zaciekawi się nimi prezes? Przecież wiemy jak wytłumaczyć, jaki jest cel zwinności (spoiler alert: bardziej użyteczny produkt i zadowolony klient).
Jeśli ceną za kilkukrotnie lepsze rozwiązanie jest poświęcenie czasu naszych pracowników na rzecz pracy w projekcie, to zwykle warto ją ponieść. Osoba odpowiedzialnie prowadząca biznes nie ma z tym problemu. To jest typowa ścieżka i typowe rozwiązanie tego problemu. Nie zawsze jest ono skuteczne. Przebijanie się przez strukturę organizacją potrafi być utrudnione zarówno w małych, jak i dużych firmach.
W wielkich korporacjach nikt nie ma na nic czasu i często trudno jest znaleźć właściwą osobę do rozmowy. Z kolei w małych firmach często mamy CEO, który wszystkie decyzje podejmuje jednoosobowo i „na żaden agile nie ma czasu”. A jeszcze gorzej wygląda sytuacja w przypadku zamówień publicznych, gdzie o elastycznej formie współpracy w ogóle nie ma mowy.
I co wtedy?
Waterfallowy klient, zwinni pracownicy
Jeżeli nie jesteśmy w stanie sformalizować naszej agile’owej współpracy, szukajmy innych rozwiązań. Tak jak pomysł na agile był odpowiedzią na takie, a nie inne warunki, tak i my nie powinniśmy załamywać rąk, tylko szukać pomysłów.
Jeśli używamy Scruma, powinniśmy przecież „adaptacyjnie rozwiązywać złożone problemy tak, by w produktywny i kreatywny sposób wytwarzać produkty o najwyższej możliwej wartości”. Nawet jeśli naszym „produktem” w tym przypadku jest forma współpracy z klientem.
Skoro nie możemy dogadać się „na górze”, to spróbujmy wypracować agile’ową formę współpracy bezpośrednio z zespołami, które mogą nam pomóc. SME, analitycy z ramienia klienta, kierownicy zamawiający funkcjonalności – to są osoby, które mogą poświęcić nam czas. Mogą razem z nami pracować zwinnie nawet, jeśli klient jest waterfallowy.
Bardzo często najbardziej pomocni będą docelowi użytkownicy systemu. To oni mają skin in the game, bo będą używać tego, co zostanie wytworzone. Dlatego jeśli pokażemy im, że ich uwagi są implementowane, a nie ignorowane, powinni być więcej niż chętni do pomocy. Szczególnie gdy rozwiązanie pierwotne odbiega od ich oczekiwań.
Wcale nie wymaga to zapraszania tych osób do siebie. Agile Manifesto mówi, że „Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu” i idealnie byłoby, gdyby osoby biznesowe siedziały u nas. Ale podgrywanie komuś nowych funkcjonalności, wysyłanie propozycji rozwiązań i telefony to coś, co każdy waterfallowy klient może zaakceptować.
Waterfallowy klient nie musi być zewnętrzny. To może też być osobny dział bądź pion w naszej firmie. Podejdźmy do niego dokładnie w ten sam sposób, zwłaszcza, że zapraszanie go do siebie zwykle jest o wiele łatwiejsze.
I pamiętajmy, że taki sposób myślenia powinien przejawiać się zawsze – również na Sprint Retrospective. Nigdy nie zwalajmy winy na czynniki zewnętrzne, zawsze zastanawiajmy się „co my możemy w tej sytuacji zrobić”.
Bo jakieś rozwiązanie można znaleźć zawsze.
