Zwinna transformacja w ING Banku Śląskim

Rok temu w ING Banku Śląskim rozpoczęto wdrożenie Agile. Jako jedno z narzędzi wybrano Scrum, które stwarza warunki dla innowacji, zmniejszając dystans między IT a biznesem.

Celem ING Banku Śląskiego jest dostarczanie zintegrowanych usług finansowych i zachowanie charakteru banku zorientowanego na klienta. Bank dociera z ofertą do wszystkich segmentów odbiorców, wykorzystując technologicznie kanały komunikacji. Rosnąca dynamika zmian technologicznych i oczekiwania klientów sprawiają, że nie da się oddzielić technologii od biznesu. Zmniejszenie dystansu, większa transparentność działań, możliwość szybkiego reagowania na zmiany, łatwość komunikacji – to oczekiwany model współpracy w relacji biznes–IT.

Rok temu uruchomiono inicjatywę, która okazała się istotnym czynnikiem wspierającym realizację tych celów – zwinną transformację. Jako jedno z narzędzi wybrano Scrum, które stwarza szczególną przestrzeń dla innowacji. Zmniejsza dystans pomiędzy IT a biznesem, zapewnia większą transparentność i możliwość szybkiego reagowania na zmiany. Ale także dużo wymaga, zwłaszcza na poziomie organizacji. To metoda opierająca się na empirycznej kontroli procesu, w której codzienne doświadczenie jest źródłem wiedzy o projekcie. Scrum to proces ciągłej inspekcji i adaptacji, nieustannego eksperymentowania i poszukiwania nowych rozwiązań. Taki model działania daje możliwość szybkiego reagowania na zmieniające się potrzeby biznesu, pozwala na dostarczanie usług, które bezpośrednio trafiają w gusta klientów.

Podstawowe wyzwania transformacji

1. Pierwszym wyzwaniem była złożoność rejestru produktu (product backlog). Wyznaczały ją m.in.: różnorodność oferty produktowej, wielokanałowość, świat technologii mobilnych. To znalazło odzwierciedlenie w kompleksowym modelu architektury korporacyjnej. Jego celem jest zapewnienie optymalnego i spójnego wykorzystana technologii dla realizacji potrzeb biznesowych.

2. Kolejnym wyzwaniem był kontekst organizacyjny zwinnej transformacji. Aby zapewnić spójne rozwiązania i wykorzystać dojrzałość organizacyjną, przyjęto podejście holistyczne. Wymagało to adaptacji istniejących procesów, takich jak: zarządzanie popytem (demand management), zarządzanie projektami, zarządzanie wydaniami produktu (release management), planowanie i koordynacja złożonych zmian w systemach IT, zarządzanie testami. Na kontekst składały się też praktyki i cele wynikające z wcześniej wdrożonych modeli i standardów działania, wśród których były modele CMMI, COBIT, metodyki Prince2 i PMI.

3. Ostatnim wyzwaniem jest skalowanie metody Scrum, a szczególnie jej dwa elementy:

Role. Specyfika produktów bankowych i obecność zewnętrznych poddostawców spowodowały, że role właściciela produktu i ScrumMastera były obciążone. Duże zależności między zespołami i silne interakcje z biznesem spowodowały, że ScrumMaster miał dużo więcej blokad do usunięcia niż w pozostałych projektach. Musiał współpracować z innymi ScrumMasterami w organizacji, uczestniczył w cyklicznych spotkaniach Scrum of Scrums, angażował się w prace zespołu, który zajmował się planowaniem i koordynacją procesu wdrożenia na poziomie organizacji. Wprowadzenie roli ScrumMastera i właściciela produktu wymagało dokładnego określenia zakresu obowiązków menedżera liniowego. Zależności i udział zewnętrznych dostawców wpływały na pracę zespołów scrumowych i wiązały się z wyzwaniami na poziomie integracji rozwijanych produktów.

