Po dłuższej przerwie wracam z nowym artykułem z serii pytań i odpowiedzi, do których inspirują mnie dyskusje, jakie prowadzę 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ć).

Produkt czy projekt

Na początek warto zastanowić się, o czym tak naprawdę mówimy. Czy faktycznie 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, który ma pozwolić na kreowanie wartościowych odpowiedzi na zmieniające się potrzeby 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 po prostu poczynione z góry plany, to naszą intencją raczej nie będzie ich zmienianie, by dostosować się do bieżącej sytuacji. Zrobimy to, jeśli nie będzie wyjścia, minimalizując zakres tego dostosowania.

W drugim przypadku (nazwijmy go rozwojem produktu albo ogólnie rozumianej wartości), 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 zrealizowane zostanie.

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 to pozwolić osiągnąć. Metody zwinne nie są „innym sposobem na robienie tego, co robiliśmy dotychczas” ani nie pozwolą „robić więcej lub szybciej to samo, co robimy dzisiaj za wolno, albo w zbyt małej ilości”. Zwinność to w istocie sztuka skutecznego wybierania, co warto zrobić i robienia tego jak najszybciej. Dzięki temu, choć zrobimy dużo mniej, to co potrzebne i wartościowe pojawia się szybciej.

A zatem do czego takich mechanizmów chcemy użyć? Bo jeśli chodzi wyłącznie o „efektywniejsze zarządzanie projektami”, to właściwie możemy sobie od razu powiedzieć, że żadnej zwinności nie uzyskamy. Użycie metod Agile, jeśli po nie sięgniemy, może spowodować poprawę samego procesu wytwarzania rozwiązań, ale to jeszcze nie świadczy o zwinnym działaniu. Żeby o nim mówić, empiryzm musi działać nie tylko na poziomie wytwórczym, ale również (albo przede wszystkim) na poziomie decyzji odnośnie do tego, co będziemy wytwarzać.

Miary

Gdy już określimy cel, jaki chcemy osiągnąć dzięki Agile, warto zastanowić się, co jest miarą jego osiągania i zdefiniować, jak chcemy te miary sprawdzać:

  • jak często i kto je będzie sprawdzał,
  • jakie wartości są oczekiwane,
  • co świadczy o tym, że idziemy w dobrą stronę.

Z obserwacji tych miar i wyciągając z nich wnioski, możemy świadomie sterować procesem, jakim się posługujemy. Przy czym miary 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 to 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 polega na czymś innym. To ciągły proces, w którym poszukujemy, jak 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 pomaga i 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. 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, konteksty, narzędzia itd. – wtedy musimy nasz plan działania („backlog”) dostosowywać. Bo 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 coś nie bardzo 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. Theory of Constraints, 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 czy Lean. 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. Ta wyjątkowość bardzo rzadko jest faktem, 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 żadnych 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 umiejętność szybkiego zmieniania składu Zespołów tak, by nadążyć za tą zmiennością. 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 nam 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ą.

Dlatego między bajki możemy włożyć przekonanie, że „zaplanujemy” zwinne Zespoły z góry. 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ż uda się uruchomić proces stawania 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 zabił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. Jeśli traktować będą je jako coś, co „trzeba zrobić”, to ich 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.