blog.testowka.pl

Z zaszłości historycznych, a w niektórych krajach (w tym także w Polsce) również z powodu norm prawnych często wynika problem związany z brakiem zdefiniowanej struktury zarządzania w organizacjach wytwarzających oprogramowanie w sposób zwinny. Agile stawia na podstawowe wartości i równość każdego człowieka/członka zespołu. Iluzja posiadania władzy nad drugim człowiekiem jaką często mają managerowie w organizacjach kultywujących tradycyjne podejście do zarządzania prowadzi często do niepotrzebnych konfliktów i niezmiernie de-motywuje pracowników.

W Agile nie ma managerów, którzy mogli by komuś kazać coś robić. Zamiast zdalnego zarządzania poprzez ścisłą kontrolę w Agile stawia się na coachów i trenerów, których zadaniem jest pilnowanie przestrzegania zasad i usuwanie przeszkód stojących na drodze do efektywnej pracy developerów oraz przede wszystkim wspieranie każdego pracownika w ciągłym polepszaniu swoich umiejętności.

Osoby ściśle przywiązane do określonej struktury, w której do tej pory ktoś mówił im co mają robić (często także jak mają to zrobić i ile mają na to czasu) mają problem z tym, by samemu zorganizować swój czas i by pracować nad zwiększaniem swojej efektywności.

Kolejnym problemem wynikającym przeważnie z braku umiejętności budowania poczucia odpowiedzialności za produkt są próby obchodzenia ograniczeń dotyczących braku bezpośredniej “władzy” nad pracownikami i szukanie sposobności do stosowania metody kija i marchewki. W Agile nie skupiamy się na karaniu tych, którzy coś popsuli lub popełnili błąd, tylko na tym jak takich błędów uniknąć w przyszłości. Karanie, poza masochistyczną satysfakcją karzących nie wnosi żadnej wartości do produktu i projektu, a może jedynie obniżyć motywacje karanego i całego zespołu. Błędy są najwartościowszą lekcją i to właśnie na nich najszybciej i najwydajniej się uczymy.

Oczywiście jeśli nasz zespół ciągle popełnia błędy, które dużo nas kosztują powinniśmy poszukać przyczyn tego stanu rzeczy. Podstawą Agile są ludzie – właściwi ludzie, czasem po prostu okazuje się, że w naszym zespole takich nie ma. By działać zwinnie potrzebujemy odpowiedzialnego zespołu, który będzie w stanie sam rozwiązywać problemy i nie podda się przy pierwszej porażce. Niestety, niektórzy ludzie nie potrafią wziąć na siebie ciężaru odpowiedzialności i potrzebują ciągłej kontroli i zdalnego sterowania we wszystkim co robią.

No dobrze, ale przecież rzeczy nie dzieją się same. Czy na prawdę w Agile nie ma managerów? Tytuł powyższego postu miał być pewnego rodzaju prowokacją wynikającą głównie z błędnej interpretacji/tłumaczenia słowa manager.W naszej krajowej kulturze zwykło się nazywać managerami osoby zarządzające ludźmi, zarządzające procesem etc. W oryginale słowo manager nie musi odnosić się bezpośrednio do zarządzania i tak właśnie jest w Agile – manager w Agile to osoba, która sprawia, że rzeczy się dzieją – ustalone zasady są przestrzegane, spotkania odbywają się o czasie, konflikty są rozwiązywane, etc. Manager w Agile to taki trochę ninja, którego nie widać ale zawsze gdzieś tam jest i dba o to by proces działał sprawnie – istotne jest to, że to nie manager tworzy proces (bo robi to cały zespół – często wespół z managerem), ale to rolą managera jest dbanie o to by proces mógł być stosowany i by wszystko działo się płynnie i bez przeszkód.