Praktyki. Skalowanie ceremonii scrumowych (planowanie sprintów, codzienne scrumy, przeglądy i retrospektywy) wymagało wypracowania modelu pracy. Były to sztywne reguły dotyczące synchronizacji sprintów. W codziennych scrumach wprowadzono zasadę, że odbywały się one co 15 minut w wyznaczonych ramach czasowych. Dzięki rozwiązaniu członkowie zespołów scrumowych i zewnętrzni dostawcy mogli uczestniczyć nawet w kilku spotkaniach. Przy przeglądach na koniec sprintów skalowanie wiązało się z zaangażowaniem większej liczbę interesariuszy (biznesu i IT). Wprowadzono cotygodniowe forum wymiany doświadczeń, które miało na celu dzielenie się dobrymi praktykami i rozwiązywanie problemów. W spotkaniach uczestniczyli ScrumMasterzy, właściciele produktów oraz interesariusze którzy chcieli podzielić się wiedzą i udzielić informacji zwrotnej.

Od czego się zaczęło?

Oto etapy, z których składał się proces zwinnej transformacji:

1. Konfrontacja z rzeczywistością. Przeprowadzono szereg wewnętrznych warsztatów, do których zaproszono kadrę kierowniczą i uczestników wybranych zespołów projektowych. Przeprowadzono gruntowną analizę luk dotyczących kluczowych procesów bankowych.

2. Zdefiniowanie wizji zmiany. Organizacje, żeby się rozwijać, muszą być innowacyjne, muszą zaskakiwać i zachwycać klientów. Taka też była wizja naszej zmiany: „Klient w centrum".

3. Powołanie zespołu wewnętrznych nawigatorów. Na początku powołano zespół wewnętrznych nawigatorów, składający się z menedżerów wydziałów. Agenci zmian odpowiadali za stworzenie warunków sprzyjających wdrożeniu zmiany, wspierali jej realizację, oceniali efektywność.

4. Opracowanie strategii wdrożenia. Zaproszono do współpracy zewnętrzną firmę konsultingową Kugler Maag CIE, która pozostała do końca realizacji inicjatywy. Rozpoczęto cykl strategicznych warsztatów.

5. Pilotaż zespołów scrumowych. Wybrano cztery zespoły projektowe, każdy zajmował się innym produktem i klientem biznesowym. W wielu firmach projekt pilotażowy jest traktowany jako test, którego wynik decyduje o kontynuacji wdrożenia w całej organizacji. W ING Banku pilotaż miał pomóc w planowaniu dalszych etapów transformacji. Oto czynniki, którymi kierowano się przy wyborze zespołów pilotażowych:

• Rozmiar zespołu. Do pilotażu wybrano małe projekty. Każdy z zespołów realizował inny typ przedsięwzięcia.

• Typ klienta biznesowego. Wybrano zespoły projektowe, które współpracowały z najbardziej „zwinnymi" klientami. Trzeba było znaleźć klientów biznesowych, którzy mogliby wcielić się w rolę właściciela produktu.

• Ranga projektu. Wybrano projekty najważniejsze dla organizacji.

6. Wdrożenie (iteracyjne). Pilotaż pokazał wąskie gardła procesu; co trzeba zmienić, jak przeorganizować pracę, żeby wdrożenie Scruma zakończyło się sukcesem. Po analizie wniosków z pilotażu i wprowadzeniu poprawek do strategii można było przystąpić do wdrożenia. Co dwa miesiące iteracyjnie uruchamiano kolejne zespoły scrumowe. Z każdym z nich przez kilka sprintów pracował zewnętrzny coach, który pomagał wcielić praktyki i wartości w życie. Oprócz wsparcia udzielanego na poziomie zespołu prowadził indywidualne sesje ze ScrumMasterami i właścicielami produktu. Każdy zespół uczestniczył w szkoleniu stanowiącym wprowadzenie do pracy w metodzie Scrum.

Wybrane rozwiązania

Spośród wielu rozwiązań, które udało się wypracować, trzy wymagają szczególnej uwagi:

