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, dodanie „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 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 „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 ten, w którym ktoś ma władzę, by faktycznie nakazać „myślenie zwinne” i użyje swoich możliwości, bo dokonać rewolucyjnej 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 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 większa frustracja i obawy, a tym samym większe ryzyko, że taka „transformacja” wymsknie się spod kontroli.

Dlatego warto zadać sobie zupełnie inne pytanie 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. Przekonać do „myślenia Agile” brzmi dla mnie 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 Agile, 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 zwinnie” mogą coś osiągnąć. A to prawie zawsze nieprawda.

Podejście zwinne (rozumiane jako użycie empiryzmu do osiągania celów) 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 właściwie 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 im 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 koncept, 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 za mało dokładnej analizy poprzedzającej rozpoczęcie prac. Zamiast sięgnąć po metody zwinne, będą dążyć do czegoś dokładnie odwrotnego: poświęcenia jeszcze więcej czasu na „dobre przygotowanie zespołów do pracy”, precyzyjne zdefiniowanie tego, co ma być zrobione oraz 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 są błędne – co zapewne jest możliwe, ale jest strategią co najmniej ryzykowną. Mogą ucierpieć relacje z „biznesem”, zmuszamy też wszystkich do coraz bardziej czarno-białego postrzegania rzeczywistości (na zasadzie: Agile jest dobry, 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żą potencjalne obszary, gdzie użycie empiryzmu pozwalałoby osiągać więcej, ograniczyć ryzyko, zebrać feedback wcześniej, wyprzedzić konkurencję itd. Potwierdzą, że faktycznie, „biznes” dość 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 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 faktycznie 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, bo dokonywać znaczących zmian w organizacji.

W praktyce oznacza to, że nie udało się „biznesu” przekonać, choć istnieje 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 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. Ale niekoniecznie 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 procesu.

Przykład: wielu Project Managerów tak zarządza swoimi projektami, żeby uzyskać maksymalną swobodę odnośnie do zmian 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, gdyby brakło czasu na zrobienie wszystkiego, projekt nie zakończył się katastrofą. Wciągają interesariuszy w proces na tyle, jak dalece mogą, by na długo przed końcem prac potwierdzić, że projekt nie rozminie się z ich potrzebami.

Czy to brzmi znajomo? Tak, ci Project Managerowie instynktownie robią to, co czyniłby 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 dość, że nie oznaczałoby rewolucji, to 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 Project Managerowie po niego sięgają.

Oczywiście nie muszą to być wyłącznie projekty i ich managerowie. W każdej większej organizacji prowadzonych jest wiele różnych inicjatyw: budowane są nowe 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 podeście zwinne jest niezbędne „biznesowi” — być może nie, wtedy nie warto po niego sięgać i stosować na siłę. Ale może jest tak, że co prawda Agile nie jest niezbędny (bo i tradycyjnymi metodami organizacja radzi sobie nieźle), natomiast użycie metod zwinnych dałoby lepsze rezultaty, większą responsywność w stosunku do potrzeb rynku, niższe ryzyko biznesowe itd. Wtedy wciąż się opłaca użyć metod Agile.

Do niektórych ludzi trafiają 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 pozostają głusi na takie argumenty, ponieważ wiążą z pracą zwinną obawy, które te wszystkie potencjalne korzyści przesłaniają. Mogą bać się, że stracą swoją pozycję w organizacji. Mogą spodziewać się utraty kontroli nad przebiegiem rozwoju produktów lub usług, za które odpowiadają. Mogą też kojarzyć Agile z chaosem i anarchią (np. są przekonani, że Developerzy w Agile 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. Takich obaw może być mnóstwo.

Warto poznać te lęki i odpowiedzieć na nie. Nie powtarzaniem komunałów o tym, że będzie inspekcja i adaptacja, więc będzie super, ale konkretnymi przykładami 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 tak, by zobaczyli, że to istotnie działa.

Jedną z częstych obaw „biznesu” jest strach przed rewolucyjną zmianą, którą wymusi zastosowanie metod zwinnych. Strach ten ma zwykle źródło w przekonaniu (utrwalanym przez niedouczonych „propagatorów Agile”), że taki np. Scrum musi być użyty albo superpoprawnie, 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 i podejściami, dopóki nie są sprzeczne z empiryczną kontrolą procesu. Można zacząć z „kulawym” Agile, byleby dążyć do jego uzdrowienia z determinacją i w sposób świadomy.

Nie chodzi przy tym o wykrzywianie idei Agile, ale o przemyślaną strategię wprowadzania kolejnych zmian, które pozwalają coraz lepiej z empiryzmu korzystać. Np. podniesienie przejrzystości, zwiększenie swobody decyzyjnej zespołów, zidentyfikowanie wartościowych celów, być może przedefiniowanie samych produktów i ich wizji. Wiele z takich zmian da się wprowadzić, niekoniecznie wykrzykując na prawo i lewo, że to po to, aby pracować zwinnie. Warto uzyskiwać akceptację dla efektów (i wykreować pożądanie, by pojawiły się kolejne), niż dla haseł, które niewiele z początku znaczą i nic nie dają.

„Biznes”, czyli kto?

Warto też przede wszystkim dobrze poznać swój „biznes”, np. produkt i jego interesariat. Bo tak naprawdę nie ma czegoś takiego, jak „biznes”, dlatego ciągle zapisuję to w cudzysłowie. Są 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 musimy szanować), tym łatwiej nam będzie do czegokolwiek ich przekonać.

Niektórzy Product Ownerzy mają problem ze swoim „biznesem”, ponieważ właściwie traktują go bezosobowo — bardziej jako dział firmy, albo jakiś zbiór ról w firmie, niż konkretne osoby. To błąd, bo wtedy tak naprawdę nie wiadomo, z kim rozmawiać. Jak rozmawia się z działem firmy? Jakie potrzeby i obawy ma ten dział? Rozmawiać trzeba z konkretnymi pracownikami tego 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 ani o sposobie pracy. 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 pracą zespołu.

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 tak 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 (ale nie faktyczny) zyskał realną władzę.

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. To spowoduje, że przekonywać do Agile będzie właściwe osoby, a potem z właściwymi osobami rozmawiał będzie o produkcie.

Nie tylko „biznes”

Jeśli chcemy korzystać z metod zwinnych, by osiągać wartościowe cele, nie możemy skupić się na szeroko rozumianym „biznesie” (jak zresztą pisałem, nie ma czegoś takiego – są konkretni ludzie). Przyjmijmy, że „biznesem” są ludzie odpowiedzialni za produkty, usługi i strategię firmy. 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 biznesowo, jak i technologicznie. Są wreszcie zarządzający organizacją na różnych poziomach – od kierowników liniowych do kadry zarządzającej (CEO, COO, CFO itd.).

Skupienie w dyskusji o użyciu metod zwinnych tylko na „biznesie” może okazać się błędem, jeśli pominiemy całe otoczenie, w jakim ów „biznes” działa. 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 mającej dział IT. 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 superprzewidywalne, 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”. Wtedy też pojawi się presja na to, żeby zmusić tych ludzi do „myślenia Agile”, a uczestnicy tych działań (Scrum Masterzy, Product Ownerzy), postawieni przed takim celem, pytać będą na szkoleniach, jak mają to zrobić…

Po trzecie, moim zdaniem najważniejsze: zwinność jest miarą zdolności ciągłej 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 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 właściwie 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 Kanbana. Tymczasem są dziesiątki metod zwinnych, zarówno zarządczych (takich jak Scrum), jak i technicznych (np. TDD). Co więcej, te metody można łączyć ze sobą w dowolnych konfiguracjach, o ile robimy to świadomie, wychodząc od celu, jaki chcemy osiągnąć.

Wybierając metody, pamiętajmy, że one powinny 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ć, i sposób potwierdzenia, że faktycznie jest to osiągane. Tylko wtedy unikniemy „myślenia Agile” bez realnych korzyści, na rzecz działania Agile (a dokładniej: 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 niekoniecznie środowisko, w jakim są stosowane, jest idealne. Inaczej mówiąc niekoniecznie od pierwszego dnia Scrum lub Kanban, jakiego użyjemy, musi być idealny. W praktyce prawie zawsze na początku będzie „kuleć”, a organizacja (zespoły i ich otoczenie) będą szukać sposobu, by tę „kulawiznę” zredukować, a najlepiej usunąć całkowicie. Dopóki to dążenie do lepszego działania jest trwałe, organizacja i jej „biznes” ma szansę na osiągnięcie coraz większych korzyści z użycia metod Agile.

Zdjęcie: Paul Skorupskas