Kilka lat później, kiedy słuchałem opowiadania jednego z menedżerów firmy produkcyjnej z branży tworzyw sztucznych, o wdrożeniu u nich metodyki SCRUM, przypomniał mi się obraz malucha opisującego wonsza. W opowiadaniu menedżera prawie nic się nie zgadzało z założeniami metodycznymi, ale było dużo pasji, zaangażowania i wewnętrznego przekonania, że właśnie znalazł idealne rozwiązanie na wszystkie bolączki firmy. Cóż, nie miałem serca burzyć jego wyobrażeń, ale z drugiej strony nie mogłem przejść nad tym obojętnie – przed sobą miałem dojrzałą osobę a nie kilkulatka. Spokojnie, bez zbędnych emocji, metodycznie i powoli zaczęliśmy sobie „odhaczać” ważne elementy metodyki SCRUM i okazało się, że wdrożony w firmie sposób działania zawiera ich niewiele. Widziałem niezadowolenie na twarzy menedżera, któremu wyraźnie podobało się określenie SCRUM i było synonimem nowoczesnego podejścia do realizacji projektów. Czym teraz będzie imponował swoim kolegom? Jak to nazwać? Czy w ogóle wypada tak działać?

No właśnie, podobnie jest z całym obszarem zwinnego zarządzania projektami. Wiele osób wysnuwa wyobrażenie o działaniu zgodnie z metodykami AGILE na podstawie semantycznego znaczenia słowa zwinny: „wykonujący szybkie, zręczne ruchy” ,  „o ruchach, poruszaniu się kogoś lub czegoś: szybki i zgrabny”[1] lub określeń bezpośrednio w języku angielskim: "able to move your body quickly and easily", "able to think quickly and clearly". Przy czym w  słowniku Cambridge Dictionary[2] znajdziemy już określenia bardziej odpowiadające biznesowej rzeczywistości "able to deal with new situations or changes quickly and successfully" lub już zupełnie blisko "used for describing ways of planning and doing work in which it is understood that making changes as they are needed is an important part of the job". Krótko mówiąc, w wyobraźni wielu osób, zwinne zarządzanie projektami to osiąganie celów bez tej całej „metodyki, głupiej papierologii, bezsensownego planowania i ograniczających procesów” i, żeby było ciekawiej, w wielu przypadkach cele można osiągnąć w taki właśnie sposób. Podobnie, jak można mówić prozą nie mając o tym zielonego pojęcia, nie znając definicji prozy.

No to jak właściwie wygląda ten wąż?

Wszystko zaczęło się w świecie programistów, którzy poszukiwali szybszej, łatwiejszej, bardziej efektywnej drogi realizacji projektów. Tradycyjne metodyki, których założenia powstawały w latach 40, a pierwsze próby opisania i usystematyzowania to lata 60 XX wieku, zaczęły ciążyć zespołom, od których oczekiwano szybkiego realizowania zadań i reagowania na dużą ilość zmian w założeniach. Doprowadziło to do spotkania grupy 17 osób[3], zajmujących się programowaniem, w dniach 11-13 lutego 2001 w Snowbird ski resort w stanie Utah. Dyskutowali, co zrobić, żeby ich praca była bardziej efektywna i przynosiła zadowolenie zarówno im, jak i odbiorcom ich prac[4]. W wyniku dyskusji powstał słynny „Manifest programowania zwinnego”, który brzmi tak:

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić:

Chciałbym zwrócić uwagę, na ostatnie zdanie manifestu, które wyraźnie podkreśla (a nie przekreśla) znaczenie działania procesowego, używania narzędzi zarządczych, dokumentowania, negocjowania, realizacji planów.

Na podstawie tak zdefiniowanych czterech wartości (które okazały się bardziej uniwersalne niż się to początkowo wydawało) powstało 12 pryncypiów zwinnego programowania[6]:

1. Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesne i ciągłe dostarczanie cennego oprogramowania.
2. Akceptujemy zmieniające się wymagania, nawet na późnym etapie rozwoju produktu. Zwinne procesy zmiany pozwalają na stworzenie warunków zadowolenia klienta.
3. Dostarczaj działające oprogramowanie często, od kilku tygodni do kilku miesięcy, preferując krótszy czas.
4. Ludzie biznesu i programiści muszą współpracować codziennie przez cały czas trwania projektu.
5. Buduj projekty wokół zmotywowanych osób. Stwórz warunki do pracy i wspieraj ich, aby dobrze wykonali swoją pracę.
6. Najbardziej skutecznym i efektywnym sposobem przekazywania informacji do i z zespołu programistów jest rozmowa twarzą w twarz.
7. Działające oprogramowanie jest podstawową miarą postępu projektu.
8. Zwinne procesy promują zrównoważony rozwój. Sponsorzy, deweloperzy i użytkownicy powinni mieć możliwość utrzymywania stałego tempa rozwoju.
9. Ciągła dbałość o doskonałość techniczną i dobry design zwiększa zwinność.
10. Prostota - sztuka maksymalizacji ilości prac niezbędnych.
11. Najlepsze architektury, opis wymagań i projekty rozwiązań powstają w samoorganizujących się zespołach.
12. W regularnych odstępach czasu zespół zastanawia się, jak stać się bardziej skutecznym, a następnie odpowiednio poprawia i dostosowuje swoje zachowanie.

