Zapraszaliśmy na ostatnią edycję Agilii, a ponieważ wziąłem udział w tym wydarzeniu i było sporo wartościowych prezentacji, postanowiłem podzielić się z Wami streszczeniem wybranych najlepszych fragmentów. W tym roku konferencja ściągnęła trochę mniej uczestników niż poprzednio, ale Ci którzy się pojawili – na pewno nie żałują. Podstawowym przesłaniem wydarzenia, jakie przewijało się przez słowa kolejnych prelegentów (zwłaszcza keynote’ów), to wielkie znaczenie wizji organizacji i jej strategii. To było o tyle ciekawe, że typowe konferencje zwinne mocno skupiają się na technikach czy historiach konkretnych wdrożeń, a na Agilii wyłapałem w tym roku jednak dość odwrotny komunikat – “niezależnie od stosowanego podejścia, nie będziesz zwinny, jeśli nie masz jasnej strategii tego, dokąd zmierza Twoja firma i Twój produkt”.
Building an agile company – Vaclav Muchna
Konferencję otworzył CEO i założyciel firmy YSoft, czeskiego dostawcy rozwiązań “smart office” (m.in. drukowanie i skanowanie). W charyzmatyczny sposób przybliżył historię rozwoju swojego biznesu i filozofii myślenia o prowadzeniu firmy, jaki stosuje w praktyce. Przez pierwszych 5 lat istnienia YSoftu Vaclav twierdzi, że w zasadzie ponosili wyłącznie porażki – realizowali projekty dla swoich klientów, ale nie byli w stanie przekuć niczego w trwałe rozwiązanie, które przyniosłoby stałe dochody. Coś, z czego zaczęli sobie zdawać sprawę to fakt, że firma i jej zarządzający nie mieli wizji. Pierwszym pomysłem na jakąś wizję była koncepcja “zbudować czeską firmę, która działa globalnie”. To było marzenie założyciela i realna siła, która go nakręca w działaniu do dzisiaj – ale jako wizja firmy sprawdziło się to kiepsko, ponieważ nie ma w niej ani słowa o klientach. Dopiero po jakimś czasie udało im się ukształtować wizję, która miała sens dla całej organizacji – “umożliwiamy naszym klientom działać mądrzej dzięki naszym rozwiązaniom biurowym”. Coś co Muchna podkreślił, to fakt, że wizja musi być istotna dla całej organizacji i podlegać ewolucji wraz ze zmianą firmy. Fajnym podkreśleniem było też to, że pracownicy firmy niekoniecznie podążają za osobą lidera (mimo, że Vaclav jest ewidentnie charyzmatyczny) – podążają za wizją lidera.
Vaclav przytoczył definicję liderstwa zbudowaną na bazie pracy profesora Kaplana z Harvardu:
- Czy jesteś w stanie odkryć to, w co wierzysz i dzielić się tym z innymi?
- Czy jesteś w stanie realizować tę wizję?
- Czy robisz to w sposób, który dostarcza wartość?
Jeśli uzyskujesz pozytywną odpowiedź na powyższe pytania, ludzie za Tobą podążają, niezależnie od tego, czy jesteś liderem z władzą wynikającą z hierarchii czy nie.
Vaclav przytoczył też historię tego, jak w YSoft podchodzą do rozwoju produktu. Od samego początku pracy nad swoimi rozwiązaniami stosowali podejście iteracyjne, rozbudowywali oprogramowanie kolejnymi wersjami aż uznali, że jest gotowe do wypuszczenia na rynek. Z perspektywy czasu uważają, że to był waterfall – mimo, że oprogramowanie było realizowane w krótkich cyklach. By zrobić prawdziwie gotowy na rynek produkt musieli dokładać całą masę elementów biznesowych (marketing, dokumentację, strony sprzedażowe), które powstawały po zakończonym projekcie rozwoju oprogramowania. Zredefiniowali sobie to, czym jest rozwój produktu i obecnie iteracja odbywa się na poziomie całej firmy. Praca kilku strumieni jest zsynchronizowana i efekt iteracji rozwoju software’u przechodzi w następnej iteracji do zespołów biznesowych (Marketing, Wsparcie sprzedaży), tak by najpóźniej po jednej pełnej iteracji możliwe było urynkowienie rozwiązania. Produktem nie jest kod, produktem jest wypuszczenie usługi dostępnej dla klientów (z całym kompletem biznesowym – marketingiem, dokumentacją itd.). Coś co Muchna podkreślił, to wewnętrzny opór pracowników przed takim poukładaniem procesów – doświadczenie mówiło im, że “tak się nie da pracować”. CEO spodziewał się brania odpowiedzialności i wytrwałości w dążeniu do realizacji tego modelu, ale zaskoczyło go to, że jego menedżerowie nie byli w stanie przekonać pracowników do takiego podejścia. Mimo to naciskał całą organizację, by konsekwentnie realizowali taki model – i przyznaje, że nauczyli się tego podejścia jako cała firma wyłącznie przez jego upór. Uważa jednak, że było warto się starać i próbować, mimo trudności i wątpliwości. W efekcie z perspektywy czasu widzi, że takie całościowe podejście iteracyjne do rozwoju produktu dało korzyści na poziomie całej firmy – poprawiła się komunikacja, udało się wyeliminować silosowe podejście, korzystne efekty widać też na poziomie produktu (nowe pomysły) i jego jakości.
Competetive advantage via Lean-Agile Procurement Mirko Kleiner
Mirko swoją prezentację o uzwinnianiu procesu zakupowego zaczął od metafory z Asterixa – cała starożytna Francja jest już uzwinniona przez Rzymian i tylko jedna galijska wioska mężnie się opiera (departament zakupów). Prelegent przywołał swoją hipotezę na temat rozwoju tematu zwinności na poziomie firm. Jego zdaniem istnieją następujące rodzaje zwinności:
- Osobista
- Zespołowa
- Ogólnofirmowa
Każda kolejna przynosi większe sumaryczne korzyści, a Mirko ekstrapoluje to i zakłada, że kolejny poziom dodatkowych korzyści ukryty jest na poziomie międzyfirmowym (zwinność na poziomie firm partnerskich, np. w łańcuchu dostaw, strumieniu wartości).
Niestety na poziomie współpracy międzyfirmowej pokutuje nadal podejście, które świetnie obśmiane zostało w tym krótkim filmiku https://www.youtube.com/watch?v=essNmNOrQto .
Proces zakupowy to schemat idealnie odwzorowujący waterfalla – na początku pojawia się mnóstwo dokumentów, próbujących precyzyjnie opisać niepewność biznesową, stosowane są bramki decyzyjne, wydłużające czas faktycznego dostarczania wartości, strona zamawiająca obstawia się prawnikami i przyjmuje założenie braku zaufania do partnerów. Czas typowego procesu zamawiania w dużych organizacjach potrafi zająć 6 do 12 miesięcy, zanim zacznie się pojawiać jakiekolwiek kreowanie wartości. Mirko proponuje, by do procesu zakupowego podejść z tymi samymi założeniami, jakie stosowane są w zwinnym wytwarzaniu oprogramowania – zaangażujmy ludzi we wszystkich potrzebnych rolach od pierwszego dnia i skupmy się na szybkim dostarczaniu wartości biznesowej. Nie skreśla potrzeby zaangażowania prawnika czy negocjatora – ale w szczególności zachęca, by te kolejne specjalizacje nie pracowały kaskadowo i w oderwaniu od siebie. Narzędziem, które może zastąpić całość papierkowej roboty w takim procesie jest “Lean Procurement Canvas”. Dzięki temu, że narzędzie jest proste i że wypełniamy je zespołowo (najpierw pierwszą część po stronie zamawiającego, a potem całość wraz z potencjalnymi dostawcami), proces wyboru możemy sprowadzić do “dni zamiast miesięcy” (co jest jednym z haseł podejścia Lean Agile Procurement).
Najpierw zamawiający musi sformułować po swojej stronie oczekiwania czasowe (timeboxy), warunki związane z tą inicjatywą, potrzeby jakie mają być zaspokojone i istniejące alternatywy do tej inicjatywy. Potem dostawca (lub dostawcy) uzupełniają swoją część szablonu (umiejętności, koszty, unikalna wartość), iteracyjnie dochodząc z zamawiającym do czegoś, co ma kształt zwinnego kontraktu, spisującego wszystkie ważne elementy mające wpływ na proces decyzyjny. Całość treści, którą wypełniamy w tym narzędziu, to zgadywanie, hipotezy, które należy szybko zwalidować, by potwierdzić ich prawdziwość i poprawiać ich brzmienie wraz z odkrywaniem tego, jaka jest rzeczywistość.
Mirko przytoczył przypadek użycia tego podejścia, w którym firma po wyselekcjonowaniu 4 potencjalnych dostawców (i wypełnieniu lean procurement canvas), zaprosiła ich do zrealizowania 4 jednodniowych sprintów, po każdym z nich odbywało się review gotowego rozwiązania, a po zakończonym cyklu wszyscy zaangażowani po stronie zamawiającego mogli szybko wybrać najlepszą firmę, z która byli w stanie błyskawicznie kontynuować współpracę. Obie strony tego procesu mają interes w tym, żeby zainwestować swój czas i intensywnie współpracować podczas procesu wyboru, tak, aby skrócić czas (oczekiwania na rozwiązanie i niepewności czy otrzyma się zamówienie).
(źródło schematu https://www.lean-agile-procurement.com/lean-agile-procurement-approach/ )
Wszystkim zainteresowanych tym podejściem zachęcam do odwiedzenia strony https://www.lean-agile-procurement.com/ , gdzie znaleźć można m.in. darmowe materiały do pobrania i case studies.
“Code it. Ship it. Own it. On-call, a catalyst for agility” Roma Shah
Ostatnią prezentacją, którą chciałbym przytoczyć, była zwięzła opowieść o korzyściach z podejścia DevOps. Prelegentka jest przedstawicielem firmy rozwijającej swój własny produkt – i jak w wielu firmach z biegiem lat i zwiększaniem się ilości klientów oraz pracowników zaczęły się problemy. Produkt nie odpowiadał potrzebom klientów a wielkim wyzwaniem była jego awaryjność i powtarzające się coraz częściej niedostępności, których usunięcie trwało zbyt długo. W realiach produktów online oznacza to miliony strat przy każdej awarii – Roma przytoczyła statystyki, z których wynikało, że godzina niedostępności kosztuje od 100 tysięcy, przez milion do nawet 2,5 miliarda dolarów w przypadku największych firm. W przypadku jej firmy przyczyną powiększających się czasów niedostępności była popularna praktyka zarządzania rozwojem i utrzymaniem – odseparowanie utrzymania i utworzenie wyspecjalizowanych zespołów zajmujących się monitorowaniem i zarządzaniem operacjami IT. Z czasem wyspecjalizowany zespół utrzymania okazał się przede wszystkim zespołem wyizolowanym od pozostałych developerów, rozwijała się też kultura bohaterów – dzielnych inżynierów, którzy w pocie czoła gaszą kolejne przydarzające się pożary, bez refleksji z jakich powodów one powstają. Remedium, jakie zastosowali, to wprowadzenie kultury devops – zbudowanie odpowiedzialności za cały produkt we wszystkich zespołach, procesów współpracy, tak by właściwi ludzie reagowali we właściwych momentach i wzięli właścicielstwo na siebie. Roma podkreśliła, że kultura devops to coś, co dotyczy całej organizacji, to nie jest nowa rola, czy odpowiedzialność wybranego zespołu w ramach platformy. W praktyce devops oznacza, że ten sam zespół pisze kod, jest jego właścicielem na produkcji i reaguje na awarie. By zapewnić utrzymanie, kolejni członkowie zespołów w firmie Romy są dostępni w systemie “on-call” (dyżury), w czasie których wyznaczony przedstawiciel zespołu jest zobowiązany do przyjrzeniu się problemowi i zaaplikowaniu szybkiego rozwiązania w swoim systemie. By takie podejście funkcjonowało sprawnie, w ramach kultury devops w organizacji rozwijane są narzędzia usprawniające monitoring, powiadomienia i współpracę podczas rozwiązywania problemów. W przypadku firmy Romy wprowadzenie podejścia DevOps wygenerowało 45% więcej wdrożeń na produkcję, 25% spadek incydentów na produkcji, 50% spadku średniego czasu rozwiązania poważnych incydentów. Zdaniem prelegentki DevOps wyraźnie wzmacnia zwinność (agile) w jej firmie:
- Wspiera frameworki zwinne
- DevOps oznacza prawdziwie interdyscyplinarny zespół, odpowiedzialny za produkt w całości
- Długofalowa odpowiedzialność za utrzymanie zachęca zespół do zorganizowania sobie tego aspektu w sposób, który w jak najmniejszym stopniu przeszkadza zespołowi w pracy rozwojowej (automatyzacja, minimalizacja zasięgu awarii, sprawny monitoring)
- Zespół uzyskuje pętle informacji zwrotnej i sam odpowiada za usprawnianie sposobu radzenia sobie z utrzymaniem produkcji
- Zespół uczy się dyscypliny i uporządkowania swojej pracy rozwojowej
- Poprawia współpracę w zespole
- Współpraca jest szczególnie potrzebna przy rozwiązywaniu awarii, gdy presja czasu wymaga empatii ze strony całego zespołu i szybkiego skutecznego działania
- DevOps oznacza autonomię wraz z odpowiedzialnością, co jest składnikiem budującym motywację u inżynierów
- Postawy liderskie i odpowiedzialność za system – osoby rozwiązujące awarie naprzemiennie przyjmują postawy liderskie, trudne doświadczenia rozwijają w przyszłości mocniejsze usprawnienia co do sposobu pracy całego zespołu, żeby unikać problemów (wymiana wiedzy, rozwiązania lepszej jakości, usuwanie słabych punktów w produkcie)
- Usprawnia produkt
- Podejście DevOps pozytywnie wpływa na jakość kodu i narzędzi developerskich
- Każdy developer czuje osobiście wagę swoich decyzji, odpowiada za zadowolenie klienta (nie tylko za dostarczanie kolejnych funkcji, ale też za niezawodność usług)
Roma przywołała ze swoich doświadczeń kilka przemyśleń na temat skutecznego wprowadzania kultury DevOps i podzieliła się nimi jako rady dla wszystkich słuchaczy:
- Zbuduj zrozumienie tego, dlaczego developerzy powinni być odpowiedzialni za produkt w całości
- Nie buduj zespołów testerskich ani utrzymania – takie silosy są w sprzeczności z filozofią DevOps, zatrudniaj do zespołów developerów “full stack”
- Zainwestuj czas w automatyzację testów i środowisko Continous Integration, jeśli nie masz dobrego monitoringu – jest on również niezbędny
- Przy dyżurach sprawdziło im się podejście rotacyjne, w którym każdy członek zespołu od czasu do czasu odpowiada za reagowanie na awarie, zgodnie z ustalonym harmonogramem. “Dyżurny” odpowiada osobiście za usunięcie awarii (może szukać wsparcia ze strony innych ekspertów, ale nie powinien przekazywać zadania do innego członka swojego zespołu)
- Każdy incydent jest otwarty dla wszystkich, mogą go obserwować, dołączyć do jego rozwiązania jeśli mają jakiś pomysł, uczyć się z rozwoju sytuacji
- Miarami sukcesu podejścia DevOps są krótsze cykle dostarczania, krótszy czas rozwiązywania awarii oraz krótsze i rzadsze niedostępności produktu. Ale warto też przyjrzeć się pozytywnym efektom ubocznym – można spodziewać się wzrostu satysfakcji klienta (bardziej niezawodny produkt), wzrostu produktywności zespołów (szybsza naprawa błędów, lepsza jakość produktu i narzędzi) i większej satysfakcji pracowników.