Tytułowe pytanie często zadają mi Scrum Masterzy i Product Ownerzy. Krótka odpowiedź: nie zmuszać, ponieważ nic to nie da. Sposób myślenia każdego z nas wynika z przekonań lub ewentualnie obaw przed konsekwencjami nieposłuszeństwa względem kogoś, kto ma nad nami władzę. To samo dotyczy biznesu – o ile nie mamy nad nim władzy (a Product Ownerzy mają ją rzadko, Scrum Masterzy zaś praktycznie nigdy), żadne zmuszanie nie wchodzi w grę. A nawet, gdyby było możliwe, nie miałoby sensu.

Wprowadzenie na siłę podejścia Agile w najlepszym razie skończy się użyciem arbitralnie wybranej metody zwinnej (jednej z wielu) i posługiwanie się nią w sposób mechanistyczny, dający nikłe lub żadne korzyści organizacji. Zmiana ograniczy się do nazwania starych praktyk, ról, artefaktów i zdarzeń po nowemu, dodania „obowiązkowych elementów wymaganych przez metodę”, których brakowało wcześniej i odtrąbiony zostanie sukces. W praktyce nic się nie zmieni, a z empiryzmu jak nie korzystano przed „wdrożeniem Agile”, tak dalej się nie będzie korzystać.

Piszę, że to najlepszy z możliwych scenariuszy wprowadzania zwinności na siłę, ponieważ istnieje duża szansa, że organizacja nie ucierpi na nim za bardzo. Owszem, poniesie koszty tzw. transformacji, ale ponieważ nie zmieni istotnie sposobu działania, a wcześniej jakoś była w stanie w ten sposób względnie skutecznie działać, powinna zachować te zdolności.

Dużo gorszym scenariuszem jest taki, w którym ktoś ma władzę, spróbuje nakazać „myślenie zwinne” i użyje swoich możliwości, bo wymusić rewolucyjne zmiany. Niewątpliwie daje to duży potencjał na osiągnięcie ogromnych korzyści, pod warunkiem, że przy okazji nie zostanie rozwalona sama organizacja, jej produkty, pozycja rynkowa, ciągłość operacji itd.

Ludzie zmuszeni, by „myśleć zwinnie”, mogą podejmować działania całkiem spójne z podejściem Agile, jednocześnie fundamentalnie nie zgadzając się z potrzebą postępowania w ten sposób. Im większy jest rozziew między przekonaniami ludzi i tym, co muszą robić, tym bardziej rosną frustracja i obawy, a tym samym i ryzyko, że sprawy wymkną się spod kontroli.

Dlatego warto zadać sobie zupełnie inne pytanie (to poniżej) i poszukać na nie dobrej odpowiedzi.

Jak przekonać biznes do użycia Agile?

Zamiast o „myśleniu zwinnym” piszę o użyciu Agile, ponieważ wszystkie zwinne metody są narzędziami. Przekonywanie do „myślenia Agile” to trochę tak, jakby przekonywać kogoś do „myślenia młotkiem”. Tak, ja wiem, że Agile to też pewna filozofia działania, ale w praktyce sprowadza się ona do zastosowania empirycznej kontroli procesu, a poszczególne metody i praktyki to narzędzia, których należy świadomie użyć.

Jest drugi, ważniejszy powód, dla którego wzdragam się przed przekonywaniem kogokolwiek do „myślenia zwinnego”. Agile nie jest przecież celem, ale drogą do osiągania celów. Dużo sensowniej jest w mojej ocenie przekonywać do użycia Agile po to, by te cele osiągać.

Przyjęcie właściwej perspektywy w dyskusji z biznesem (i w sumie z kimkolwiek, kogo chcemy przekonać do zastosowania empiryzmu), jest kluczowe. Jeśli wychodzić będziemy z pozycji ewangelisty, istnieje duże prawdopodobieństwo, że zlekceważymy obawy rozmówców i okażemy brak szacunku dla ich przekonań, na podstawie których działają obecnie. Inaczej mówiąc, damy im do zrozumienia, że popełniają błąd, nie „myśląc Agile” i zasugerujemy, że jedynie „myśląc Agile”, mogą coś osiągnąć. A to prawie zawsze nieprawda.

Podejście zwinne (rozumiane jako użycie empiryzmu do osiągania celów w złożonym środowisku) nie zawsze jest potrzebne. A jeśli jest potrzebne, to nie oznacza z definicji, że inaczej pracować się nie da. Owszem, korzyści będą mniejsze, ryzyko niepowodzenia dużo wyższe, ale Agile nie musi być oczywistym i jedynym wyborem.

