Jak wdrażać zwinne metodyki w hierarchicznej organizacji

O wyzwaniach, roli liderów i sposobach tworzenia zwinnego środowiska pracy w organizacjach o dziedzicznie hierarchicznej kulturze opowiadał Jakub Szczepanik, lider zespołu Agile Coachów w mBanku podczas konferencji „Zarządzanie zespołami IT” organizowanej przez magazyn „Computerworld”.

„Historia transformacji mBanku sprowadza się do prostej kwestii: chcemy, żeby IT było zwinne” – podkreśla Jakub Szczepanik. Rynki zmieniają się szybciej niż kiedykolwiek, coraz bardziej liczy się szybkość dostarczania produktów, ich wydajność i niezawodność oraz stopień dostosowania do indywidualnych potrzeb użytkowników. Zastałe, wielkie biznesy odczuwają rosnącą presję ze strony start-upów oraz konkurentów wywodzących się z innych sektorów – w przypadku banków są to tzw. Fintechy. Mając na uwadze przemiany, jakie na przedsiębiorstwach wymuszają technologie tzw. trzeciej platformy, widać wyraźnie, że właściwe dostosowanie struktury zarządzania projektami informatycznymi to konieczny element pełnozakresowej cyfrowej transformacji. Agile to jednak nie tylko zwinne IT – „agile’owa kultura, agile’owy sposób pracy dobrze wpływa na pracowników” – podkreśla Szczepanik.

Dziedziczna hierarchiczność kultury organizacyjnej

Zmiana sposobu zarządzania bywa jednak trudna. Duże organizacje, w tym banki oraz instytucje finansowe, mają silną tendencję do budowania scentralizowanych, pionowych struktur. To z kolei przekłada się na kulturę zarządzania oraz stosunki panujące między pracownikami różnych szczebli.„Nie tylko w strukturze organizacyjnej, ale w ogóle w kulturze funkcjonowania bardzo silnie zaszyta jest perspektywa, że menedżer ma zawsze rację” – podkreśla Jakub Szczepanik.

Zobacz również:

  • 9 cech wielkich liderów IT
  • Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk
  • Zarządzanie informacją – nowe kierunki

Nie inaczej było w mBanku. „Cała organizacja była – z perspektywy menedżerskiej – niesamowicie hierarchiczna” – wskazuje Szczepanik i wylicza: „liderzy, którzy rozdzielają zadania pracownikom; dyrektorzy, którzy bardzo ściśle kontrolują liderów z rozliczanego czasu; wysokie szczeble podejmowania prawdziwych decyzji o budżetach, o tym, co jest ważne i priorytetowe”.

W takiej organizacji wdrażanie zwinnej kultury zarządzania wymaga podwójnego wysiłku i ostrożności. „Uruchomiliśmy pierwsze pilotażowe zespoły scrumowe. Były one rozsiane po całej firmie: w hurtowni danych, zespołach mobilnych, w zespołach zajmujących się rdzeniem systemu bankowego”. Były to ostrożne kroki mające ustalić, co należy zmienić w procesach, strukturze organizacyjnej oraz kulturze korporacyjnej, by efekty prac okazały się trwałe. Nie było odgórnego założenia co do zakresu i przedmiotu zmian.

Nastawienie, nawyki, przyzwyczajenia i nieodwołane rozkazy

Zetknięcie z hierarchiczną kulturą organizacyjną nastąpiło szybko. „Ostrym dowodem takiej kultury i negatywnego stanu zastanego było coś, co wydarzyło się podczas warsztatu dla zespołu infrastruktury. Opowiadałem, jak może wyglądać infrastruktura w świecie zwinnym, czym jest Kanban, jak ważne jest tworzenie zespołów produktowych” – opowiada Jakub Szczepanik. Uczestnicy warsztatu słuchali, dopytywali, reagowali, zgłaszali uwagi – do momentu, w którym przyznali, że istotną barierą w adaptacji podejścia Agile będą menedżerowie. „Uczestnicy spotkania kompletnie storpedowali warsztat. Nie było sensu w ogóle iść dalej i tłumaczyć szczegółów tego, jak można by nad tym problemem popracować. Nie wierzyli, że w istniejącym sposobie zarządzania można pracować zwinnie”. Zamiast tego wspólnie z prowadzącym napisali list do menedżerów, w którym sformułowali uwagi, jakie mieli wobec swoich zwierzchników. Szybko okazało się, że „wszystko, co mówili, było nieprawdopodobnie prawdziwe dla całej organizacji” – podkreśla Jakub Szczepanik. Oczywiście „niektórzy menedżerowie byli wspierający, pomagający zespołowi, interesujący się współpracą z Agile Coachem wspomagającym transformację; skupieni na tym, by rozwiązywać problemy, jakie zespoły zgłaszały w swoich pierwszych próbach, pierwszych sprintach. Ale byli też menedżerowie oddaleni, ‘trzymam za was kciuki – wykonać’. Niekoniecznie pomocni”. Obie postawy wynikały nie tylko z pozytywnego czy negatywnego stosunku do Agile, ale również z prób zrozumienia roli menedżera w tak zarządzanej organizacji. Część osób rozumiała odsunięcie się od zespołu jako element realizacji koncepcji Agile .

