Agile wymaga kultury

Mogłoby się wydawać, że zastosowanie metodyk zwinnych w procesie cyfrowej transformacji organizacji to gotowy przepis na sukces i skuteczną zmianę. Okazuje się, że wcale tak nie jest, a seria sprintów, z których złożony jest proces zwinnej transformacji, może zamienić się w długodystansowy bieg z przeszkodami.

Kate Hobler z firmy Brass Willow w trakcie wystąpienia na konferencji "Agile w biznesie" 2019.

Metody agile wywodzą się ze schematu PDSA, opracowanego przez Williama Deminga. PDSA (ang. plan-do-study-act) to cykl ciągłego doskonalenia, wywodzący się z filozofii Dalekiego Wschodu. Podejście zwinne, chociaż w rzeczywistości nie jest niczym odkrywczym, stało się niesamowicie modne. „Podejście agile to nie są rzeczy nowe, ale na nowo nazwane. Dzięki temu interesuje się nim większa ilość firm” – przyznaje Kate Hobler, mentorka i trenerka metody Scrum w firmie Brass Willow.

Można wręcz zaryzykować stwierdzenie, że dziś każda organizacja chce być zwinna. W konsekwencji pojęcie „agile” zaczęło być używane na skalę masową, wskutek czego… zużyło się. A w pogoni za zwinnością organizacje gubią sens manifestu agile. Coraz częściej w ostatnich latach słychać zatem głosy o zmierzchu agile’a. Kurt Cagle w głośnym artykule w „Forbesie” w sierpniu br. pisał: „[Agile] stało się religią, i podobnie jak większość religii, nie ma większego sensu dla osób z zewnątrz”.

Zobacz również:

Kate Hobler jednak uspokaja – koncepcja zwinności nigdy nie wyjdzie z mody. Za dużo przynosi korzyści.

Agile. Zwinnie, czyli jak?

W organizacjach z epoki przedagile’owej panował typowy rozdział obowiązków i kompetencji. Funkcjonowały tradycyjne działy biznesu, rozwoju usług/aplikacji oraz infrastruktury IT. Biznes zajmował się sprzedażą, programiści – tworzeniem usług i aplikacji, a dział informatyczny – rozwijaniem i utrzymaniem infrastruktury niezbędnej do ich świadczenia. Biznes zamawiał wykonanie usług, które następnie oferował klientom firmy, a development zobowiązywał się do ich dostarczania na bazie umowy Service Level Agreement. IT pracowało w silosach: oddzielnie infrastruktura, technologia, aplikacje. Ryzyko błędów było większe, a procesy – wydłużone. I tak to się toczyło, od jednego dużego wydania aplikacji bądź usługi do następnego.

Podejście zwinne wywróciło ten układ, zarówno pod względem sposobu dostarczania nowych usług, jak i procesów modernizacyjnych i restrukturyzacyjnych biznesu. Zmiany i innowacje dostarczane są w modelu iteracyjnym, czyli w mniejszych porcjach, tzw. sprintach – i w szybszym tempie.

W założeniu pozwala to lepiej kontrolować cały proces, szybciej reagować na ewentualne problemy i wprowadzać poprawki. Jednocześnie cały czas trwają testy, dzięki którym klienci organizacji – zarówno zewnętrzni, jak i wewnętrzni, czyli pracownicy – nie są na koniec zaskakiwani efektami.

Agile. Filary zwinności

Pierwszy to ludzie, drugi to procesy, a trzeci – technologie. „Adresowanie ich równomiernie to znak, że idziemy w dobrym kierunku” – mówiła Magdalena Nowicka, Global Head of Technology Sourcing w firmie Nordea.

Problem powstaje wtedy, gdy za zmianami nie idzie zmiana kultury organizacyjnej. Nie wystarczy spotykać się w gronie zespołu i omawiać postępy sprintu. Współpraca biznesu i IT nie może być pozorna – a tak się dzieje, gdy przykładowo, wszystkie decyzje związane z projektem podejmowane są na wyższym szczeblu, a właściciel produktu jest nim tylko z nazwy. Zmiana kultury pracy i sposobu myślenia są najtrudniejsze. I nie dotyczy to wyłącznie zarządu. „Większość transformacji nie powiodła się, bo pracownicy nie wierzyli, że wartości, które firma chce wdrożyć, są ich wartościami” – mówiła Nowicka w trakcie wystąpienia na konferencji „Agile w Biznesie”, organizowanej przez „Computerworld”.

A skoro wyznacznikiem zwinności organizacji jest jej struktura, to do ustalenia, czy transformacja zmierza w dobrym kierunku wystarczy przeanalizować obowiązujący model współpracy między działem biznesowym a technologicznym. Czy ciągle rozliczają się na podstawie umów i czy biznes odbiera usługę? Bo w zwinnej organizacji tak być nie powinno. Gdy biznes ogranicza się tylko do zamówienia usługi lub aplikacji, nie bierze odpowiedzialności za końcowy produkt.

I odwrotnie – dział programistyczny, ograniczając się wyłącznie do dostarczenia zamówienia, nie bierze na siebie ryzyka niepowodzenia całego projektu (patrz: ramka „Jak zostać zwinnym dostawcą IT”).

Agile. Bez BizDevOps ani rusz

Kiedy transformacja zawodzi

Projekty transformacji kończą się fiaskiem zwykle dlatego, że nie poprzedza ich zdefiniowanie celu i strategii zmiany. Inne powody, według Kate Hobler z Brass Willow, to: brak przejrzystości – nikt nie wie, od czego zacząć i jakie są kolejne etapy zmiany; niewłaściwe umiejscowienie transformacji – brak adwokata zmiany na szczeblu zarządu; zbytnie poleganie na zewnętrznym doradztwie.

