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 punkt 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 dużo 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 też proces selekcji tego, co zrealizowane zostanie.

Cel

Kluczowe jest ustalenie celu, jaki chcemy osiągnąć. Metody zwinne nie są „innym sposobem na robienie tego, co robiliśmy dotychczas”, ani nie pozwolą „robić więcej lub szybciej tego, 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ć.

A gdy już określimy cel, jaki chcemy osiągnąć dzięki Agile, warto zastanowić się, co jest miarą jego osiągnięcia 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ę.

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ąć? 

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, odkryjemy 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 problemami, jakie nas otaczają.

Artykuł Metody zwinne w dużych projektach pochodzi z serwisu CRN.

Na początek trzeba zastanowić się, czym jest wspomniany „kulawy Scrum”. Jest wybrakowany lub niekompletny? Jeśli tak, czego w nim brak i jakie są tego skutki? A może reguły obowiązujące w organizacji uniemożliwiają poprawne użycie Scruma? Jeśli tak, co jest niemożliwe i jak wpływa to na efektywność działania zespołów scrumowych?

Pierwszy scenariusz jest taki: dziś faktycznie nie da się użyć Scruma poprawnie, bo organizacja przez lata ułożyła się pod zupełnie inny sposób działania, niemożliwy do zmiany z dnia na dzień. A ponieważ nie możemy lub nie chcemy robić rewolucji (której organizacja mogłaby nie przetrwać), potrzebujemy czasu. Inaczej mówiąc: wiemy, co robimy nieefektywnie i szukamy sposobu, by to zmienić – co być może wymaga gruntownej przebudowy kultury całej organizacji.

Jeśli ten proces (dążenia do zmiany i jej wprowadzania) nie jest pozorny, i jeśli faktycznie dążymy świadomie do tego, by działać lepiej (i liczymy na to, że im bliżej „poprawnego Scruma” się znajdziemy, tym większe odniesiemy korzyści), to wcale nie jest „kulawy Scrum”. Jest marny, może bardzo marny, ale to właśnie jest Scrum: iteracyjne i inkrementalne rozwijanie produktów i zespołów (szerzej: organizacji), by lepiej przekuwać możliwości ludzi i zasoby firmy na coś, co daje wymierne korzyści.

To, że uwiera nas robienie czegoś „niezgodnie z definicją”, to dobrze – powinno uwierać, bo wtedy dążyć będziemy do zmiany status quo. Natomiast to nie jest powód, by samobiczować się stwierdzeniami o „kulawym Scrumie”.

Zróbmy listę tych rzeczy, które wymagają zmian i usprawnień najpilniej, a następnie zajmijmy się nimi po kolei – poczynając od tego, co najważniejsze, albo co da najlepsze efekty, eksperymentując, dzieląc duże problemy na małe kawałki tak, by łatwiej było sobie z nimi radzić… Brzmi znajomo? Tak, dokładnie tak buduje się produkty z użyciem Scruma. Nie ma powodu, by tego samego podejścia nie użyć do budowania zwinnej organizacji.

Po co nam ten Scrum…

Możemy niestety odkryć coś mniej budującego: ktoś nakazał użycie Scruma, ale nikt nie ma rzeczywistych intencji z niego korzystać ani wysilać się, by zrobić to dobrze. Zanim przejdę dalej, krótka dygresja: ten scenariusz nie jest tożsamy z sytuacją, w której jakaś firma podjęła decyzję o użyciu Scruma na zasadzie kultu cargo – z nadzieją, że mechanistyczne „wdrożenie” procesu z automatu przyniesie korzyści. Taki scrumowy kult cargo zazwyczaj wygląda z zewnątrz bardzo poprawnie i trzeba zdrapać kilka warstw z fasady, by zobaczyć, że to wszystko pozory (brak empiryzmu, brak przejrzystości itd.). Tym samym scrumowy kult cargo rzadko bywa oskarżany o bycie „kulawym Scrumem”. Za to dużo częściej bywa „dowodem na to, że Scrum nie działa”.

Jeśli nie uda się wykrzesać chęci użycia Scruma, niewiele z tym można zrobić. Sytuacja nie jest beznadziejna, ale prawie zawsze problem trzeba rozwiązywać poza zespołem Scrum. Żadne szamańskie tańce dookoła Developerów, pohukiwanie na nich i szkolenia nie zmienią faktu, że ludzie nie chcą robić czegoś, czego się od nich oczekuje. Nie chcą, bo być może nie ma to sensu (wtedy poszukajmy innej metody), albo też nie rozumieją powodów, dla których Scrum w ich kontekście jednak sens ma (wtedy dajmy im ten powód).

Co zatem robić?

Co zrobić, będąc Product Ownerem w takiej sytuacji? Zadbać o dobrą definicję swojego produktu – tak, żeby wiedzieć, po co jest robiony, jaki sens jest w jego efektywnym budowaniu, jakie korzyści to daje, jakie są koszty i skutki braku tej efektywności. Kto wie, może uda się uzyskać źródło zaangażowania dla ludzi i przesuniemy się do tego pierwszego scenariusza. Wciąż będzie trudno, bo zderzymy się z różnymi ograniczeniami organizacji, ale przynajmniej będziemy realnie dążyć do zniesienia tych ograniczeń.

Ale może też się okazać, że nasz produkt… nie ma w ogóle sensu. Albo że nikt w organizacji nie ma realnych intencji czegokolwiek zmieniać, a samo wprowadzenie metod zwinnych jest tylko grą pozorów – bo „wypada być Agile”. Wtedy sytuacja może być beznadziejna, o ile nie uda nam się przebić „w górę” i uzyskać choćby minimalnego wpływu na sposób działania organizacji. Czasami jedynym sposobem, by zacząć robić coś sensownego, jest przejście do innej firmy. Bo, wbrew tym, którzy oferują „przeprowadzenie transformacji zwinnych w każdej organizacji”, nie wszędzie da się uzyskać choćby podstawową zwinność.

Artykuł Problem „kulawego Scruma” pochodzi z serwisu CRN.