Przy odrobinie dobrej woli, i niewielkich zabiegach edytorskich, na podstawie tak zapisanych pryncypiów można stworzyć zasady bardziej uniwersalne, nieodnoszące się do tworzenia oprogramowania. Próby takiego podejścia zostały opisane w „Agile Practice Guide[7]”, gdzie wprowadza się pojęcia „myślenia zwinnego” (agile mindset).

Ciekawe, co właściwie może pójść nie tak?

Użyję tutaj ulubionego określenia konsultantów – „to zależy”. Tych zmiennych wpływających na poprawne działania (lub nie) modelu „Agile” jest bardzo dużo. Wymienię tylko niektóre:

• Dojrzałość organizacji
• Stopień skomplikowania procesów zarządczych
• Przyzwyczajenia zespołów
• Motywacja pracowników
• Umiejętności pracy w zespole samostanowiącym
• Wielkość zespołu
• Oczekiwania klientów
• Konieczność dostarczania produktów na określony czas
• Konieczność ścisłej realizacji budżetów.

Tych czynników można wypisać naprawdę długą listę, ale chciałbym zwrócić uwagę na element, który się powtarza – ludzie. W książce „Agile – szybciej, łatwiej, dokładniej[8]” autor zwraca uwagę na „czynnik ludzki”. Krótko mówiąc, bez świadomego zespołu, ludzi posiadających umiejętności pracy w zmiennym środowisku, osób niebojących się podejmowania decyzji, kreatywnych, odpowiedzialnych – wdrożenie metodyk zwinnych po prostu się nie uda. Niestety, osoby podejmujące decyzję o użyciu metodyk zwinnych często o tym zapominają. Sam byłem świadkiem próby uruchomienia projektu SCRUM z zespołem przyzwyczajonym do bardzo procesowego działania i ścisłego podziału obowiązków i odpowiedzialności. Jeszcze długo będę pamiętał minę programisty, od wielu lat przyzwyczajonego do realizacji zadań w oparciu o wcześniejszą pracę analityka, od którego nagle oczekiwano współpracy z klientem biznesowym. Ta osoba po prostu nie chciała (lub nie potrafiła) rozmawiać z klientem końcowym, w pewnym momencie usłyszałem „Wiesz co, porozmawiaj z nimi, opisz mi dokładnie, co mam zrobić, daj mi miesiąc - ja siądę i to zrobię.” No i po zwinności.

Oczywiście, to nie jest sytuacja powszechna. Wiele osób chętnie przystaje na zasady stosowane w zespołach samostanowiących i angażuje się w pracę widząc w tym możliwości rozwoju i spełnienia swoich zawodowych oczekiwań.

Problem „ludzki” nie dotyka tylko pracowników. Należy mocno podkreślić znaczenie zrozumienia i chęci użycia metodyk Agile przez menadżerów w tym kierowników projektów. Z moich obserwacji wynika, że menadżerowie wyższych szczebli, działający na pewnym poziomie abstrakcji, łatwiej akceptują możliwość użycia metodyk zwinnych. Największy opór przed używaniem tych metodyk widziałem u kierowników projektów, z wieloletnim stażem w dużych organizacjach. „Większość menadżerów projektów była przyzwyczajona do postrzegania metodyki jako bardzo dobrze zdefiniowanych, kompletnych i dobrze zintegrowanych z narzędziami i praktykami potrzebnymi do ich obsługi [9]”.  W przypadku Agile tak nie jest, jest dużo większa tolerancja używania narzędzi zarządczych. Podczas jednej z dyskusji, po spotkaniu w ramach seminarium PMI, usłyszałem wręcz opinię „ … ten cały Agile to inna nazwa dla chaosu w projekcie”. Po tym stwierdzeniu rozgorzała bardzo emocjonalna dyskusja, która nie zakończyła się konsensusem. Zwolennikom zwinnego zarządzania projektami (do których również się zaliczam) nie udało się przekonać przeciwników. Po spokojnym przenalizowaniu argumentów w użytych w dyskusji, niestety już bez obecności adwersarzy, uświadomiłem sobie, że wpadłem w pułapkę, którą można nazwać „agile jest dobry, bo jest dobry”. Przecież nie wszędzie trzeba ( a wręcz w niektórych sytuacjach nie powinno się) używać metodyk zwinnych.

Podsumowując ten krótki artykuł, zanim podejmiesz decyzję o użyciu danej metodyki, dokonaj analizy zarówno organizacji jak i istoty zadań projektowych. Podejmij wysiłek zapoznania się z podstawowymi zasadami metodyki i nie używaj jej „na siłę”, bo możesz zrobić więcej złego niż dobrego.
____