Ponadto należy też zwalczać mit, że transformacja zwinna – z jej podejściem iteracyjnym, zespołami projektowymi i właścicielami produktów – eliminuje menedżerów średniego szczebla. W rzeczywistości są oni w tym procesie niezwykle ważni, bo stanowią połączenie między szczeblem strategicznym a operacyjnym. Ich obawy należy więc szczególnie adresować.

U podstaw każdej transformacji leży zwykle przynajmniej jeden z czterech głównych powodów: poprawa innowacyjności organizacji, obniżenie kosztów funkcjonowania, skrócenie czasu wprowadzania zmian i produktów oraz zmiana priorytetów operacyjnych – klient ważniejszy niż procesy.

Za pierwszy krok w kierunku zwinnej transformacji można uznać wdrożenie metodyk DevOps, czyli połączenie dwóch obszarów rozwoju oprogramowania (Dev) i operacji (Ops). Istotą agile’a jest jednak wykonanie kolejnego kroku – stworzenie zespołów BizDevOps, czyli jednostek angażujących pracowników działów biznesowych w proces tworzenia produktów na równi z działami rozwoju.

„Dopóki biznes nie połączy się z IT, czy to przez fizyczne stworzenie zespołów i zmianę struktury organizacyjnej czy poprzez zespoły wirtualne i dopóki nie weźmie odpowiedzialności za to, co robi IT, a IT nie podzieli się ryzykiem z biznesem, nie ma mowy o wdrożeniu agile” – przekonuje Nowicka.

Wiąże się z tym niepodważalna korzyść dla biznesu – dostęp do ludzi na co dzień pracujących z najnowszymi technologiami, którzy mogą doradzić, co warto wdrażać w usługach dla klientów. Nie ma bowiem wątpliwości, że technologia – chociażby 5G, sztuczna inteligencja i blockchain – będzie dawać coraz większe możliwości zmiany procesów i zaspokajania potrzeb klienta.

Równolegle, warstwa infrastrukturalna organizacji powinna być przenoszona do chmury, do modelu usługowego (as a service). W świecie idealnym powinna to być chmura publiczna – podkreśla Nowicka – jednak w świecie realnym istnieje wiele różnych uwarunkowań, na które trzeba brać poprawkę (np. systemy zastane, których szybko się nie da przenieść do chmury).

Jak zostać zwinnym dostawcą IT

Jak przekonać firmę kupującą usługi informatyczne do korzystania z umów spójnych ze zwinnymi metodykami zarządzania projektami IT? W trakcie konferencji „Agile w biznesie” opowiadał o tym Łukasz Węgrzyn z kancelarii SSW Pragmatic Solutions. Ekspert wskazał zestaw dobrych praktyk, które mogą ułatwić zdobycie lukratywnego kontraktu.

Dostawca musi:

  • rozumieć specyfikę zamawiającego oraz realia rynkowe i branżowe, w których zamawiający funkcjonuje. Ma to szczególne znaczenie w wypadku firm z sektorów regulowanych (bankowość, ubezpieczenia, paliwa, obronność), gdzie dużo do powiedzenia ma dział compliance,
  • przeprowadzić wspólnie z zamawiającym tzw. dekompozycję projektu – zamiast analizy przedwdrożeniowej. Ta druga szybko się dezaktualizuje, podczas gdy dekompozycja prosto opisuje, jak długo będzie tworzony produkt.
  • przedstawić zakres realizowanego projektu. Nie może go negować, powołując się na „agile” (bo „w agile’u nie ma zakresu”),
  • dostarczać dokumentację projektu – nawet jeżeli Manifest Agile uznaje ją za niezbyt ważną. Dokumentacja nie musi być dostarczana iteracyjnie,
  • dbać o wyważenie umowy. Kontrakt nie może faworyzować dostawcy, przykładowo, gdy kwota odpowiedzialności dostawcy jest za niska w stosunku do wartości projektu. Dostawca musi proponować model płatności, bazujący na dzieleniu się ryzykiem i sukcesem.
  • zapewnić możliwość szybkiego zakończenia projektu w razie wystąpienia problemów z realizacją zapisów kontraktu. Pomoże to uniknąć przetrzymywania projektów na „kroplówce”.

Dostawca nie powinien:

  • forsować swojej metodyki. Każdy zamawiający inaczej rozumie zwinność i może kierować się własnymi, wewnętrznymi metodykami. Dlatego dobrze dopasować się do zamawiającego,
  • rotować zespołami projektowymi, pracującymi u klienta ani zmieniać personelu przypisanego do projektu,
  • negocjować – na etapie formułowania umowy – klauzul o transferze know-how. Te zapisy występują w kontraktach coraz częściej, ponieważ zamawiający oprócz pozyskania nowych produktów chcą też zdobyć wiedzę.

--

"Agile w biznesie" to spotkanie skierowane do liderów zmian i kadry zarządzającej dużych i średnich firm będących w trakcie transformacji lub rozpoczynających ten proces w duchu Agile. IX edycja konferencji odbyła się 27 września 2019 r. w siedzibie Google Polska w Warszawie. W programie znalazło się kilkanaście prelekcji opartych o case studies największych firm na polskim rynku - uczestniczyło w nich ponad 120 managerów. Kolejna edycja "Agile w biznesie" we wrześniu 2020 r.


TOP 200