Po dłuższej przerwie wracam z nowym artykułem z serii inspirowanej dyskusjami z uczestnikami szkoleń, jakie prowadzę. Dziś zajmę się „wdrażaniem” Agile w dużych firmach i postaram się podpowiedzieć, od czego zacząć (i od czego nie zaczynać).

Projekt czy rozwój produktu

Na początek warto zdefiniować, jaki jest charakter inicjatywy, w której „wdrożona” miałaby zostać zwinność. Czy mowa o projekcie, czyli tymczasowym przedsięwzięciu o z góry określonych celach, mniej lub bardziej precyzyjnie zdefiniowanych z góry? Czy raczej o długotrwałym procesie rozwoju jakiegoś produktu lub usługi, dostarczającym odpowiedzi na zmieniające się potrzeby interesariuszy tak długo, jak jest to opłacalne?

W pierwszym przypadku (projekt) możemy zapewne posłużyć się mechaniką zwinną, ale im więcej decyzji podejmiemy z góry, im bardziej detalicznie zdefiniujemy punk końcowy (czyli to, co ma powstać), tym mniejsze szanse na uzyskanie dużych korzyści z działania zwinnego, o ile w ogóle będzie ono możliwe. Jeśli bowiem realizować będziemy poczynione z góry plany, to raczej nie będziemy ich ochoczo zmieniać, by dostosować się do bieżącej sytuacji. Zrobimy to, jeśli nie będzie wyjścia, minimalizując zakres wprowadzonych adaptacji.

W drugim przypadku (nazwijmy go rozwojem produktu), działanie zwinne ma zdecydowanie większy potencjał i jeśli będziemy umieli go zastosować, przyniesie wymierne korzyści. Jakie? Eliminację marnotrawstwa, redukcję ryzyka inwestycyjnego, większą wartość tego, co wytwarza organizacja, dzięki lepszemu dopasowaniu do zmieniających się potrzeb. Inaczej mówiąc, w tym przypadku zwinność nie ograniczy się do samego procesu wytwórczego (jak przy „zwinnym realizowaniu projektów”), ale obejmie również proces selekcji tego, co zostanie wytworzone.

W wielu organizacjach pojęcia produkt i projekt funkcjonują jako synonimy (niesłusznie), dlatego warto zastanowić się, o co w rozważanej inicjatywie chodzi i do tego dobrać najlepszy sposób działania (metody, Zespoły itd.).

Cel

Kluczowe jest ustalenie celu, jaki ma zostać osiągnięty dzięki zwinności. Trzeba też odpowiedzieć sobie na pytanie, czy chodzi o jego osiągnięcie jednorazowo, czy raczej o zdolność dokonywania tego wielokrotnie i powtarzalnie. Przykładem celu jednorazowego może być wytworzenie na czas rozwiązania zgodnego z oczekiwaniami klienta, który je zamówił. Natomiast celem, który trzeba osiągać ciągle na nowo, jest wytwarzanie produktu w taki sposób, by najpierw zdobył on silną pozycję na rynku, a potem był w stanie ją utrzymywać.

Ustalony i zrozumiały dla wszystkich cel umożliwia dobór adekwatnych narzędzi i praktyk, którymi posługiwać się będzie organizacja i jej Zespoły. Z celu wynikać powinien również wybór konkretnej metody zwinnej lub całego ich zestawu.

Zwracam uwagę, że żadna z metod Agile nie nadaje się do optymalizacji masowej produkcji dóbr fizycznych lub wirtualnych. Procesy tego typu dążą przede wszystkim do uzyskania maksymalnej wydajności przy zachowaniu niskich kosztów i akceptowalnej jakości tego, co jest wytwarzane. Nie chodzi w nich o poszukiwanie nowych rozwiązań czy dostosowaniu ich do zmiennej rzeczywistości, ale o maksymalną powtarzalność i eliminowanie marnotrawstwa (bo ono generuje straty).

Zwinność nie polega na zdolności wytwarzania szybko i w dużej ilości tego, co jest dobrze zdefiniowane, ale przede wszystkim to umiejętność skutecznego i szybkiego wybierania, co warto zrobić i robienia tego tak szybko, by w międzyczasie nie zmieniły się potrzeby. Inaczej mówiąc, nie chodzi o to, by zacząć robić więcej tego samego, co zawsze, tyle że szybciej i w inny sposób, ale by zacząć robić to, co jest potrzebne i nie tracić czasu na rzeczy zbędne. Dzięki temu, choć zrobimy dużo mniej, to co wartościowe pojawia się szybciej.

Czy sensownym celem użycia metod Agile może być efektywniejsze zarządzanie projektami? Wszystko zależy od tego, czym są owe projekty. Jeśli nazwa ta stosowana jest jako synonim inicjatywy biznesowej i może kryć się pod nią wszystko, to do wielu tak rozumianych projektów zwinne podejście będzie doskonale pasować.

