blog.testowka.pl

Syzyfowe Prace – Agile Transformacje

opublikowany przez 14, Kwi, 2015, w kategoriach Agile, Coaching, Lean

3195818623_6757843874_o

„(…) We can see that the insanity – and tragedy – of agile – lies in the Sisyphean task of trying to build effective teams – and ways of working- inside ineffective organisations.”

Bob Marshal „What Is Agile Software Development?

Powyższy cytat bardzo dobrze obrazuje to co od kilku lat zauważam podczas mojej pracy jako Agile Coach. Głównym problemem moich klientów jest przeważnie to, że konieczne zmiany wymagane do usunięcia wielu dysfunkcji powinny zachodzić na poziomie całej organizacji a tymczasem wszyscy próbują optymalizować na poziomie poszczególnych zespołów.

Brak spójnej wizji, jasno określonych wartości, misji lub też misja i wartości jako marketingowy chwyt całkowicie sprzeczne z tym jak naprawdę działa organizacja to chleb powszedni wielu firm.

Krytyka Boba Marshal’a w artykule z którego pochodzi powyższy cytat – mniej lub bardziej przesadzona jest jednak w dużej mierze trafna – większość Agile’owych technik i metod skupia się głównie na pracy zespołu (zespołów) wokół produktu – ponad tym wszystkim jest jeszcze organizacja wewnątrz której dany zespół egzystuje i wytwarza produkty.

Stąd też moje zainteresowanie Lean Software Development i System Thinking – w tych dwóch podejściach pracujemy z całymi organizacjami i jednocześnie z zespołami. Praktycznie za każdym razem pracując z nowym zespołem i organizacją zaczynam od zwizualizowania strumienia wartości (Value Stream Mapping). Za pierwszym razem robimy to z perspektywy zespołu a następnie staramy się tą wizję zweryfikować i rozszerzyć o to jak faktycznie wygląda przepływ wartości w organizacji. Gdzie zaczyna się wartość – skąd biorą się wymagania? Co dzieje się z wymaganiami zanim trafią do developmentu? Co dzieje się z nimi później – w jaki sposób są weryfikowane? W których miejscach pojawiają się przestoje produkcyjne – gdzie wymaganie czeka, czyli gdzie generowane są straty? Gdzie są wąskie gardła (w skali całej organizacji raczej rzadko w zespole developerskim)? To tylko kilka z pytań które mogą być przydatne podczas stawiania takiej diagnozy.

Źródła wielu problemów widocznych i często powodujących brak motywacji i frustrację w zespołach wynikają z dysfunkcji, które mają miejsce poza zespołami. Niezliczoną ilość razy słyszałem na warsztatach, szkoleniach i przede wszystkim podczas sesji coachingowych jak wszyscy narzekają na to jak jest źle i nie da się nic z tym zrobić. Oczywiście w wielu takich przypadkach wystarcza zmiana postawy członków zespołu, czasem właśnie po to, by wywrzeć odpowiednia presję na organizację i wypracować pewne zmiany.  Niemniej jednak jest też masa sytuacji w których narzekania na poziomie zespołów i związana z nimi niemoc poprawienia czegokolwiek są przynajmniej częściowo uzasadnione. Bez konkretnych zmian na różnych poziomach organizacji i współpracy z ludźmi, którzy na kształt organizacji mają największy wpływ prędzej czy później możemy natrafić na barierę nie do pokonania. Zawsze można oczywiście zmienić organizację (o ile świat byłby lepszy, gdyby ludzie pracowali w firmach w których CHCĄ pracować), ale to raczej utopia i o ile realna w poszczególnych przypadkach, o tyle niemożliwa do spełnienia przy większej skali.

Patrząc w przeszłość na projekty transformacji agile, które miałem okazję wspierać w ten czy inny sposób jasno widać, ze najlepsze efekty udało się nam osiągnąć tam, gdzie pracowaliśmy z całą organizacją. Począwszy od prezesa/zarządu, poprzez managerów wysokiego i średniego szczebla i skończywszy na developerach (i nie tylko – istotne np. jest też zaangażowanie działów produktowych, marketingowych i przede wszystkim HR).

Tam, gdzie miałem okazję pracować jedynie z pojedynczymi zespołami zmiany zaszły stosunkowo niewielkie. Przeważnie udawało się zoptymalizować pracę zespołu ale potencjał zwiększenia efektywności był znacznie większy – wystarczyłoby tylko wprowadzić pewne usprawnienia na poziomie organizacji, na które nie było zgody (a raczej możliwości porozmawiania z kimkolwiek, kto taką zgodę mógłby wyrazić).

A czy Twoja organizacja (a nie tylko zespół) jest gotowa na zmiany?


1 Comment for this entry

  • grzesiek gałęzowski

    Wow, nie spodziewałem się przeczytać wpisu, który w 100% pokrywa się z moimi przemyśleniami na ten temat (choć oczywiście moje doświadczenia są dużo bardziej ograniczone).

    Wygląda na to, że muszę zająć się mocniej Systems Thinking i Leanem…

    Dzięki!!

Skomentuj