Skalowanie zwinności

utworzone przez Marcin Żmigrodzki

Obok budowania motywacji wewnętrznej, skalowanie zwinnych projektów na całą organizację jest moim zdaniem Graalem, którego poszukują zarządy.

Tak, jak warto mieć zaangażowanych ludzi, którym chce się podważać status quo i wdrażać innowacje, to duże organizacje chciałyby sklonować ideę małego zwinnego projektu na całość firmy.

Przez nasz kraj, podobnie, jak przez całą zachodnią gospodarkę przelała się fala transformacji zwinnych. Dotknęła ona szczególnie sektor finansowy i telekomunikacyjny, czyli wszędzie tam, gdzie wymagana jest wysoka innowacyjność oraz większość projektów zależy od zmian w głównych systemach informatycznych. Co ciekawe ta fala transformacji agile nie dotknęła sektora produkcji, ani usług publicznych. Jednak tam, gdzie pojawiła się, pozostawiła ślad. W poniższym tekście zbiorę moje refleksje na temat tego, jak mogłaby a jak wygląda taka transformacja.

Kontrola vs. zwinność

Duże organizacje potrzebują kontroli i struktur. Struktur organizacyjnych: działów, pionów, sekcji, bo człowiek ma ograniczoną rozpiętość kierowania i komunikacji, struktur zakresu: WBS, epic/feature/story/task, bo długie listy zadań mają tendencję do zaśmiecania się, struktur kosztów: budżety działowe, projektowe, zadaniowe, bo tak jak łatwiej rozliczać i kontrolować wydatki, struktury czasu: plany strategiczne, mapy drogowe, kamienie milowe, daty wypuszczeń, Gantty, wersje, bo podobnie jak przy kosztach tak łatwiej jest kontrolować rzeczywistość.

Natomiast pojedynczy zespół dobrze, aby pozostawał zwinny, ze zbiorową odpowiedzialnością, płaską strukturą, krótką listą zadań, planem na najbliższy sprint i nie zwracaniem uwagi na budżet.

Według metodyk skalujących agile gdzieś po drodze powinna zajść transformacja z klasycznego zarządzania i waterfall na agile. I jeszcze powinna ona być niezauważona dla zespołów, aby nie psuć zaangażowania. Na górze mamy plany bazowe, procenty realizacji KPI, odchylenia od terminów mapy drogowej, a na dole autonomię i swobodę.

Toteż dochodzi do wypaczeń. Przykładowo wg SAFE nadal wyceniajmy zadania w storypointach, ale cichaczem umówmy się, że 1 storypoint = 1 dzień i porównujmy produktywność między zespołami oraz wprowadźmy analizę odchyleń.

To magiczne przejście od agile do waterfall zachodzi przez stopniowe dokładanie kolejnych wskaźników kontrolnych. To tak jakby gotować żabę, jak będziemy robili to powoli, to może nie zorientuje się, że już nie jest taka zwinna. Drugi sposób na przejście to zrzucenie odpowiedzialności na kierowników projektów. Od góry można ich rozliczać z celów i planów bazowych, a od dołu zmusić do współpracy z niezależnymi zespołami. Piszę to z dużą ironią, bo oba sposoby na przejście od agile do waterfall często generują serie konfliktów.

Ciekawy przykładem kontroli na górze a zwinności na dole jest model spiralny Barry’ego Boehma stosowany w DARPA. Projekt w nim przechodzi przez cykle inicjacji, produkcji i walidacji, które pozwalają na utrzymanie kontroli inwestycyjnej, ale na dole, na poziomie zespołu może być tak zwinny, jak tylko chce.

Jeden ze znajomych, poddany transformacji agile, przytoczył mi ciekawy argument. Na ogólne narzekanie na bałagan powstały po transformacji zapytałem go, a gdzie to dobrze działa. Odparł, że tam, gdzie jest dobry product owner z biznesu, który wie czego chce, rozumie naturę technologii i ma na wyłączność zwinny zespół technologów. Podoba mi się ten argument. Aby transformacja agile powiodła się musimy mieć wielu product ownerów o wysokich kompetencjach biznesowych i elementarnych technicznych, którzy wiedzą czego chcą i mają na wyłączność swoje zespoły. Wraca nam idea lidera transformacyjnego, ale w wydaniu nie dyrektora a product ownera.