1. Praca z dużym rejestrem produktu. Rejestr produktu, nad którym pracowały zespoły scrumowe, był różnorodny. Perspektywa klienta też była zróżnicowana, niekiedy reprezentowana przez kilka linii biznesowych. Po warsztatach okazało się, że trzeba wprowadzić odpowiednią organizację i hierarchię w grupie właścicieli produktu. Zwracano uwagę, żeby zespoły scrumowe miały tylko jednego właściciela produktu, z którym będą współpracować. Trzeba było zmierzyć się z pewnego rodzaju dychotomią, na którą składały się IT oraz biznes. Zdecydowano się na wprowadzenie rozwiązania, które nazwano „koncepcją luster" – rola właściciela produktu miała swoje lustrzane odbicie zarówno po stronie IT, jak i biznesu. W ten sposób zespoły scrumowe współpracowały tylko z jedną osobą, która odpowiadała za rozwijany produkt. Zdawano sobie sprawę z ograniczeń modelu, ale wiadomo było, że proces włączenia biznesu w prace zespołów scrumowych nie będzie łatwy. Panowało przekonanie, że musi to być ewolucja. Z drugiej strony, Scrum jest modelem empirycznym. Jego olbrzymia wartość to możliwość ciągłej korekty ścieżki działania. Decydując się na „koncepcję luster", chciano z tej możliwości skorzystać.

2. Skalowanie roli właściciela produktu

Drugim rozwiązaniem było skalowanie roli właściciela produktu. Zdecydowano się na wprowadzenie dwóch poziomów. Pierwszy wiązał się z nową rolą – tzw. głównego właściciela produktu (Chief Product Owner). To osoba zarządzająca rejestrem produktu na poziomie całego obszaru, ustalająca priorytety i komunikująca wizję, która dotrze do poszczególnych właścicieli produktu na niższych szczeblach i zostanie przekazana zespołom scrumowym. Czytelny przepływ informacji miał kluczowe znaczenie. Wszystkie wątpliwości, kwestie sporne rozwiązywane były przez głównych właścicieli produktu. Po stronie IT rolę głównego właściciela produktu pełnili Account Managerowie.

3. Konfiguracja zespołów. Powołano interdyscyplinarne zespoły. Wcześniej ludzie z zespołów projektowych siedzieli w różnych miejscach, komunikacja była utrudniona. Udało się to zmienić. Konfiguracja zespołów scrumowych była zróżnicowana. Zazwyczaj były to zespoły nieparzyste (pięcio-, siedmio- i dziewięcioosobowe). Zauważono, że w takich zespołach najszybciej przebiegał proces samoorganizacji. Ludzie łatwiej dzielili się zadaniami, mieli poczucie wspólnego celu i odpowiedzialności za produkt. Warto wspomnieć o zadaniach utrzymaniowych. Utrzymanie okazało się piętą Achillesa zespołów scrumowych. Początkowo próbowano buforować pracę ze sprintu na sprint, kalibrując ilość czasu potrzebnego na utrzymanie. Zawsze jednak trzeba było zmieniać plany. Jedną z decyzji było wydzielenie utrzymania do oddzielnych zespołów, które nie będą pracować w Scrumie (tu sprawdził się Kanban). Nie było jednak wystarczającej liczby osób, żeby uformować zespoły. Tak zrodził się pomysł wirtualnych zespołów utrzymaniowych – zespół wirtualny to była grupa zadaniowa. Tworzyli ją ludzie, którzy na okres jednego sprintu „wychodzili" z zespołu scrumowego, pracowali nad zadaniami utrzymaniowymi, a potem wracali do zespołu. Każdy czuł się związany z jednym zespołem. To nie zakłócało procesu formowania się zespołów scrumowych.

Korzyści wdrożenia

Korzyści z wprowadzenia zwinnej transformacji w ING Banku Śląskim można podzielić na dwa obszary:

1. Korzyści dla biznesu

• większa przejrzystość planowania;

• częsta informacja zwrotna od zespołu;

• wczesne wykrywanie zagrożeń i konfliktów w realizacji modyfikacji;

• rosnące zaangażowanie biznesu w prace nad wymaganiami produktu, wspólne testy i retrospektywy;

• wpływ biznesu na zakres i kształt produktu.

2. Korzyści dla zespołów

