Agile wymaga kultury
-
- 16.10.2019, godz. 13:12
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.
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ż:
- To oni powalczą o 30 tys. euro. Znamy półfinalistów Infoshare Startup Contest
- Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24
- Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk
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
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ć.
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 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.