Problemem tylko jest fakt, że zespoły częstokroć nie są dostępne na wyłączność. Ludzie migrują, zespoły migrują i generalnie mamy dużą macierzowość. Podejście kaskadowe za pomocą szczegółowego planowania radzi sobie z tym wyzwaniem, natomiast agile ma tu problem i ludzie często wpadają w multitasking.

Motywacja do innowacji

Dlaczego organizacje potrzebują przejścia od kontroli do zwinności na poziomie pojedynczego zespołu. Powodów jest kilka: moda, argumenty rekrutacyjne dla nowych kandydatów („my nie jesteśmy złą korporacją, żółty ptak z ulicy Sezamkowej też był wielki a jaki sympatyczny”). I wreszcie mamy najważniejszy argument, tj. pozostawienie autonomii, bo ta buduje motywację wewnętrzną, zaś motywacja wewnętrzna jest silnie skorelowana z innowacyjnością.

To nie jest niewykonalne. Mimo skomplikowanych metodyk można nie niszczyć zaangażowania. Wszystko zależy od stylu, tak stylu, który każe powstrzymywać się od przesadnej ingerencji i wysłuchać maluczkich, bowiem w nich tkwi potencjał.

Pozytywny wniosek jest taki, że styl zachowania się lidera, niezależnie od przyjętego frameworku pozwala zachować poczucie autonomii w zespole. Chodzi o to, aby ludzie rozumieli uzasadnienie decyzji i mogli wywrzeć na nią wpływ.

Inżynieria oprogramowania

SAFE fajnie uwzględnił to, że oprogramowanie buduje się w specyficzny sposób, inaczej niż domy, inaczej niż nowe produkty AGD i inaczej niż kampanie marketingowe dla przykładu. Znajdziemy tu architektury, infrastruktury, wydania, stabilizację jakości, specyficzne role, jak analitycy, programiści i testerzy. I moim zdaniem dobry framework powinien uwzględniać specyfikę produkcji w danym sektorze.

Stosowanie sztywnych wydań, gdy sednem projektów jest tworzenie hardware’ów i logistyka komponentów nie działa tak, jak pisanie kodu, nie ma sensu. A z takiej założenia wychodzi Scrum for Hardware, co z resztą było gwoździem do jego trumny.

Dzielenie się wiedzą

Innowacje potrzebują kilku rzeczy, wybrane z nich, które akurat sobie przypomniałem to: zasoby, autonomia, presja na kreatywność oraz wiedza. Bez wiedzy odkrywamy koło na nowo i rzucamy infantylne pomysły.

Zwinność niestety może powodować zamykanie się zespołów w swoich bąblach poznawczych. Owszem w Scrumie regularnie dochodzi do dzielenia się wiedzą: na standupach, w ciągu dnia na kawie, na Slacku, czy na retrospektywie, ale ten oddziaływanie jest ograniczone do zespołu. Wiedza nie paruje na całą organizację tak, jakby mogła.

Spotify proponuje odpowiedź na to w postaci idei gildii, SAFe wspólnoty praktyków, DAD proponuje wszystko, co się da, więc pewnie też coś na dzielenie się wiedzą. Jednak bariery siedzą w mentalności ludzi a nie w technikach. Ja muszę nie bać się zadać pytania, ja muszę być krytyczny wobec siebie, aby wiedzieć, kiedy stanąłem pod ścianą i dopiero wówczas poproszę o pomoc. Z drugiej strony mój światły kolega musi mieć czas na udzielenie mi pomocy. Tego nie zbuduje się technikami, tylko budowaniem motywacji oraz świadomości.

Wdrażanie

