Szósta edycja konferencji Agile w Biznesie odbyła się 20-21 września w Warszawie i zgromadziła ponad 80 uczestników, którzy mieli okazję wziąć udział w prezentacjach case studies, pracować na warsztatach i – co również ważne – uczestniczyć w dyskusjach w kuluarach z innymi uczestnikami wydarzenia. W ramach tego artykułu przywołane zostaną trzy najlepsze (zdaniem uczestników) spośród ośmiu wystąpień z pierwszego dnia konferencji.
“Scaling Agile in Large Organization – How it Works?” Tom Willems, ING Belgium
Konferencję otworzył przedstawiciel belgijskiego ING, Tom Willems, który przedstawił podejście swojej organizacji do transformacji zwinnej i wprowadził w szczegóły skalowania agile. ING szukało modelu, na którym mogliby bazować swoją transformację i 2 lata temu zdecydowali się na SAFe (Scaled Agile Framework). Wykorzystali go jako bazę do dalszej ewolucji swojego własnego rozwiązania. Podstawą zwinności w ING są zespoły DevOpsowe, w każdym zespole zebrani są inżynierowie odpowiedzialni zarówno za rozwój jak i utrzymanie odpowiednich produktów. Ponad zespołami funkcjonują jeszcze 2 poziomy zarządzania – zespoły pracują w “pociągach wdrożeniowych” (ang. agile release trains), w których planowane są wysokopoziomowe funkcjonalności. Za zarządzanie tym wyższym poziomem odpowiada grupa właścicieli Funkcjonalności i Architekci Korporacyjni, którzy skupiają się na spoglądanie w dłuższej perspektywie niż poszczególne zespoły devopsowe. Całość spaja najwyższy poziom abstrakcji – każda funkcjonalność mapowana jest na poziomie całego portfela projektów, realizującego strategię organizacji. Tom Willems podał rozpiętość czasową tematów znajdujących się na poszczególnych poziomach portfela – kluczowe inwestycje strategiczne trwają 3-5 lat, epik to maksimum 18 miesięcy, wysokopoziomowa funkcjonalność zajmuje do 6 miesięcy.
Prelegent przybliżył też podejście swojej firmy do transformacji – na początku pokazał animowany filmik, krótko i sprawnie opisujący czym jest Scrum i SAFe. ING rozpoczęło transformację w styczniu 2015, którą poprzedziły półroczne pilotaże w 20 zespołach. Do zasadniczej transformacji zaplanowali bardzo systematyczne podejście – każdy zespół podlegał procesowi wdrożenia zgodnemu ze schematem następujących po sobie fal, które miały na celu doprowadzenie do pełnego wprowadzenia ich modelu zwinności w ciągu jednego roku. Model ten zamieniony został na rozbudowaną listę kontrolną, w którym badany jest szereg wskaźników (np. czy dostarczanie oprogramowania jest szybsze) i zmiany zachowań (np. czy odbywają się poszczególne zdarzenia scrumowe) mających doprowadzić do pożądanego stanu procesu. Oprócz pytań o efekty i mechanikę, przedmiotem badania jest też satysfakcja pracowników z agile’a – co kilka miesięcy członkowie zespołów są pytani na ile zadowoleni są z nowego podejścia, a wyniki tych odpowiedzi są agregowane w ogólny wskaźnik – i co ważne Tom przyznał, że satysfakcja pracowników była jednym z większych wyzwań i w kolejnych badaniach wynik spadał, co wygenerowało większą uwagę na ten aspekt po stronie osób zarządzających zmianą. Prelegent uprzedził ewentualne pytanie o to, czy czasem tak rozbudowane mierzenie zmiany nie było przesadzone, twierdząc, że transformacja tak dużej organizacji (1700 pracowników w IT) musi być bardzo szczegółowo monitorowana.
Spośród innych praktyk zastosowanych w trakcie transformacji warto wymienić dbałość o propagowanie informacji o zwinności – ING założyło “Agile Portal” w swoim intranecie, na którym zamieszczone było dużo informacji o ich podejściu do zwinności, podstawowe informacje o zespołach devopsowych i wyniki samej zmiany. Zadbali też o to, by zapewnić rozbudowany system szkoleń, nie tylko narzędziowych ale również skupiających się na wartościach związanych ze zwinnością, Scrumem i SAFe.
Tom Willems wymienił wszystkie miary, jakimi oceniają efekty wdrożenia agile, przede wszystkim jest to koszt dostarczania oprogramowania, jego szybkość i jakość. Sprawdzana jest też przewidywalność (czy zespoły dostarczają to, do czego się zobowiązują), satysfakcja pracowników i stabilność produktu (mierzona ilością incydentów).
Swoją prezentację prelegent zakończył krótkim podsumowaniem największych wyzwań, jakie dostrzegł w trakcie transformacji – przede wszystkim podzielił się opinią o tym, że agile polepszył im przejrzystość realizowanych inicjatyw, ale nie zmniejszył złożoności procesu. Trudno się dziwić takiej refleksji, jeśli postronnemu obserwatorowi od razu rzucało się w oczy bogactwo ról i warstw zarządzania w ich modelu. Z drugiej strony nie wiemy do końca z jakiego stanu startowali, może 3 poziomy zarządzania i 4 role właściciela (portfel, epik, funkcjonalność i zespół) to jest wyraźny postęp w porównaniu do wcześniejszego systemu.
Dużą trudność w transformacji całej organizacji sprawiał moment przejściowy, gdy jednocześnie realizowane były projekty w starym i nowym modelu, zespoły były zbyt mocno ze sobą powiązane zależnościami i musiały być przeorganizowane według produktów biznesowych, skupiając się na utworzeniu samodzielnych jednostek.
Wśród czynników mających wpływ na sukces ich transformacji Tom wymienił przede wszystkim wsparciu ze strony Zarządu banku, wystartowanie z pilotażami, które pomogły im odkryć kilka największych problemów, zanim wdrożenie zrealizowano na pełną skalę. Wymieniona została też istotność wsparcia ze strony agile coachów, którzy pomagają przeprowadzić zespoły przez zmianę, nie tylko od strony teoretycznej (jak powinien wyglądać Scrum), ale co ważniejsze – od strony praktycznej, z perspektywy osób, które kiedyś przechodziły identyczny proces zmiany i wiedzą z własnego doświadczenia, jak może wyglądać dobrze funkcjonujący zwinny zespół. Tom wspomniał też o tym, że agile jest wspierany we wszystkich jednostkach grupy ING, między innymi pokazał planowane zmiany w holenderskim ING, które wskazane zostały na filmiku. Trudno nie odnieść wrażenia, że twórcy tego modelu bardzo uważnie 😉 oglądali znaną animację “Spotify Engineering Culture”. Czy “model Spotify” może funkcjonować skopiowany jeden-do-jeden w banku? Czas pokaże…
“Holacracy is For Grown-Ups: Agile (On Steroids) For the Entire Business” Mark Vletter, Voys
Kolejną wyróżniającą się prezentacją była opowieść o kulturze zarządzania w firmie Voys.nl. Mark Vletter, założyciel i CEO tej firmy przybliżył historię rozwoju swojego startupu i ich sposób na to, by poradzić sobie bez typowego dla większych organizacji modelu zarządzania opartego na hierarchii menedżerów i przydziałów zadań do poszczególnych pracowników. Mark podkreślił, że świat przyspiesza w tempie eksponencjalnym – radykalnie skraca się długość życia firm, błyskawicznie przyrasta ilość danych, jakie generuje ludzkość, świat wokół nas przeobraża się. Modele zarządzania oparte o stałą hierarchię nie nadążają za tym tempem, organizacje powolne wypierane są przez te, które potrafią się szybko adaptować. Stąd między innymi popularność podejścia agile, które prelegent zdefiniował na swój sposób: “budować właściwe rzeczy, szybciej”. Gdy Voys urósł ponad 50 osób, zdecydował, że zamiast formować zarządzanie hierarchiczne, zaadaptował na swoje potrzeby Holacracy. W tym podejściu wszyscy pracujący w firmie pracują ze sobą również nad jej ciągłym zmienianiem. Utworzone zostały kręgi – każdy krąg ma konkretny cel związany z funkcjonowaniem firmy, a każdy pracownik pełni wiele różnych ról, często w różnych kręgach jednocześnie. Informacje o tym, kto czym się zajmuje zebrane są w systemie intranetowym, więc każdy pracownik szukający osoby odpowiedzialnej za dane zagadnienia, jest w stanie bez problemu zorientować się który krąg i kto konkretnie wykonuje dane zadanie.
Mark przywołał koncepcję propagowaną w książce “Drive” Dana Pinka – osoby pracujące nad zadaniami kreatywnymi motywuje poczucie autonomii, dążenie do mistrzostwa i posiadanie konkretnego celu. Zdaniem prelegenta istotny jest jeszcze dodatkowy aspekt, będący fundamentem dla trzech wcześniejszych wymienionych – poczucie bezpieczeństwa. Poczucie bezpieczeństwa w firmie Voys budowane jest przez szereg działań, spośród których wymienione zostały między innymi: przejrzystość (z założenia wszystko jest dostępne dla wszystkich, w tym informacje finansowe o stanie firmy), kultura publicznego przyznawania się do błędów i przepraszania za nie, dawanie sobie i szukanie informacji zwrotnej oraz równość między pracownikami. Jednym z przejawów otwartości i przejrzystości organizacji (oraz zapewne również w jakiejś części forma promowania marki) jest też upublicznianie informacji o sposobie funkcjonowania Voysa, na przykład w postaci ebooka dostępnego na voys.nl/book, w którym zawarte są informacje przekazywane nowym pracownikom na temat funkcjonowania firmy.
“Umowy “zwinne” po polsku, czyli retrospekcja po 3-letnim sprincie” Łukasz Węgrzyn
Pierwszy dzień Agile w Biznesie zakończył Łukasz Węgrzyn, prawnik specjalizujący się w temacie umów IT, który podsumował swoje doświadczenia z pracy nad umowami zwinnymi (nazywając to przewrotnie trzyletnim sprintem). Oprócz samej zawartości prezentacji warto docenić dużą dozę autoironii na temat podejścia prawników do zwinności – Łukasz zaczął od zażartowania, że wartości scrumowe (poszanowanie, zaangażowanie, otwartość, skupienie i odwaga) dla typowego prawnika są rozumiane raczej jako frazy z obszaru dyplomacji niż coś rzeczywistego. Chociażby temat zaufania jest jedną z większych bolączek polskiego rynku nowych technologii i umów z nim związanych – strony kontraktu z zasady sobie nie ufają. Tutaj Łukasz z doświadczenia zasugerował zastosowanie praktyki okresu próbnego (“rozbiegu”) albo sprintu zero. Zanim strony kontraktu zwiążą się na dłuższe umowy, warto spróbować się w jakimś krótszym przedsięwzięciu. Jeśli kultury organizacyjne dostawcy i zamawiającego do siebie nie pasują, to najlepsza umowa nie uchroni przed porażką – i te różnice kulturowe warto wykryć najwcześniej jak to możliwe. Nawet z perspektywy dostawcy warto wejść w “rozbieg”, lepiej dla realizującego kontrakt ponieść koszty na przykład trzech sprintów próbnych niż związać się na długi czas ryzykując konfliktami z zamawiającym, utratę reputacji i niezadowolenie swoich pracowników.
Prelegent podzielił się też doświadczeniami z tego, jak w praktyce realizowane są umowy zwinne i jakie odejścia od teoretycznych podstaw spotyka. Jeśli chodzi o role scrumowe, popularnym problemem jest nisko umocowany Product Owner, nie mający pełnomocnictwa do podejmowania decyzji, co zabija jakąkolwiek zwinność w realizacji – dowolne większe decyzje wymagają tygodni zatwierdzeń po stronie Zamawiającego. Zdaniem Łukasza dobrą praktyką może być wpisanie kar umownych za nieresponsywność Zamawiającego, ponieważ projekt zwinny uda się tylko jeśli obie strony umowy są równie zaangażowane i równie szybkie w swoich działaniach. Kolejną rolą często źle umocowaną w umowach zwinnych w praktyce jest Scrum Master. Zdarzają się kontrakty, w których Scrum Mastera nie ma w ogóle albo jego rola sprowadzona jest to managera zespołu wytwórczego. Problemem mogą być też niedostatecznie określone oczekiwania co do zespołu developerskiego – zmiany składu osobowego są zbyt częste, zespół nie jest samowystarczalny ani interdyscyplinarny (czyli do realizacji części prac potrzebuje posiłkować się osobami spoza zespołu, co spowalnia prace).
Łukasz wymienił też antywzorzec który spotyka w podejściu do Product Backlogu, cytując: “Oto nasz backlog z którego nic nie wynika, czyli jesteśmy zwinni”. Jego zdaniem Zamawiający mający konkretną wizję produktu, powinien zawrzeć go w Product Backlogu i nie bać się zamieścić go jako część umowy. Projekt nie jest wtedy zwinny, jeśli kompletnie nie wiemy czego chcemy, tylko jest zwinny wtedy, gdy umiemy zmieniać priorytety i reagować na sytuację zmianami w Backlogu. Stąd ważne jest, żeby częścią kontraktu zwinnego była procedura kontroli zmiany, łatwa do zastosowania i zachęcająca obie strony do dopasowywania się w trakcie prac, a nie usztywniająca do realizowania pierwotnie założonego planu.
Ostatnią częścią prezentacji była analiza możliwych modeli rozliczeń. I tutaj prowadzący prezentację sam przyznał się, że największym zaskoczeniem dla niego jest to, że oprócz klasycznych modeli Time&Material i Fixed Price chętnie adoptowany jest bardziej wysublimowany model “Cost Target Contract”. Obie strony takiego kontraktu umawiają się na przewidywany koszt kontraktu, ale po równo dzielą się ewentualnym zyskiem albo stratą. Jeśli przewidywany projekt będzie kosztował mniej niż przewidywano (na przykład 800 tysięcy zamiast 1 miliona), dostawca dostaje wynagrodzenie za pracę faktycznie wykonaną i połowę środków zaoszczędzonych (w tym przykładzie – 100 tysięcy premii). Dostawca może przejść do realizacji kolejnych projektów, a Zamawiający zaoszczędził część pierwotnie zaplanowanych pieniędzy. W drugą stronę działa podobny mechanizm – jeśli koszt projektu okaże się wyższy niż zakładany, dostawca ponosi połowę kosztów przekroczenia (dostarcza swoje usługi za połowę ceny). Zdaniem Łukasza taki model zachęca do optymalizacji czasu dostarczenia (dostawca ma motywację premii za szybszą realizację produktu projektu, co zamawiającemu umożliwi szybsze zarabianie na nim), model nie powoduje też utrzymywania kontraktu na siłę przez dostawcę (który w innych modelach rozliczeniowych ma powody, by wydłużać współpracę, bo za każdy kolejny okres ma płacone kolejne kwoty).
Podsumowanie
Podsumowując konferencję Agile w Biznesie, warto wyróżnić to wydarzenie jako dobrą okazję do porozmawiania o zagadnieniach zwinności z uczestnikami z wielu firm i co dość unikalne – osób o perspektywie menedżerskiej (wg informacji organizatorów 20% uczestników to członkowie zarządów, 60% to wyższa kadra menedżerska). Dyskusje toczyły się po prezentacjach, w czasie warsztatów zorganizowanych drugiego dnia i w kuluarach konferencji. Dobrany zestaw prelegentów pozwolił przyjrzeć się temu jak z transformacją i skalowaniem zwinności radzą sobie duże firmy z zagranicy i z Polski, z różnych branż.
Po stronie obszarów do poprawy dało się zauważyć różnorodność poziomów jakości prezentacji – główny przekaz niektórych prelegentów mógł się zagubić w natłoku materiału prezentowanego na slajdzie i chaosie wypowiedzi. Niespecjalnie dopasowana do tematyki konferencji była prezentacja o zarządzaniu projektami metodą łańcucha krytycznego – nie ujmując nic podejściu, trudno traktować je jako część szerszej rodziny metod zwinnych, a Panowie prezentujący case study bez zająknięcia opowiadali o zarządzaniu zasobami, zależnościami między menedżerem projektem a menedżerem zadania i ekscytowali się wizualizacją wykresu Gantta z zaznaczoną ścieżką krytyczną. W dyskusjach zauważyć dało się też różnorodność potrzeb uczestników – z jednej strony część słuchaczy potrzebowała wiedzy o podstawach transformacji zwinnej, ale byli też przedstawiciele firm, którzy pierwsze kroki mają już za sobą i mogli odczuć niedosyt materiałów bardziej zaawansowanych, takich jak raptem na marginesie prezentacji wspominane gildie czy większe zaangażowanie biznesu w wytwarzanie produktu (belgijskie ING nazwało to koncepcją BizDevOps).
Źródła zdjęć: organizatorzy Agile w Biznesie 2016