.st0{fill:#FFFFFF;}

Elastyczność bierze się z prostoty 

 4 lipca, 2023

Tomasz Dzierżek

Wiele firm i organizacji sięga po podejście zwinne (agile) z niezrozumiałych powodów. Niektóre próbują zwiększyć efektywność, przyspieszyć tworzenie rozwiązań, skrócić mityczny time-to-market. Są też tacy, którzy szukają elastyczności. Ale czy ją znajdą?

 

Po co komu agile?

Jeszcze w 2019 roku, w początkach naszego bloga, popełniłem tekst „Jaki jest cel zwinności?„. W nim zaś śmiało korzystałem zarówno z własnych doświadczeń, jak i z Agile Manifesto. I wszystko sprowadza się do tego, że pracując zwinnie, skupiamy się na zadowoleniu klienta. Można to oczywiście ubierać w takie słowa jak „wczesne i ciągłe dostarczanie wartościowych produktów”, „ścisła współpraca z odbiorcami/biznesem”, „częste wdrażanie”, itd. Koniec końcow, w początkach zwinności, było ono odpowiedzią na nieprzewidywalność i nieadekwatność (niską wartość) dużych projektów informatycznych.

Skoro już przywołuję historię, to warto wspomnieć, że myśli dotyczące powodów „bycia agile” są z nami cały czas. Pod koniec 2022 roku nagraliśmy i opublikowaliśmy „statement”, w którym przyznajemy bez ogródek, że „Firmy wcale nie chcą być agile„. Bo nie chcą. Nawet pomijając fakt, że „firma” jako byt nic nie chce, bo nie żyje, to podejście zwinne nie jest im do niczego potrzebne. Ludzie w firmach chcą osiągać lepsze wyniki, zarabiać więcej, dostarczać szybciej. Mało kto, poza fanatykami Scruma bądź zwinności, ustawia sobie jako cel „być agile”.

Jest jednak wiele miejsc, gdzie zwinność bierze się jako odpowiedź na problem pod tytułem „chcemy być bardziej elastyczni”. No i wtedy się zaczyna…

 

Skąd się bierze elastyczność?

Elastyczność wcale nie bierze się ze zwinności. Po prostu często osoby, które zarządzają w sposób zwinny i reprezentują agile mindset, budują wszystko w taki sposób, aby elastyczne było. To trochę kwestia przyczyn, skutków i rzeczy zupełnie nieskorelowanych.

Patrząc na profesjonalnych sportowców, możemy czasami wyciągnąć błędne wnioski odnośnie tego, co jest potrzebne do osiągania takich wyników. Swego czasu wszyscy byli pod wrażeniem diety Michaela Phelpsa, który podobno przyjmował ponad 10 tysięcy kalorii dziennie. Każdy jednak wie, że to nie jest droga do zostania wielokrotnym mistrzem olimpijskim. Co więcej, nie jest to nawet kierunek! Chcąc poprawić swoje wyniki w czymkolwiek, nie będziemy przecież obżerać się „bo tak robią najlepsi”. I podobnie jest z tą elastycznością. To, że wiele ekstremalnie elastycznych przedsięwzięć działa w sposób zwinny, to nie znaczy, że jest to niezbędne.

Jeżeli mowa o firmach i organizacjach, to elastycznym (i zwinnym) się jest, albo nie. Jest to spektrum i można znajdować się na nim w różnych miejscach. Zwykle jednak po krótkiej rozmowie z kimkolwiek jesteśmy w stanie stwiedzić, czy w tym miejscu jest jakikolwiek ślad elastyczności i/lub zwinności. Jeżeli zmiana zakresu wymaga zgody 20 osób i komitetów, jeżeli za jedną rzecz odpowiada 10 managerów, jeżeli mamy osobny proces na dodanie wymagania do backlogu i zupełnie inny na jego usunięcie, to od razu wiemy, że nie będzie tu mowy o elastyczności.

 

Znów te procesy i narzędzia…

Tak, jak nie da się wprowadzić innowacji przez „godziny na innowacje” czy „departament innowacji”, tak samo nie da się wprowadzić elastyczności przez procedury i narzędzia. Niektórzy traktują jednak proces Scrum, bądź w ogóle zwinność, jak te 10 tysięcy kalorii Phelpsa. „Jak wprowadzimy Scrum, to będziemy bardziej elastyczni.” I zupełnie zapominają o tym, że budżet akceptowany jest na cały rok z góry, a okienka wdrożeniowe są co 6 miesięcy. W takich warunkach żaden proces i żadne narzędzie nie pomoże.

Miejsca w których ktoś próbuje wdrażać podejście zwinne („transformacja agile„) ze złych powodów borykają się z wieloma problemami, które same tworzą. Nie tylko dlatego, że postawiony cel („wdrażać szybciej”, „pracować efektywniej”) jest niezgodny z duchem zwinności. Równie istotna jest przecież zgodność nastawienia do warunków i całej organizacji.

Jeżeli chcemy być elastyczni, to zasad i procedur nie może być dużo. Co więcej, muszą one uwzględniać zmienność i nie mogą nas usztywniać. Najbardziej elastyczne jest „róbta co chceta”, ale wtedy oczywiście trudno o jakieś efekty. Stąd zasady się przydają – ale powinno ich być jak najmniej. Można by wręcz powiedzieć, że powinniśmy mieć ich tak mało, jak to tylko możliwe i powinny być one jak najprostsze.

 

Prostota i pragmatyzm prowadzą do elastyczności

Jednym z moim ulubionych pytań w kontekście zwinności jest „Co się stanie, jeśli tego nie zrobimy?„. To pytanie towarzyszyło mi zawsze przy pracy nad wymaganiami, ale też towarzyszy mi przy podejmowaniu decyzji. Jako szczególarz i perfekcjonista na odwyku często odpowiedź na „Co się stanie…?” brzmi „będę się czuł niekomfortowo”. Jeśli to są jedyne potencjalne konsekwencje, to czasami warto się przemęczyć.

Pragmatyzm, czyli robienie tylko tego co potrzeba i niczego więcej, to prosta droga do uwolnienia czasu i innych środków. Naturalnie prowadzi to do większej elastyczności – możemy śmiało postanowić, że robimy coś innego. W podobny sposób działa prostota, której świetnym przykładem jest Zespół Scrumowy.

Scrum Team to mały zespół rozwijający jeden produkt, bądź nawet jeden aspekt danego produktu. Posiada jedną osobę, która wie co chce osiągnąć i jasno to komunikuje. Prace toczą się w krótkich okresach, a założenia są często sprawdzane przez wypuszczanie nowszych wersji. To bardzo prosty mechanizm, który sam siebie reguluje i – jeżeli tylko mu pozwolić – dostarcza efekty.

Zespół pięciu osób z dziesięcioma managerami różnego szczebla daleki jest od prostoty. Podobnie jeśli mamy osobne zespoły wdrożeniowe, testerskie, akceptujące pracę, osobny proces testów deweloperskich i osobny na UAT-y, procedurę wdrożenia do akceptacji i akceptacji wdrożenia. Scrum Teamy działają dobrze nie dlatego, że są scrumowe, ale przede wszystkim dlatego, że są proste i mają jasno określone zasady i granice.

Jeżeli więc ktoś chce zwiększyć elastyczność organizacji, zacznijmy od uproszczenia struktury, pozbycia się większości zasad i pragmatycznego podejścia do wymagań. Niech ludzie skupią się na (dobrej) robocie. Przecież dokładnie to robimy, kiedy projekt jest już po terminie. A skoro wierzymy, że to jest droga do jego uratowania, to dlaczego nie chcemy tak działać od samego początku?

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}