Czym jest empiryzm i kiedy jest potrzebny?

Aby przekonać biznes do użycia empiryzmu, trzeba po pierwsze wyjaśnić, czym ten empiryzm w praktyce jest. Dopiero wtedy ma jakikolwiek sens pójście dalej i zdefiniowanie, czym jest zwinne działanie w kontekście organizacji takich jak ta, w której funkcjonuje ów biznes (np. czym jest zwinny rozwój produktu albo zwinne świadczenie usług klientom).

Kluczowym jest tutaj upewnienie się, że biznes rozumie, kiedy podejście Agile może dać korzyści, czyli czym jest niestabilna złożoność, którą okiełznać można z użyciem empirycznej kontroli procesu. Częstym błędem jest założenie, że to są rzeczy oczywiste – nie, nie są, z reguły trzeba to wyjaśnić.

Niewykluczone, że efektem naszych wysiłków będzie utwierdzenie się biznesu w przekonaniu, że Agile jest zbędny – czyli coś dokładnie przeciwnego, niż chcieliśmy osiągnąć. Dlaczego tak się może stać? Nie dlatego, że rozmówcy źle zrozumieli ideę, ani nie dlatego, że nie uważają tego podejścia za faktycznie skuteczne w radzeniu sobie z niestabilną złożonością. Po prostu nie sądzą oni, że w ich przypadku taka niestabilna złożoność występuje.

Skąd takie przekonanie? Najczęściej z wiary, że nieprzewidywalność w ich organizacji (w ich biznesie) jest wynikiem albo zaniedbań ludzi, albo niewystarczającej analizy przed rozpoczęciem prac. Zamiast sięgnąć po metody zwinne, będą dążyć do czegoś dokładnie odwrotnego: poświęcenia jeszcze większej ilości czasu na „dobre przygotowanie projektów”, precyzyjne zdefiniowanie tego, co ma być zrobione oraz kuloodpornego planu działania.

Czy biznes zmaga się z niestabilną złożonością?

Ci, którzy postawili sobie za cel przekonanie biznesu do „myślenia Agile”, na tym etapie często próbują wykazać rozmówcom, że ich oceny stopnia złożoności spraw są błędne. To nie musi się udać, a grozi popsuciem relacji z biznesem. Łatwo też popaść w fundamentalizm polegający na rysowaniu czarno-białego obrazu rzeczywistości, w którym Agile jest dobry, a wszystko inne złe.

Pragmatycy przekonujący biznes do użycia Agile zgodzą się z opiniami rozmówców („tak, skutecznie działacie”), po czym wskażą obszary, gdzie użycie empiryzmu pozwalałoby potencjalne osiągać więcej, ograniczyć ryzyko, zebrać feedback wcześniej, wyprzedzić konkurencję itd. Przyznają, że biznes całkiem dobrze przewiduje różne rzeczy i potrafi się do nich przygotować, ale robi to za cenę kosztownych analiz, odłożenia w czasie rozpoczęcia prac, ciężkiego procesu zarządzania ryzykiem i monitorowania stanu spraw.

Wynikiem tych dyskusji jest czasami uznanie, że faktycznie biznes nie zmaga się z niestabilną złożonością i empiryzm nie przyniesie większych korzyści – wtedy dalsze przekonywanie do użycia metod zwinnych nie ma zapewne sensu.

Czasami (niezbyt często) samo uświadomienie sobie problemu złożoności wystarczy do zmiany sposobu działania biznesu, który sięgnie po empiryzm jako narzędzie – już nie trzeba będzie go dalej przekonywać, bo sam będzie się domagał, by zastosować metody Agile.

Najczęściej jednak dyskusja utknie na obopólnym zrozumieniu, że co prawda poziom niepewności jest duży i potencjalnie Agile mógłby pomóc sobie z nim lepiej radzić, ale nie jest na tyle wysoki, by po metody zwinne sięgać. Mogą paść rozmyte deklaracje, że w przyszłości na pewno tak się stanie, ale teraz nie jest to najlepszy moment, by dokonywać znaczących zmian w organizacji.

Osiągnięcie stanu zawieszenia oznacza, że nie udało się biznesu przekonać. Istnieje jednak duża szansa, że teraz ludzie ci rozumieją, czym jest zwinne działanie. Ta wiedza pozwoli im w przyszłości samodzielnie dostrzec obszary, w których użycie empiryzmu dawałoby szansę na uniknięcie wielu problemów lub lepsze poradzenie sobie z nimi. Być może wystarczy poczekać, aż to przekonanie zacznie być na tyle silne, by stali się otwarci na zmianę sposobu działania. Niekoniecznie jednak musimy czekać biernie.