Natomiast jeśli mowa o klasycznych projektach, ciężko wyobrazić sobie dobrze działającą hybrydę podejścia zwinnego z nimi. Wynika to z rozbieżności zasad, jakie obowiązują w metodykach projektowych i tych zwinnych. Projekty mają sens, gdy można przewidywać długoterminowo, co da się zrobić i co przyniesie korzyści. Agile korzysta z empirycznej kontroli procesu wytwarzania wartości wszędzie tam, gdzie przewidywanie i planowanie długoterminowe jest nieskuteczne. Decydując się na „zwinne realizowanie projektów”, organizacja deklaruje, że funkcjonuje w środowisku, które jest jednocześnie dostatecznie przewidywalne i nieprzewidywalne…

Miary

Gdy już określimy cel, jaki chcemy osiągnąć dzięki Agile, warto zastanowić się, co jest miarą jego osiągnięcia (lub osiągania) i zdefiniować, jak chcemy zdefiniowane miary sprawdzać. Trzeba ustalić:

  • Jak często i kto je będzie sprawdzał?
  • Jakie wartości miar są oczekiwane?
  • Co świadczy o tym, że idziemy w dobrą stronę?

Obserwując miary i wyciągając z nich wnioski, możemy bardziej świadomie sterować procesem, jakim się posługujemy. Przy czym konkretne wartości miar nie powinny być nigdy celem samym w sobie, bo wtedy przestają być przydatne do usprawniania procesów i zaczynają je skutecznie wypaczać.

Ewolucja nie projekt

Kolejna sprawa: nie da się „wdrożyć metod zwinnych”, bo to implikuje przeprowadzenie czegoś na kształt projektu, gdzie na koniec będzie można ogłosić sukces i orzec, że „od teraz firma jest zwinna”. Pamiętajmy, że zwinność to umiejętność reagowania na zmiany, a te pojawiają się nieustannie. Jeśli założymy, że potrafimy zdefiniować z góry, co to znaczy zwinny i zaplanujemy, jak i kiedy taki stan osiągniemy – to już ponieśliśmy klęskę, zanim w ogóle ten nasz projekt zaczniemy realizować. Dlaczego? Bo postępując w skrajnie niezwinny sposób, nie da się nauczyć zwinnego działania, a bez tej umiejętności ciężko mówić o zwinności, czyż nie?

Poprawne użycie metod zwinnych to ciągły proces, w którym poszukujemy sposobu, by lepiej korzystać z empiryzmu przy podejmowaniu decyzji i realizowaniu ich. Nie da się stworzyć uniwersalnej recepty, jak zacząć, a co dopiero mówić o próbie określenia stanu docelowego. Prawdę mówiąc, przekonanie o tym, że istnieje jakiś stan docelowy, jest pierwszym sygnałem, że chyba nie rozumiemy istoty empirycznej kontroli procesu i jej zastosowania do radzenia sobie ze złożonymi problemami.

Zwinne stawanie się zwinnym

Dlatego, gdy już określimy cel, jaki chcemy osiągnąć (albo osiągać) za pomocą Agile, i gdy mamy już zdefiniowane miary, którymi chcemy mierzyć jego osiąganie, przeanalizujmy:

  • Co najbardziej potrzebne jest do osiągnięcia tego celu?
  • Co zrobić, by to coś się pojawiło?
  • Co utrudnia osiągnięcie celu?
  • Co zrobić, by te utrudnienia usunąć?
  • Co pomaga w osiągnięciu celu?
  • Jak wzmocnić to, co nam pomaga i jak najlepiej to wykorzystać?

Z tych rozważań wyłoni się lista rzeczy, o które trzeba zadbać (problemów, procesów, narzędzi, kompetencji itd.). W krótkich interwałach, oceniając regularnie, czy uzyskujemy właściwe efekty, pracujmy nad tymi rzeczami. Dokładnie tak, jak buduje się złożony produkt. Iteracyjnie i inkrementalnie (przyrostowo).

Oczywiście w miarę, jak będziemy posuwać się do przodu, odkrywać będziemy nowe problemy, możliwości, narzędzia itd. – wtedy musimy nasz plan działania dostosowywać. Gdybyśmy z uporem trzymali się pierwotnych zamysłów, realizując je w klasyczny projektowy sposób, od pewnego momentu będziemy na pewno szli w złą stronę, rozmijając się z realiami środowiska i problemów, jakie nas otaczają.

Konsekwencja w eliminowaniu utrudnień

Istnieją gotowe metody, z których możemy skorzystać. Scrum jest jedną z nich, ale niejedyną. Jeśli się na niego zdecydujemy, upewnijmy się, że go rozumiemy i bądźmy gotowi na ogromne trudności w pierwszych Sprintach. To nie Scrum je wygeneruje, tylko uczyni je boleśnie widocznymi – one już są w naszej organizacji. Nie mówmy zatem, że „u nas Scrum nie działa”. Jeśli marnie działa, to zapewne organizacja jest bardzo niedojrzała lub nieefektywna (a może obie te rzeczy na raz) i widząc to, możemy coś z tym zrobić. Jeśli będziemy w tym konsekwentni, z czasem będzie lepiej.