I tu dochodzimy do szalenie ważnego aspektu, który bywa pomijany przez takich gigantów zarządzania, jak IPMA, PMI, IIBA, natomiast całkiem ładnie obsłużył go SAFE. W jaki sposób wdrożyć daną metodykę? PMBOK Guide ma z dodatkami około 1000 stron, a wdrażaniu metodyki na nim opartej poświęcono może z dwie. Nie da się wziąć encyklopedii i jej zainstalować w organizacji, a o tym zapomnieli twórcy DAD.

Potrzebne jest opracowanie drogi wdrażania skali w agile, a niekoniecznie konkretnego frameworku. Z resztą sam Spotify oznajmił ustami jednego z technologów, że model nazwany imieniem firmy już dawno wygląda inaczej. Nie ma właściwie modelu Spotify, jest kultura organizacyjna, która prowokuje do ciągłej ewolucji w imię autonomii zespołów i skoordynowanego rozwoju strategicznego.

Warto wspomnieć, że tą rolę, przewodnika po drodze ku transformacji, starają się też wypełnić konsultanci oraz wewnętrzni liderzy zmian.

To, co ostatecznie przebije się po dzisiejszym kryzysie transformacji agile, to podejście indywidualne. Organizacje raczej będą konstruowały własne frameworki, nazywając je jedynie za pomocą znanych terminów jak SAFE czy Spotify. Zwinność jest raczej drogą niż celem. Takie podejście sprawdziło się w lean i waterfallu. Do doskonałości można dążyć, podejmując dziesiątki racjonalnych decyzji i wybierając własną ścieżkę. Ale doskonałości nigdy nie osiągniemy.

Organizacje krok po kroczku powinny wskazywać priorytety w uzwinnianiu i utrzymywaniu kontroli. Tutaj wyraźnie widoczna jest cykliczność, na przemian zarząd uelastycznia zespoły, dając im autonomię i usztywnia przywracając kontrolę. Wszystko po to, aby znaleźć właściwy balans.

Z każdą taką pętlą uzwinniania/usztywniania wdrażane są kolejne techniki i metody pracy. A to retrospektywa, a to zakres opisany od strategii do zadania, a to sprinty, a regulowane release’y, a to samoorganizujące się zespoły, a to monitorowanie pracy, aby wyłapać wąskie gardła. Nie ma jednej drogi. Jest odkrywani, co organizacji pasuje najlepiej w danej chwili, a co trzeba zmienić.

Dla uczciwości dodam, że DAD przywołuje koncepcję Choose Your WOW, czyli wybierz swój sposób pracy. Ale robi to na tak ogólnym poziomie i zasypuje tak dużą ilością technik od sasa do lasa, że DAD staje się niestrawny.

Podsumowanie

W tytule artykułu przytoczyłem wykres popularności wyszukiwania Google Trends dla SAFe i kilku innych frameworków/metodyk. Jak widać trakcję uzyskały dwa, a jej skalę widać w porównaniu do na przykład PMI DAD – Disciplined Agile Delivery – to ta czerwona niewidoczna linia na wykresie.

Dlaczego akurat SAFE i Spotify się przebiły? Mam dwa argumenty: właściwy czas, łatwość wdrażania, adresowanie właściwych problemów. Oba modele pojawiły się dość wcześnie, gdy zainteresowanie skalowaniem dopiero narastało. DAD dołączył dużo później, co IMHO wykluczyło go z rywalizacji. Oba modele też adresują istotne potrzeby. SAFE streściłbym do potrzeby przez zarząd kontroli wśród wielu „zwinnych” projektów. Celowo słowo „zwinny” oprawiłem w cudzysłów, bo często przy wdrażaniu SAFE gubiona jest filozofia i mindset agile. DAD natomiast stara się budować kulturę współpracy z pominięciem wielu „twardych” aspektów, jak inżynieria oprogramowania, czy struktury decyzyjne. Na swoje nieszczęście LESS i S@S znalazły się w rozkroku pomiędzy dwoma atraktorami. Jak zarząd chciał utrzymania kontroli w zwinności uwaga firm ściągana była przez SAFE, jak natomiast firma chciała zbudować zwinną kulturę, nie ingerując w operacje i projekty, to w kierunku Spotify.

Jednak jak widać nawet te dwa wiodące podejścia również szczyt mają już za sobą.