Dowody działania empiryzmu

Szukajmy obszarów, gdzie choćby w minimalnym stopniu empiryzm jest wykorzystywany, by pokazać efekty jego działania w praktyce. To, że w organizacji nie używa się metod zwinnych, nie znaczy, że całkowicie brak w niej empirycznej kontroli procesów.

Przykład: wielu kierowników tak zarządza swoimi projektami, żeby zachować maksymalną swobodę zmiany zakresu prac tak długo, jak tylko się da. Zaczynają od tego, co najbardziej ryzykowne, żeby mieć w razie czego dość czasu na dostosowanie, gdyby początkowe założenia się nie potwierdziły. Decydują, by najpierw robić to, co krytyczne, by w razie braku czasu na zrobienie wszystkiego projekt nie zakończył się katastrofą. Wciągają interesariuszy w proces, starając się na długo przed końcem prac potwierdzić, że projekt nie rozminie się z ich potrzebami.

Czy to brzmi znajomo? Tak, ci kierownicy projektu instynktownie robią to, co czyniłby np. Product Owner w Scrumie, choć oczywiście mają dużo bardziej związane ręce. Jeśli znajdziemy przykłady takiego działania, możemy ich użyć do przekonania biznesu, że użycie metod zwinnych nie oznaczałoby rewolucji, tylko usystematyzowałoby i uczyniło prostszym coś, co już i tak się dzieje. Ba, to byłby dowód na to, że w istocie empiryzm jest niezbędny, skoro kierownicy projektów po niego sięgają.

Oczywiście nie muszą to być wyłącznie projekty i ich kierownicy. W każdej większej organizacji prowadzonych jest wiele różnych inicjatyw: budowane są Zespoły, odkrywane nowe technologie, kreowane kampanie marketingowe itd. – prawie na pewno w mniejszym lub większym stopniu, aby w ogóle być w stanie coś osiągnąć, ludzie korzystają tam z empiryzmu, nawet o tym nie wiedząc.

Jeśli brak takich przykładów w organizacji, w jakiej funkcjonuje biznes (to mało prawdopodobne, ale niewykluczone), poszukajmy przykładów z innych firm działających w tej samej branży. Przy czym celem wciąż nie powinno być przekonanie biznesu, by użył czegoś tylko dlatego, że korzystają z tego inni. Chodzi o pokazanie, że dzięki użyciu metod Agile inni osiągają lepsze rezultaty niż ci, co trzymają się tradycyjnych metod (lub w ogóle działają chaotycznie) – oczywiście, jeśli tak naprawdę jest.

Korzyści dla biznesu

Wróćmy do oceny czy podejście zwinne jest niezbędne biznesowi – być może nie, ale nie oznacza to automatycznie, że metody Agile nie doprowadzą do lepszych rezultatów, wyższego poziom dostosowania do potrzeb rynku, obniżenia ryzyka inwestycyjnego itd. Wtedy wciąż się opłaca ich użyć.

Do niektórych ludzi trafiają takie argumenty o korzyściach i możliwościach, bo faktycznie ich celem jest uzyskanie jak najwięcej dla organizacji, w której funkcjonują. Gdy zobaczą, że da się działać efektywniej i że potencjalne korzyści mocno przeważają nad kosztami zmiany, zaangażują się w nią w pełni.

Inni kierują się przede wszystkim obawami, które przesłaniają wszystkie potencjalne korzyści płynące z pracy zwinnej. Mogą spodziewać się, że stracą silną pozycję w organizacji. Mogą bać się utraty kontroli nad przebiegiem rozwoju produktów lub usług, za które odpowiadają. Mogą być przekonani, że Agile to chaos i anarchia, bo Developerzy zaczną robić, co chcą, jak chcą i kiedy chcą. Bywa, że biznes boi się rewolucji, która rozwali to, co działa, nie dając szybko (albo w ogóle) nic w zamian.

Warto poznać te lęki i odpowiedzieć na nie. Oczywiście nie chodzi o powtarzanie komunałów o tym, że będzie inspekcja i adaptacja, więc będzie super, ale o pokazanie przykładów praktyk, które użyte w konkretnym kontekście jakiegoś problemu mogą (choć nie muszą, gwarancji przecież nie ma) dać lepsze rezultaty. Być może konieczne będzie nakłonienie biznesu do przeprowadzenia kilku eksperymentów w mniejszej skali celem sprawdzenia, że to istotnie działa.

