Dla kogo jest ta cała zwinność?

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

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: