Podsumowanie V edycji Agile w Biznesie

Agile w Biznesie22 i 23 września odbyła się konferencja Agile w Biznesie, a podsumować warto pierwszy dzień, składający się z prelekcji, głównie case studies z dużych firm polskich i zagranicznych. Summa summarum prezentacje utrzymały dość zaskakująco wysoki poziom (moje oczekiwania były ciutkę niższe). Podsumuję trzy moim zdaniem najlepsze prezentacje, które nie były jeszcze na naszych łamach opisane, i muszę dodać, że na ustalonym już wcześniej poziomie stanął również Łukasz Węgrzyn, który opowiedział o kontraktach zwinnych, ale zawartość tej prezentacji była już przytaczana na naszych łamach przy okazji podsumowania Scrumdays.

Edgar van Zoelen „Sustainable Agile Transformation within Philips”

Najmocniejsza pod każdym względem w mojej ocenie była prezentacja Edgara z Philipsa, który przybliżył słuchaczom historię transformacji agilowej w tej korporacji i podzielił się paroma lekcjami, których się wszyscy w tej firmie nauczyli przy tej okazji. Transformacja w Philipsie rozpoczęła się w 2011 roku i ostatecznie dotyczyła w sumie 10000 ludzi na całym świecie zarówno w IT jak i w biznesie. Zmiana rozpoczęła się od ruchu entuzjastów, którzy małymi krokami, konsekwentnie rozprzestrzeniali wiedzę o agile, próbowali zmieniać zespoły i propagowali rezultaty, jakie uzyskiwali. Na początku ten ruch entuzjastów liczył zaledwie 4 osoby, w końcu grupa ta (nazwana Agile Center of Excellence) urosła do 12 osób, które zajmują się w Philipsie szkoleniami i coachingiem agilowym. Bardzo ważną lekcją w pierwszych etapach zmiany było jednoznaczne odpowiedzenie sobie na pytanie, dlaczego w ogóle zmiana była potrzebna – w przypadku Philipsa proces zarządzania projektami był ciężki, sformalizowany, a projekty przekraczały planowane koszty i miały opóźnienia.

„za dużo procesów, za dużo zasad, niskie zaangażowania, brak radości z pracy – typowa organizacja która tak naprawdę nie działa” Edgar van Zoelen o Philipsie przed transformacją agilową

Edgar przywołał też klasyczne 8 kroków zmiany Kottera, które w przypadku zespołu transformującego Philipsa stały się mapą drogi ku zmianom – kolejne kroki pogrupowali w przygotowanie klimatu do zmiany, umożliwienie zmiany w całej organizacji oraz wprowadzenie i utrzymanie zmiany. Co ważne w przypadku opowiedzianym przez Edgara, zmiany postępowały i przechodziły do kolejnych etapów zaawansowania, mimo że pierwsze zespoły scrumowe zazwyczaj startowały od regularnych niepowodzeń – jednak grupa wspierająca zmianę sprawiała, że te porażki nie były zamiatane pod dywan, a cała firma z tego uczyła się kolejnych kroków.

Bardzo istotną radą przywołaną przez Edgara było wyszukanie sponsorów na poziomie zarządu firmy (zwłaszcza przy tak dużych korporacjach międzynarodowych brzmi to jak niezwykle istotny aspekt). W tym konkretnym przypadku CEO i CIO całej firmy byli osobiście zaangażowani w zmianę, popierali ją i oczekiwali jej, m.in. poprzez osobiste wystąpienia na temat ich wizji zwinności przed całą firmą.

Dużą zmianą kulturową dla Philipsa było zerwanie z długofalowym planowaniem, który usztywniał cały proces projektowy, zamiast tego wprowadzili krótkie okresy releasowy (do 3 miesięcy), które podlegały planowaniu i roadmapowaniu, każdy taki plan mógł jednak ulegać zmianie w trakcie iteracji – tu Edgar przywołał porównaniu do drużyny piłkarskiej, która wychodzi na boisko z pewnym planem, w konkretnym składzie i z taktyką, ale w miarę rozwoju sytuacji wszystko to może podlegać zmianom (zamierzonym i niezamierzonym).

Gdy agile zaczął się rozszerzać w organizacji, natrafili na „spowalniacze” – pojawiły się w firmie osoby zajmujące konkretne role, które spowalniały adopcję, a nawet chciały ją zatrzymać. Philips w konkretnych biznesach operuje na bardzo regulowanych rynkach i osoby odpowiedzialne za compliance zaczęły wysuwać argumenty o tym, że agile nadaje się do małych projektów i jest swego rodzaju utopią, ale dla poważnych przedsięwzięć trzeba przestrzegać procesu waterfall. W takich sytuacjach niejeden agent zmiany może się załamać, ale agiliści z Philipsa wytrzymali dzięki optymizmowi 😉

W dalszych etapach zmiany, gdy agile zaczął stawać się standardem przynajmniej w części zespołów, zespół Edgara bardzo mocno skupił się na udowodnieniu różnicy, jaką dzięki agile zaczął osiągać Philips.  Dowody były bardzo różne i zawierały m.in. wzrost satysfakcji współpracy z IT czy skrócony czas od pomysłu do rozpoczęcia implementacji (zaczynali z 50 dniami, potem zeszli do 20 dni, w tej chwili w ponad 100 zespołach ten czas jest bliski zeru – stałe zespoły współpracują wprost z PO z biznesu, który zarządza priorytetami bez żadnego dodatkowego procesu spowalniającego innowacje). Wymienione zostały również oszczędności finansowe wynikające z produktywności i skrócenia czasu projektów (przy skali tej firmy te kwestie sumowały się do milionów euro).

Najważniejszym wnioskiem, jaki Edgar przytoczył było filozoficzne stwierdzenie, że agile to nie proces, metoda czy narzędzie, ale jest to sposób myślenia, mindset.Projekt Everest - 500 osób w 40 zespołach scrumowych i kanbanowych

Case projektu Everest z PZU

Michał Kopyt i Wojciech Chmielewski z PZU opowiedzieli o agile z perspektywy zarządzania programami, w zamierzeniu mieli udowodnienie, że również z poziomu portfela i całej grupy przedsięwzięć to podejście ma sens. Prezentacja była pełna metafor i „złotych myśli”, które warto obejrzeć osobiście, pisemna relacja nie ma szans przytoczyć ich trafnie i w całości. Michał z Wojtkiem opowiedzieli o projekcie Everest (500 osób w projekcie, zebranych w 40 zespołów scrumowych i kanbanowych), a co warte podkreślenia, opowiedzieli o tym projekcie na jeszcze inny sposób (a widziałem już 4 różne prezentacje w tym temacie), przytaczając nowe smaczki i perspektywy. Pierwszym wnioskiem była obserwacja, że po 2-3 udanych latach projektu, podejście agile w całym PZU staje się normą, nikogo nie dziwi chęć realizacji kolejnych projektów w ten sposób. Wypracowanie tego zajęło dużo wysiłku i po drodze było niemało potknięć i porażek, ale właśnie dzięki zwinnemu podejściu, częstej inspekcji i adaptacji pojedyncze problemy nie powodowały kaskadowania problemu na całe przedsięwzięcie. Coś, czego też cała firma musiała się nauczyć, to przejrzystość – jednoznaczne wyniki pracy zespołów scrumowych, informacje o postępach nie podlegały interpretacji, co zaczęło oznaczać również wczesne informowanie o problemach i ew. zagrożeniach dla konkretnych faz, czy grup działań mających określony termin. Przejrzystość pracy, mówienie prawdy szczególnie przypadło do gustu członkom zarządu.

Ciekawy był też dla mnie wątek zatrudniania właściwych ludzi – w ramach projektu jedną z wytycznych było to, by liderzy zatrudniali ludzi tak dobrych jak oni sami lub lepszych. W całą filozofię projektu wpisane było to, by zespoły składały się z jak najlepszych fachowców, a liderzy mieli ich jeszcze dalej rozwijać, a nie traktować jak bezwolną masę, która w każdej chwili może zawieść oczekiwania i być zwolniona. Zerwano też z zasadą hierarchiczności i Product Owner zespołu scrumowego niejednokrotnie musiał bezpośrednio rozmawiać z członkami zarządu, by wielostronnie wszyscy udowodnili sobie, że PO to osoba kompetentna, której można zaufać i której można przekazać prawo do pełnego decydowania o pracach zespołów.

Historia transformacji esky

Trzecią prezentacją, którą przytoczę w całości, była ostatnia prezentacja w całym programie pierwszego dnia, case study transformacji agilowej w firmie esky. Wystąpienie było nietypowe, ponieważ odbyło się przez Skype, ale nie wpłynęło to na zawartość merytoryczną przekazaną przez Piotra Mynarskiego, CTO tej firmy. Piotr przywołał całą historię transformacji, którą w tej relacji skrócę do najciekawszych moim zdaniem ostatnich kroków. Esky eksperymentował ze zwinnymi procesami już 4 lata temu, wtedy robili to bardzo intuicyjnie i bez żadnego wsparcia merytorycznego. Pewne pierwsze zmiany związane z odejściem od waterfalla dały im drobne korzyści, ale zapędziły ich też w duży problem jakości platform które rozwijali, więc wprowadzili silną rolę architekta, wzmocnili testerów i wrócili do podejścia projektowego, w ramach 4 tygodniowych iteracji. Ta zmiana nie przyniosła pokładanych w niej nadziei i w dodatku wyraźnie oddaliła biznes od IT, który odgrodził się warstwą architektów. Gdy tylko zespoły urosły trochę, okazało się, że jakakolwiek synchronizacja między specjalizowanymi warstwami technologicznymi przestaje być możliwa, a architekci są wąskim gardłem.

Postanowili wejść na poważnie w agile – utworzyli zespoły interdyscyplinarne, skrócili iteracje do dwutygodniowych sprintów, pocięli wielkie projekty na nieduże funkcjonalności i zaczęli je wdrażać jak najczęściej, w czym wydatnie pomogło wprowadzenie automatyzacji testów i zbudowanie CI/CD. Piotr przywołał też istotną rolę współpracy z trenerami scrumowymi, którzy pomogli dogłębnie zrozumieć scruma i wskazać na miejsca, w których możliwe są usprawnienia. Zatrudnieni zostali też doświadczeni Scrum Masterzy oraz powołano wewnętrznego Agile Coacha i te osoby wspólnie rozwijają zwinność całej organizacji. W tej chwili esky w opinii Piotra znajduje się w fazie ciągłego doskonalenia – nie mają już pierwotnych problemów z jakością czy dostarczaniem, ale nadal wyzwaniem jest skalowanie się i efektywna komunikacja w całej firmie, która urosła już do ponad 100 developerów.

Historia esky w dość zgrabnej pigułce pokazała zmienne losy transformacji i możliwe przeszkody, lista wniosków przytoczonych na końcu prezentacji wydaje się dobrze oddawać to, co można i trzeba robić w takich zmianach – współpracować na poziomie całej firmy, nie wprowadzać scruma zaczynając od zmieniania go na swoją modłę, edukować wszystkich członków zespołów, czym jest agile i współdziałać blisko z biznesem, by zrozumieli, co jest potrzebne, by razem zmienić proces dostarczania innowacji produktowych.Konferencja Agile w Biznesie

Podsumowując dzień prelekcji na Agile w Biznesie, średnio rzecz biorąc poziom prezentacji był niezły i z większości nieopisanych przeze mnie wystąpień również dało się wyciągnąć parę ciekawych lekcji. Bardzo imponuje mi zebranie w jednym miejscu takiej ilości studiów przypadków, w zasadzie uniknięto wystąpień teoretycznych czy filozoficznych. Sama konferencja ma swoją konkretną grupę docelową i opowieści o faktycznych sytuacjach i wnioskach z prawdziwych transformacji mogą być inspirujące na swój sposób zarówno dla tych, którzy zaczynają swoją przygodę z agilem w większej organizacji, jak i tych, którzy działania uzwinniające firmę aktywnie u siebie podejmują.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x