Jedną z częstych obaw biznesu jest strach przed tym, że żadnej zwinności nie uda się osiągnąć mimo podjęcia ryzyka i poniesienia kosztów związanych z użyciem metod Agile. Strach ten miewa źródło w przekonaniu (utrwalanym przez niedouczonych „propagatorów Agile”), że taki np. Scrum musi być użyty albo perfekcyjnie, albo nie da żadnych korzyści. Tymczasem to nieprawda: Scrum da tym więcej korzyści, im poprawniej z niego korzystamy, ale ten kulawy też może je dać (choć oczywiście zależy to od poziomu i charakteru kulawizny).

Biznes powinien rozumieć, że metody zwinne to jedynie szkielety procesu – zbiory zasad i kluczowych elementów, które można dość swobodnie uzupełniać różnymi praktykami, dopóki nie są one sprzeczne z empiryczną kontrolą procesu. Można zacząć z kulawym Agile i nieustannie dążyć do jego uzdrowienia z determinacją i w sposób świadomy. Skoro każda kulawizna jest manifestacją istniejących ograniczeń, jej wyeliminowanie, jakkolwiek trudne i nierzadko czasochłonne, zawsze daje organizacji nowe możliwości.

Biznes, czyli kto?

Warto też przede wszystkim dobrze poznać swój biznes, np. produkt i jego interesariuszy. Bo tak naprawdę nie ma czegoś takiego, jak biznes, dlatego ciągle zapisuję to słowo kursywą. Są za to konkretni ludzie, mający różne potrzeby, obawy, sympatie, urazy itd. Mogą odrzucać Agile z racji złych doświadczeń z nim, mogą się go bać, mogą go nie rozumieć. Im lepiej potrafimy wczuć się w sposób myślenia i potrzeby tych ludzi (nie musimy ich lubić, ale powinniśmy szanować), tym łatwiej nam będzie do czegokolwiek ich przekonać.

Niektórzy Product Ownerzy mają problem ze swoim biznesem, ponieważ traktują go bezosobowo – jako dział firmy albo jakiś zbiór ról w organizacji, nie zaś konkretne osoby. To błąd, bo wtedy nie wiadomo, z kim rozmawiać. Jak ustalić coś z całym działem firmy? Jakie potrzeby i obawy ma ten dział? Rozmawiać trzeba z konkretnymi pracownikami działu, wybranymi tak, by faktycznie reprezentowali dobrze pozostałych.

Czasami kłopot sprawia to, że Product Owner nie ma dostępu do decydentów – w pewnym sensie dostaje polecenie zrobienia czegoś i niespecjalnie ma przestrzeń, by dyskutować o tym zleceniu i o sposobie pracy nad nim. Trzeba wtedy poszukać sojuszników, którzy poniosą w górę przekaz od Product Ownera. A najlepiej, by pomogli uzyskać możliwość bezpośredniej współpracy z decydentami. Najczęściej się to udaje, bo przecież organizacja nie po to daje komuś prawo decydowania o produkcie, żeby potem zredukować go do roli zarządzającego Backlogiem Produktu.

No, chyba że tak jest – wtedy warto porozmawiać z tym, kto ustanowił Product Ownera i uświadomić go, że dał Product Ownerowi jedynie formalny tytuł, ale praktyczne decyzje podejmuje kto inny. Może jest ku temu powód i da się coś zrobić, by to zmienić. Pierwszym krokiem wszakże musi być zrozumienie, kto naprawdę decyduje o produkcie, dopiero potem można podjąć dyskusję, czy i jak rozwój produktu mógłby zyskać, gdyby ten formalny Product Owner zyskał realną władzę, albo gdyby faktyczny Product Owner stał się nim również formalnie.

A bywa i tak, że interesariuszy jest po prostu zbyt wielu, a Product Owner nie rozmawia z właściwymi osobami – tymi, które mogłyby go też realnie wesprzeć we wprowadzeniu metod zwinnych. Product Owner, jeśli ma być skuteczny, musi wiedzieć, kim są kluczowi interesariusze i nawiązać z nimi na tyle bezpośrednią i stałą relację, w jakim stopniu to możliwe.

Nie tylko biznes

Jeśli chcemy korzystać z metod zwinnych, by osiągać wartościowe cele, nie możemy skupić się wyłącznie na szeroko rozumianym biznesie (jak zresztą pisałem, nie ma czegoś takiego – są konkretni ludzie). Jeśli tym biznesem są ludzie odpowiedzialni za produkty, usługi i strategię firmy, to czy tylko ich dotyczyć będzie zmiana, jaką spowoduje sięgnięcie po metody zwinne? Oczywiście, że nie.