• większa integracja zespołów projektowych, lepsza atmosfera pracy;

• optymalna komunikacja;

• zmniejszanie „wąskich specjalizacji” w zespole i przechwytywanie zadań z innych obszarów;

• zespół samodzielnie rozwiązuje swoje problemy i usuwa wewnętrzne przeszkody;

• pojawienie się nowych ekspertów dziedzinowych;

• wymiana „wiedzy ukrytej”, która ujawnia się w trakcie codziennych działań nad zadaniami sprintu.

Łatwo zrozumieć, trudniej wprowadzić

Agile to metoda pracy, która opiera się na dojrzałości i wzajemnym zaufaniu biznesu oraz IT. Budowanie takiej relacji to proces, na który organizacje muszą być gotowe. Zasady zwinnego zarządzania łatwo zrozumieć. Członkowie zespołów projektowych czują się bardziej odpowiedzialni za produkt, ich celem jest zadowolenie klienta. Pracując w krótkich cyklach wytwórczych, każdy może szybko zobaczyć efekty pracy. Gdy proces jest transparentny, łatwiej jest wspólnie rozwiązywać problemy. Wprowadzane są innowacje. Z drugiej jednak strony, zwinne zasady i wartości nie są łatwe do wprowadzenia w organizacji. Zwinne metody pracy znacznie różnią się od tych, które spotykamy w tradycyjnej praktyce menedżerskiej. Metoda Scrum zakłada inny sposób myślenia i działania w projektach. Wymaga odmiennego sposobu organizowania pracy i większej autonomii zespołów. Wiąże się ze zmianą mentalności, a to wymaga czasu. Mimo to zwinna transformacja to zmiana, na której mogą skorzystać wszystkie strony – organizacja, menedżerowie, pracownicy i klienci.

Komentarze

Jednym z pierwszych przykładów zastosowania metod zwinnych było stworzenie interdyscyplinarnego zespołu, którego praca była ukierunkowana na zbudowanie w możliwie krótkim czasie aplikacji mobilnej dla klienta detalicznego na platformę iOS. Zespół, który został powołany do życia we wrześniu 2011 r., już po trzech miesiącach był w stanie dostarczyć gotową aplikację do marketu. Było to w grudniu 2011 r. Z początkiem 2012 r. aplikacja została udostępniona klientom.

W ramach wdrożenia zespół rozpoczął pracę w metodzie Scrum, w której pracuje do dziś, wzbogacając aplikację o kolejne funkcjonalności. Uwzględniając zmienne potrzeby klienta w obszarze aplikacji mobilnych, zespół osiągnął prędkość pozwalającą skrócić czas dostarczania kolejnych wersji produkcyjnych do sześciu tygodni, co było możliwe dzięki zastosowaniu zwinnych metod pracy i dobrej współpracy z biznesowym właścicielem produktu.

Tomasz Chmielewski, IT Manager w ING Banku Śląskim

Scrum zmienia dotychczasowy model współpracy z IT w zakresie planowania i realizacji projektów. Ściśle współpracując z zespołem scrumowym, mamy możliwość przedstawienia swoich racji i priorytetyzowania wymagań. Częsty wgląd w postępy pracy i weryfikacja jej realizacji sprawiają, że od razu widać efekty. Co ważne, mamy możliwość dostosowywania wymagań do zmieniających się warunków w trakcie realizacji projektu i wprowadzania na bieżąco usprawnień.

Dariusz Olesiński, właściciel produktu eBojtlik

Obecnie jesteśmy w trakcie uruchamiania kolejnych zespołów scrumowych. Każdy nowy zespół to odrębny obszar aplikacyjny, odrębny produkt bankowy, różne obszary procesowe. Po okresie adaptacji nowej metody zespoły obserwują lepszy przepływ wiedzy i wyrównywanie kompetencji w ramach rozwijanych aplikacji. Największym benefitem z punktu widzenia zespołu jest proces retrospekcji, który pokazuje i adresuje wszystkie bolączki zespołu, które są od razu rozwiązywane.

Arkadiusz Kil, Lean Navigator

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

TOP 200