Zamiast odrzucać metodę, szukajmy sposobu, by co Sprint działać lepiej. I celem wcale nie będzie uzyskanie dobrego Scruma, ale doprowadzenie do tego, żeby móc użyć dobrego Scruma i skonsumować korzyści, jakie to daje. Organizacja, która to potrafi (w której Scrum może bez trudu być zastosowany), prawie zawsze jest efektywna i skuteczna w tym, czego się podejmuje. I niemal bez wyjątku jest skuteczniejsza i bardziej efektywna od konkurencji, która zwinnie działać nie potrafi, a również zmaga się ze złożonymi problemami.

Są inne metody (np. Extreme Programming, Crystal), inne podejścia (np. teoria ograniczeń, Lean), są też różne strategie, po jakie możemy sięgnąć (np. Kanban). Używajmy ich świadomie, podobnie jak opisałem to powyżej na przykładzie Scruma. Żadne z tych podejść, metod, frameworków czy metodyk nie jest gotową receptą, a jedynie ramą, która musi być wypełniona praktykami, ciężką pracą, kontekstem organizacji. Im lepiej organizacja (jej Zespoły) to robią, tym lepsze efekty uzyskują.

A to oznacza, że nie trzeba być idealnym, by móc użyć metod Agile. Trzeba być pragmatykiem i dążyć do usuwania deficytów z organizacji, zamiast obrażać się na rzeczywistość, jaką ujawniają te metody i arogancko twierdzić, iż istnieje jakaś metoda, której użycie udowodni, że nic nie trzeba w organizacji zmieniać.

Innym objawem arogancji, o którą możemy się potknąć, jest przekonanie o wyjątkowości sytuacji, w której znajduje się określony Zespół lub cała organizacja. Z jednej strony to truizm, bo każdy Zespół jest z definicji wyjątkowy – każdy jest przecież inny. Z drugiej strony faktyczna wyjątkowość tego, co robi Zespół i samego Zespołu, zdarza się niezmiernie rzadko, za to przekonanie o niej zdarza się wyjątkowo często. I jest wymówką, by uznawać nieefektywność i marnotrawstwo za coś akceptowalnego.

Zespół

Zwinne działanie (i każde inne również) nie przyniesie korzyści bez kompetentnych Zespołów. Przyjmując, że korzystamy z empiryzmu, bo zmagamy się z niestabilną złożonością (czyli funkcjonujemy w środowisku o dużej zmienności i nieprzewidywalności), zdecydowanie utopią jest zbudowanie Zespołów dobranych idealnie do tego, co będą miały one do zrobienia. Być może na początku da się to zrobić, jeśli skutecznie przewidzimy, w jaką stronę potoczą się sprawy. Szybko okaże się jednak, że kompetencje Zespołów rozjeżdżają się z tym, co muszą one aktualnie robić.

Miarą zwinności w tym przypadku nie będzie bynajmniej umiejętność szybkiego zmieniania składu Zespołów. Wątpliwe, czy dałoby się to robić skutecznie – prawdopodobnie cały czas bylibyśmy w tym procesie o krok za rzeczywistością, która nieustannie by uciekała. Realną miarą zwinności będzie zdolność Zespołów do nabywania kompetencji, uczenia się nowych praktyk, stosowania nowych narzędzi i zmiany sposobu pracy tak, by radzić sobie ze zmiennością środowiska, w jakim funkcjonują.

Między bajki można włożyć przekonanie, że da się zaprojektować i zbudować Zespoły odporne na każdą zmianę albo że da się do takich zmian Zespoły skutecznie dostosowywać na bieżąco. Stwórzmy je najlepiej, jak potrafimy i pozwólmy empiryzmowi działać. Jeśli faktycznie składy Zespołów będzie trzeba zmienić, one same zauważą to najszybciej i poinformują o takiej potrzebie organizację. Pomijając dużo większą elastyczność takiej struktury i jej zdolność do dostosowywania się do aktualnego stanu spraw, da to członkom Zespołu poczucie wpływu na środowisko, w jakim pracują, a to jest jednym z głównych źródeł zaangażowania.

Zwinność nie jest dana na zawsze

Na koniec przestroga. Gdy już uruchomiony zostanie proces stawania się coraz bardziej zwinnym, może on po pewnym czasie się zatrzymać. Dlaczego? Bo braknie woli do dalszej zmiany. Bo „już jest dobrze”. Bo cel się zdezaktualizował, a nikt nie wyznaczył nowego. Bo popełniliśmy błędy, które zniweczyły wszystko to, co udało się do tej pory osiągnąć, więc ludzie stracili wiarę w sens i motywację do działania.

Dlatego ważne jest, by cele były naprawdę wartościowe, znane i by w procesie cały czas uczestniczyli zaangażowani liderzy. I by cele, do których osiągnięcia dąży organizacja, były autentycznie ich celami. Niezdrowe podejście do zarządzania działaniami podległej im części organizacji szybko zakazi Zespoły. A bez zaangażowanych ludzi tak Agile, jak i żadna inna metoda (również klasyczna) nie ma szans zadziałać dobrze i nie daje wymiernych korzyści.