Niezależnie od nastawienia szczególnymi momentami próby okazywały się problemy bądź momenty typowe dla organizacji zarządzanej kaskadowo, np. planowanie kwartału czy budżetowanie roku. Jeśli „rozkazy” nie zostały jednoznacznie odwołane przez przełożonych, „z menedżera wychodziło to, do czego był przyzwyczajony od lat albo czego oczekiwały od niego procesy firmowe” – wspomina Jakub Szczepanik, po czym wskazuje stojący za tym podejściem tok rozumowania: „Mam polecenie, by rozliczyć budżety, muszę zaplanować projekty, firma oczekuje, że będę wiedział, co się dzieje w projekcie, jaki jest status, muszę złożyć raport – to dotychczasowy sposób myślenia. Bardzo szybko okazało się, że bez zmienienia tego aspektu trudno nam będzie wdrażać zwinną kulturę organizacyjną”. Status quo powracało siłą inercji, zwłaszcza w momentach kryzysowych. Menedżerowie nawykli do kierowania i odbierania zadań (tasków) przechodzili w tryb mikrozarządzania, czym dezorganizowali pracę w zespołach scrumowych, uczonych przecież, że same mają rozwiązywać problemy.

Co ciekawe, „sami menedżerowie zwracali uwagę, że częścią problemu z ich zachowaniem jest kwestia wyższego menedżmentu: dyrektorów i wyższych szczebli. Ci nadal zarządzali swoimi pracownikami w starym stylu, co powodowało efekt domina” – dodaje Szczepanik. „Łatwo było mi pokazać dyrektorom, że w zasadzie menedżera pyta się o projekt. Nie pytano o zaangażowanie jego ludzi, czy jak wdraża się nowy pracownik”. Szybko stało się więc jasne, że wprowadzenie modelu Agile w mBanku będzie wymagało tyle samo pracy z menedżerami, ile z zespołami. By zmienić zespoły, trzeba było zmienić menedżerów. By zmienić menedżerów, trzeba było z kolei przepracować menedżerów nadrzędnych oraz kadrę zarządzającą .

Solidne fundamenty reorganizacji procesów

Jak zabrać się do zmiany nastawienia menedżerów? „Tak jak razem z zespołami wypracowujemy różne rozwiązania, tak z zespołem menedżerów postanowiliśmy podjąć temat ich nowej roli w świecie, do którego dążymy” – wyjaśnia Jakub Szczepanik.„Rozpisaliśmy wszystkie odpowiedzialności wszystkich ról, jakie w tym nowym świecie się pojawiają”. Do realizacji celu posłużyło znane narzędzie: macierz odpowiedzialności (Responsibility Matrix). W zestawieniu znalazły się role menedżera produktu (Product Managera), właściciela produktu (Product Owner), Scrum Mastera, a także wyższego menedżmentu, by nakreślić różnicę między menedżerem zespołu a dyrektorem departamentu. Wszystkie możliwe role zostały następnie intensywnie przepracowane na warsztatach, podczas których menedżerowie przekonywali się m.in., że Scrum Masterzy nie odbiorą im roli w zarządzaniu zespołami. Osobne warsztaty poświęcone były dyrektorom oraz podlegającym im menedżerom. Ci razem z Agile Coachem przepracowywali wątek presji na linii kadra kierownicza – menedżerowie – zespoły.