Są różne Zespoły – w tym te wytwarzające produkty i usługi na rzecz biznesu albo utrzymujące te rozwiązania w działaniu. Są eksperci, którzy pomagają organizacji i jej Zespołom. Są ci, którzy starają się wytyczyć dla organizacji kolejne kroki, zarówno biznesowe, jak i technologicznie. Są wreszcie zarządzający organizacją na różnych poziomach – od kierowników liniowych do kadry zarządzającej (prezes, zarząd itd.).

Dyskusja o użyciu metod zwinnych może doprowadzić do katastrofy, jeśli pominiemy w niej całe otoczenie, w jakim biznes działa. Tworzą go między innymi Developerzy w Zespołach. Ich też trzeba przekonać, a nie zmusić do użycia metod zwinnych – o ile faktycznie mogą być dla nich przydatne. Warto to zrobić również dlatego, że mogą nam pomóc w dotarciu do biznesu i zachęceniu go do zmiany sposobu działania (albo chociaż do przeprowadzenia eksperymentu, który pokazałby, czy w metodach Agile jest jakiś realny potencjał).

Nie ma czegoś takiego jak „transformacja Agile”

„Transformacja Agile” to hasło, które zna każdy, kto pracował w jakiejkolwiek większej firmie wykorzystującej systemy informatyczne. Gdy poodwijamy wszystkie sreberka z tego hasła i wydłubiemy ze środka to, co tam się kryje, zostanie nam… projekt „wprowadzenia zwinności” do określonej daty. Tak rozumiane transformacje są z dużym prawdopodobieństwem skazane na niepowodzenie z wielu powodów (choć oczywiście niektóre dają na tyle pozytywne efekty, że da się je prezentować jako sukces).

Po pierwsze, jak można „wprowadzać zwinność” metodą projektową (pozbawioną empiryzmu), skoro nie da się z góry przewidzieć, jak ta „zwinność” (celowy cudzysłów) miałaby wyglądać? No, chyba że się da – ale to oznaczałoby, że wszystko jest możliwe do przewidzenia, więc… po co nam ta zwinność w ogóle?

Po drugie, taka transformacja prawie zawsze będzie przymuszać (mniej lub bardziej wprost) różnych ludzi do poddania się jej. W efekcie biznesowi i ludziom pracującym na jego rzecz różni „coachowie” (celowy cudzysłów) „zrobią Agile”. Pojawi się presja na „myślenie Agile”, a ofiary tych działań (Scrum Masterzy, Product Ownerzy) pytać potem będą na szkoleniach, jak mają to osiągnąć…

Po trzecie, moim zdaniem najważniejsze: zwinność jest miarą zdolności adaptacji, więc nigdy nie jest się stabilnie i ostatecznie zwinnym. Zwinność jest w praktyce ciągłym procesem, który nigdy się nie zatrzymuje. Transformacja natomiast jest przejściem od jednego stanu do drugiego – być może stanowi rewolucyjną zmianę dużej skali rozłożoną w czasie, ale kończącą się w pewnym momencie. Zwinność nie jest transformacją tak rozumianą; jest ewolucją, która nigdy się nie kończy.

Właściwe metody

Na koniec: istnieje wiele metod zwinnych, o czym wiele osób zapomina, sięgając z rozpędu po Scruma. Albo po Kanbana, jeśli ktoś jest przekonany, że to jedna z metod zwinnych (ani to metoda, ani tym bardziej zwinna). Te dziesiątki metod zwinnych, zarówno zarządczych (takich jak Scrum), jak i technicznych (np. test-driven development, w skrócie TDD), można też łączyć ze sobą w dowolnych konfiguracjach.

Wybierając metody, pamiętajmy, że ich zastosowanie nie powinno być celem samym w sobie. To narzędzia do osiągania celów. Musi być znana odpowiedź na pytanie, co użycie konkretnej metody zwinnej ma dać. Musi też dać się potwierdzić, że wytyczone cele faktycznie są osiągane. Tylko wtedy odejdziemy od „myślenia Agile” bez realnych korzyści w stronę użycia metod Agile do uzyskania korzyści.

Nie zapominajmy też, że metody zwinne są tak zdefiniowane, by dawać korzyści również wtedy, gdy środowisko, w jakim są stosowane, jest dalekie od ideału. Inaczej mówiąc, w praktyce prawie zawsze na początku metody te będą kuleć, a organizacja (Zespoły i ich otoczenie) szukać będą sposobu, by tę kulawiznę zredukować, a najlepiej usunąć całkowicie. Dopóki dążenie do lepszego działania jest trwałe, organizacja i jej biznes mają szansę na osiągnięcie coraz większych korzyści z użycia metod Agile.