“Jeśli jesteś managerem w Agile to nie istniejesz” – a może: “Jeśli jesteś managerem w Agile to twoje istnienie nie powinno być dostrzegalne”? Problemem jest to co opisałem powyżej – niektórym ciężko jest wyzbyć się iluzji władzy i możliwości kontroli drugiego człowieka, przez co stwarzane są różnego rodzaju niepotrzebne nikomu problemy i konflikty, w tym także konflikty interesów. Wszyscy mamy wspólny cel do którego dążymy więc nie potrzebujemy nikogo kto by nas batem poganiał – oczywiście, gdy nie ma celu…

Można być managerem nie zarządzając niczym i przede wszystkim nikim, można być managerem służąc innym, pomagając innym, rozwiązując problemy, sprawiając, że rzeczy się dzieją i wszystko przebiega sprawnie i bez przestojów – wcale nie potrzeba do tego “władzy”.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.

Agile jest niezwykle nieskomplikowanym podejściem do wytwarzania oprogramowania narzucającym jedynie niezbędne minimum zasad w zupełności wystarczających do zbudowania mocnych i stabilnych podstaw na bazie których można wprowadzać pewne modyfikacje i ulepszać istniejące procesy.

W zasadzie Agile samo w sobie nie jest metodyką – to sposób myślenia (mindset), sposób codziennej pracy,  oparty na czterech filarach spisanych w postaci Manifestu Agile:

Ludzie i ich wzajemne interakcje ponad procedury i narzędzia.
Działające oprogramowanie ponad wyczerpującą dokumentację.
Współpraca z klientem ponad negocjację umów (tworzenie kontraktów).
Reagowanie na zmiany ponad ścisłe realizowanie planu.

To minimum zasad często samo w sobie staje się pokusą tego by je jeszcze bardziej ograniczyć. Postulaty manifestu Agile chociaż wydawało by się proste bardzo często są błędnie interpretowane co prowadzi do wdrożeń zwinnych metodyk zarządzania projektami kończących się porażką lub nie dających oczekiwanych (lub możliwych do osiągnięcia) efektów. Na Manifeście Agile opiera się wiele “zwinnych” metodyk i praktyk takich jak Scrum czy Programowanie Ekstremalne (XP). Metodyki te są same w sobie bardzo proste – zawierają tylko podstawowe zasady, których przestrzeganie gwarantuje wzrost efektywności zespołów developerskich. Niemniej jednak dla niektórych wydaje się to tak proste, że staje się bez znaczenia i niektóre praktyki są pomijane.

W ten sposób powstaje coś takiego jak ScrumBut: „Używamy Scrum, ale nie mamy codziennych spotkań”, „Używamy Scrum, ale nie mamy czasu na retrospekcje”, „Używamy Scrum ale nasz manager mówi nam co i ile będziemy robić w tej iteracji” etc.  Podejście typu “Weźmiemy trochę tego, trochę tamtego a resztę pozostawimy tak jak w modelu kaskadowym” powoduje, że wprowadzane zmiany nie mają szans działać w pełni o ile w ogóle cokolwiek polepszają.

Transformacja organizacji w stronę Agile to proces długofalowy, który wymaga wielu poświęceń i wyrzeczeń, a przede wszystkim wymaga otwartości na zupełnie nowe podejście do wytwarzania oprogramowania a także często wymaga od wdrażających możliwości wprowadzania zmian nie tylko w samym IT.

Gwoli ścisłości: to nie jest tak, że metodyki nie wdrażane w pełni nie będą działały w ogóle – będą, tylko efekty takiego wdrożenia będą dużo mniej stabilne i dużo mniej widoczne. Kilkukrotnie widziałem sytuacje w których metodyki pomimo tego, że wdrożone niekompletnie lub nieprawidłowo same się regulowały i ostatecznie coraz bardziej przypominały podręcznikowe wdrożenia, niestety widziałem też sytuacje, w których niecierpliwość spowodowana brakiem widocznych, obiecywanych efektów prowadziła do całkowitej rezygnacji z dalszego podążania w kierunku Agile.

Powyższy post jest rozwinięciem pierwszej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.