.st0{fill:#FFFFFF;}

Dla kogo jest ta cała zwinność? 

 4 listopada, 2020

Łukasz Bręk

Nie macie wrażenia, że dziś nikt nie osiąga obiecanych przez „agile mindset” korzyści? Dla kogo jest ta cała zwinność? Kto z niej korzysta, a kto powinien? I dokąd to wszystko zmierza?

 

Wszystko jest dla ludzi

Pomysł na temat naszedł mnie wczoraj w nocy. Kładłem się spać i przypomniałem sobie wpis, który widziałem na LinkedIn jakiś czas temu. Konkluzją tamtego wpisu było pytanie, dla kogo jest ta cała zwinność? No i zacząłem się zastanawiać.

Wszystko jest, jak zwykle, dla ludzi. Faktycznie, zwinność będzie implementowana przez wszystkie możliwe strony zaangażowane w wytwarzanie produktu. Tak jest dzisiaj. Zastanawiałem się jednak, jak to było w momencie, gdy zwinność powstawała. Krótki rzut oka na Agile Manifesto czy legendę o jego podpisaniu daje możliwość stwierdzenia, że tworzyli go deweloperzy dla deweloperów. Czy na pewno?

Zastanawiając się dalej doszedłem do wniosku, że tak samo jak możemy stwierdzić, że powstał dla deweloperów, możemy stwierdzić, że jest dla biznesu. Wszak nacisk położony na informacje zwrotne, ścisłą współpracę czy zadowolenie klienta jasno wskazuje na to, że i ten kij ma dwa końce.

Kto więc najwięcej zyskuje na zwinnym podejściu?

 

Zespół Deweloperski

Nie przez przypadek rozpocząłem właśnie od Zespołu Deweloperskiego. Dziś dla części z nich czysty Scrum jest kulą u nogi. A przecież na początku tak nie było. Scrum był nowym podejściem, dzięki któremu mogli robić rzeczy fajne, w nowy, ciekawy sposób, gwarantujący większe powodzenie całego przedsięwzięcia niż przy wykorzystaniu podejścia klasycznego. Większe prawdopodobieństwo wdrożenia produktu w akceptowalnym kształcie to większa motywacja do codziennej pracy.

Co więc poszło nie tak. Wydaje się, że dziś dużo większy nacisk kładzie się na część „zarządzania” a nie część dewelopowania produktu. Można powiedzieć, że z punktu widzenia Zespołów Deweloperskich ważniejsza jest otoczka (narzędzia?), a ich samych zepchnięto do bycia osobami odpowiedzialnymi za „wydewelopowanie tego, co zostało powiedziane”. W nowoczesnej zwinności nie ma często śladu po samoorganizacji czy krossfunkcjonalności. Są za to przeszczepy, które powodują, że cała ta zwinna praca traci sens.

Nie bez znaczenia jest również nastawienie części deweloperów. Klasyczne „będę pracował tak jak chcę i chodził tylko na spotkania, które mi się podobają” jest wciąż spotykanym nastawieniem. I psują one podejście zwinne w całej organizacji, zgodnie z dobrze nam znaną Broken window theory.

 

Zarządzanie wszystkim

Scrum Master, Product Owner, Project Manager,  Product Manager, PMO. To tylko niektóre z ról, które zarządzają projektem. Pewnie moglibyśmy ich wymienić wiele więcej.

Możemy też przywołać równie popularne macierzowe ujęcie organizacji, gdzie z jednej strony naszym przełożonym jest Product Owner, a z drugiej Team Lead bądź jakaś rola techniczna. Nie ma się co dziwić takim próbom znalezienia pracy dla middle managementu, w końcu Scrum skupia się na rozwoju produktu, a nie na projekcie. Ale nie ma się też co dziwić irytacji deweloperów, że więcej jest ludzi od zarządzania niż od pracy. Co więcej, pokutuje myślenie, że zanim za coś będę się mógł „wziąć”, musi to przejść swoistą ścieżkę zdrowia.

Przerost struktur zarządzających jest jednym z tych elementów, które odzierają zwinne organizacje ze… zwinności. Samoorganizacja zespołów staje się mitem, a możliwość decydowania o sposobie rozwiązania często czysto iluzoryczna. Za wszystkimi decyzjami stoją między innymi ludzie, o których mowa powyżej.

Chciałbym jednocześnie pokreślić, że wspomniane role są często niezbędne aby skutecznie prowadzić zwinny projekt. Nie powinny jednak ingerować w proces dewelopmentu i samoorganizację zespołów.

 

Klient

Ostatnim uczestnikiem procesu, jest klient. Myli się ten, kto myśli, że z klientem będzie najprościej.

Możemy ich z grubsza podzielić co najmniej na dwie grupy – klienta angażującego się i tego, którego produkt aż do momentu podjęcia decyzji o go-live nie będzie on interesował. Ten pierwszy jest klientem modelowym. Szybka informacja zwrotna, bieżące testy czy wsparcie Zespołu Deweloperskiego to tylko nieliczne z aktywności, jakie podejmuje.

W przypadku klienta nieangażującego się mamy sytuację wręcz odwrotną. Brak informacji zwrotnej, wysyłanie na Sprint Review niedecyzyjnych osób, które odpowiedzialne są tylko za zapisanie każdego padające tam słowa, testy dopiero na UAT-ach i słynne „jeśli chcecie pomocy w rozwiązaniu niejasności, zapraszam do siebie”.

Zupełnie inaczej sytuacja ma się z klientem zewnętrznym. Ten czasem nawet nie wie, że Zespół pracuje zwinnie. Jeśli wie, to znaczy, że był gotowy na ten sposób pracy i że najczęściej będzie aktywnie uczestniczył w rozwoju produktu.

 

Dla kogo jest ta cała zwinność?

Wymieniłem trzy strony zaangażowane w zmianę, które w teorii mogą i powinny korzystać ze zwinnego podejścia, jednak często tego nie robią. To trzy strony, którym zwinne podejście powinno dać przewagę i wymierne korzyści. Dlaczego tak się więc nie dzieje? Dlaczego rozpisując powyższe przypadki miałem wrażenie, że nikt tej zwinności nie chce? Czemu nikt nie potrafi z niej skorzystać i osiągnąć swoich celów?

Wydaje mi się, że właściwej, jasnej odpowiedzi nie ma. Mógłbym zaryzykować stwierdzenie, że wszyscy powyżej wymienieni uczestnicy procesu powinni na nim korzystać. Ale często nie chcą. Brak czasu, brak zaufania, brak bezpiecznego środowiska, brak odwagi do działania w inny sposób odciska swoje piętno na efektach „zwinności”. Możemy i musimy to zmienić.

Podzielcie się proszę Waszymi obserwacjami w tym temacie. Zostawcie komentarz bądź napiszcie bezpośrednio do nas. Jestem ciekawy, czy moje przemyślenia w tym temacie są tylko moją błędną interpretacją rzeczywistości, czy może regułą, którą musimy zmienić. Bo jeśli Wy macie podobne odczucia, to czas na zmianę.

Łukasz Bręk


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.

  1. Ciekawy temat i przemyślenia. Podrzucę kilka moich obserwacji z punktu widzenia managera. Jeżeli chodzi o zespół deweloperski to tym jak jest organizowana praca w projekcie interesuje się może jeden na 10 programistów (to i tak dobrze). Dla pozostałych jest wszystko jedno czy to będzie Scrum, Kanban czy Prince of Persia2. Młodzi programiści są przeważnie wystraszeni i ich celem jest doskonalenie umiejętności programowania, i wręcz oczekują że inni będą im mówili co mają robić. Regularzy są zajęci walką z merge konfliktami, niestabilnym CI i tworzeniem architektury. Nikt z nich nie zna bólu pracy w metodzie klasycznej gdzie przed Releasem trzeba było przygotować pudełko antydepresantów, bo trafili w takie czasy że gdzie by już nie poszli to trafią na jakąś formę Scruma. W przypadku dużych organizacji Scrum jest wprowadzany przeważnie jako lepsza forma planowania pracy, bo łatwiej planować mniejsze odcinki czasu i łatwiej monitorować postępy (zamykanie zadań), i też łatwiej też zespołowi produktowemu dorzucić coś do backlogu bo się przypomniało i coś usunąć, bo klient się wycofał. Taka forma Agile jest dla dużej organizacji wystarczająca, to i tak jest dla niej rewolucja. Klienci nie rozumieją Agile, można im co tydzień coś podsyłać, a oni pokiwają głowami, ale nie uruchomią, bo nie mają na to czasu, uruchomią jak będzie właściwy release. Mowa tu głównie o dużych klientach, gdzie bezwładność wprowadzania nowej wersji produktu jest tak duża, że dostawca pracujący zwinnie nic im w temacie nie zmienia. Agile bardzo dobrze rozumieją startupy, które chcą szybko zacząć zarabiać i zdobywać rynek nowymi pomysłami. Na to wszystko nakłada się brak głębokiego zrozumienia czym tak naprawdę jest Agile, ja się tym zajmuje wiele lat i ciągle mnie coś w tym temacie zaskakuje. Wielu Scrum Masterów jest tak zabieganych wprowadzaniem podstawowych mechanizmów Scruma (np. pilnowania czasu Daily i czy każdy się odezwał) że nawet nie widzą sensu jakiś górnolotnych rozważań czy to Daily w ogóle miało jakiś sens. Wydaje mi się że wszystkie te strony nie widzą większego zysku w tym by obecny Scrum w ich firmie był bardziej Agile, bo nawet nie wiedzą co to znaczy. To tak w skrócie. Pozdrawiam na weekend 🙂

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