Zmian w poszczególnych rolach było wiele – jedne obowiązki zniknęły, w ich miejsce pojawiły się nowe. W istotny sposób zmienił się np. zakres odpowiedzialności w odniesieniu do prac delegowanych do zespołów. Zespoły przestały odpowiadać tylko za terminową realizację zlecanych przez menedżerów zadań. Zamiast tego na ich barkach spoczęła cała odpowiedzialność za produkt, jego jakość, a także samodzielne usprawnianie. Zmienił się również proces pozyskiwania informacji zwrotnej (feedback) ze strony kierownictwa. Menedżerowie byli zachęcani, by zamiast oczekiwania na coroczne spotkania podsumowujące, częściej kontaktowali się z pracownikami i wymieniali uwagi. „Odbiorcą jakości prac menedżerów są nasi pracownicy” – podkreśla Jakub Szczepanik. To istotne, ponieważ okazało się, że opinie jednych i drugich się mijały – menedżerowie uważali, że informacja ze strony kierownictwa jest wystarczająca. Pracownicy w większości stwierdzali coś odwrotnego.

Wraz z ustaloną listą zmian w odniesieniu do ról i obowiązków przygotowano także program rozwojowy, który obejmował zebrane w toku prac potrzeby zarówno pracowników, jak i menedżerów. Jednocześnie, choć z perspektywy Agile nie jest to oczywiste, „Bardzo zależało nam, by powstał ‘nowy rozkaz” – wspomina Szczepanik. „Po ustaleniu nowej listy obowiązków menedżerów „upewniliśmy się, że wszyscy wiedzą, że to jest zaakceptowana lista. Organizacja hierarchiczna, z której wychodziliśmy, bardzo potrzebowała takiego potwierdzenia”.

Największe problemy i kontrowersje

Największa kontrowersja w stosunku do nowej roli menedżera – według słów Jakuba Szczepanika – sprowadzała się do odpowiedzi na pytanie: Za co konkretnie ma on odpowiadać, skoro nie odpowiada już bezpośrednio za realizację projektu? Zrozumienie swojej nowej roli w organizacji wymagało od menedżerów sporo wysiłku. Często zmagali się bowiem z poczuciem, że przecież dobrze radzili sobie w kaskadowym procesowaniu projektów, mieli wgląd w stan prac oraz możliwość reagowania na ewentualne niedociągnięcia. Z kolei po przejściu na zwinne metodyki zarządzania inni uczestnicy procesu jasno komunikowali, że nie należy interweniować w ich prace.

Jak w takim razie menedżer ma odpowiadać za projekt? Pojawiały się głosy, by w takiej sytuacji w ogóle zdjęto z nich tę odpowiedzialność. „Na takie rozwiązanie nie chcieliśmy się zgodzić. Mocno trzymaliśmy się zasady, że menedżer odpowiada za projekt, a jednocześnie nie może pozwalać sobie na mikromenedżment” – naciska Jakub Szczepanik. Do komunikacji takiego rodzaju odpowiedzialności posłużył się metaforą piłkarską: „trener drużyny piłkarskiej nie odpowiada za to, że ktoś strzeli bramkę czy obroni karnego. Jednocześnie często to trener wyleci jako pierwszy, jeżeli drużynie idzie źle. Trener ma ograniczone możliwości interweniowania w trakcie meczu, może jednak zrobić wiele przed meczem, by drużyna była przygotowana”. Przede wszystkim może tę drużynę zbudować, potem zaś przygotowywać, szkolić i motywować. „Rolą lidera w Agile nie jest dostarczanie dobrych projektów, tylko dostarczanie dobrych zespołów” – podkreśla Jakub Szczepanik.Te dobre zespoły będą w efekcie dostarczać dobre produkty.

Czas poświęcony na przepracowanie roli menedżerów w zwinnej organizacji nie poszedł w mBanku na marne. Nawet „menedżerowie o silnej skłonności do mikromnedżmentu po dwóch latach pracy, rozwoju i coachowania lepiej delegują zadania i dają feedback swoim pracownikom” – podsumowuje Jakub Szczepanik.

Zarządzanie zespołami IT w praktyce

Jakub Szczepanik był jednym z prelegentów na tegorocznej konferencji Computerworld „Zarządzanie zespołami IT”.

Wydarzenie w całości poświęcone było tematyce pozyskania, motywowania i utrzymania najlepszych specjalistów IT. W programie znalazły się najciekawsze studia przypadków zaprezentowane przez dyrektorów i menedżerów HR oraz szefów działów ICT. Uczestnicy mieli okazję wziąć udział w interaktywnych warsztatach oraz sesjach coachingowych. Konferencji towarzyszyło wydanie specjalnego raportu poświęconego najlepszym praktykom zarządzania specjalistami działów technologicznych.

Wydarzenie odbyło się w dniach 30–31.I.2017 w Warszawie. Już teraz zapraszamy na przyszłoroczną konferencję!

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200