Agile @ Scale

PMBOK powstał jako encyklopedia zarządzania projektami, korzystając z której firmy muszą zbudować własną metodykę przez właściwą selekcję i adaptację metod. Dwadzieścia lat temu pojawiło się kilkanaście metodyk zwinnych, z których świat zdominował Scrum z elementami Kanban i XP. Te podejścia zwane też procesami lub frameworkami mają nieco inną logikę. Przykładowo Scrum Guide prezentuje konkretny zestaw terminów, technik, spotkań, dokumentów, ról, które powinny się pojawić w zespole praktykującym zwinność. Im więcej pojawiało się projektów zwinnych, tym więcej organizacji odczuwało potrzebę koordynacji wielu równoległych zespołów realizujących powiązane albo oderwane od siebie inicjatywy. Wśród nich można wymienić LESS, Scrum@Scale, Scrum of Scrums, SAFE. Są to schematy postępowania/metodyki zarządzania dużymi zespołami ludzi zaangażowanych w projektach zwinnych. Generalnie wiele organizacji doszło do wniosku, że Scrum jest świetny, ale w małej skali. Gdy mamy do czynienia z kilkuset specjalistami, ograniczona kontrola, trudności planowania strategicznego, rozmyte role zaczynają doskwierać. Tu pojawia się Disciplined Agile Delivery, który oferuje ponad setkę wszelkich technik i metod ze świata zwinnego i kaskadowego, bo znajdziemy tam na przykład UML, który jest fundamentalnie waterfallowy. DAD zgodnie z logiką PMBOK mówi, że organizacja powinna wybrać swój styl pracy (według sloganu choose your way of work - WOW). Jednak DAD ma braki, które są siłą SAFE. To znaczy nie oferuje sposobu dobierania technik, praktyk, metod, ról, dokumentów do konkretnych potrzeb organizacji. Autorzy po prostu wysypali klocki na podłogę i oznajmili - macie tu zabawki a teraz zbudujcie z tego coś sensownego. Problemy, które przysparza DAD są powieleniem problemów w czytaniu PMBOK Guide. Brak refleksji jest tym bardziej zaskakujący, że właścicielem obu encyklopedii jest PMI. SAFE zaoferował bardziej jednoznaczną procedurę. Stworzył nawet cztery konfiguracje od prostej do bardzo rozbudowanej, jak wdrażać tę metodykę. I mam wrażenie, że to podejście zakładające prowadzenie za rękę zdecydowało o sukcesie. SAFE nie jest doskonały i zaczyna wśród firm narastać rozczarowanie tą metodyką. Ale na dzisiaj jest chyba najlepszym kompromisem. Wydaje się, że sztywny framework, który na górze jest kaskadowy, a na dole zwinny nie jest remedium dla wszystkich organizacji. Dzięki uprzejmości Pawła miałem możliwość obejrzeć ciekawy wystąpienie na temat ciekawego wdrożenia metodyk zwinnych w dużej skali. Co było charakterystyczne, to z sukcesem zaadaptowanie wielu różnych koncepcji na potrzeby tej organizacji. Trudno mi ocenić efekty tego wdrożenia, bo miałem okazję wysłuchać jedynie jej koordynatora, natomiast brzmiała rzetelnie. Powyższe spostrzeżenia nakłoniły mnie do refleksji na temat skalowania agile. Odnoszę wrażenie, że nadszedł czas, by ktoś połączył silne strony LESS, SAFE, SoS, S@S z silnymi stronami PMBOK i DAD. Mam na myśli z jednej strony spis przydatnych zagadnień ze świata zwinnego i hybrydowego, ale nie 100 terminów, tylko 20-30 faktycznie istotnych. Z drugiej strony przepis, jak skonstruować z nich framework agile@scale dla zadanej organizacji, która ma pewne nawyki, pewne silne strony, jest poddana presji rynku i ma bariery technologiczno-prawne. Z trzeciej strony książka podałaby kilka 3 do 10 różnych wariantów wdrożenia takich frameworków od małej firmy realizującej 3 projekty równolegle, przez software house z 100-500 programistami, przez firmę realizującą hybrydowe projekty, przez firmę, która utrzymuje jeden duży system rozwijany wieloma zespołami i wymagający synchronizacji wdrożeń, przez wielką korporację z kilkoma tysiącami pracowników. Z jakich elementów mógłby składać się taki framework?

Części wspólne

Na dole jest zespół Scrumowy. Zakres ma charakter hierarchiczny, ale stara się udawać zwinność. Czyli na dole backlog, a wyżej różne sposoby grupowania zakresu. Klonowanie spotkań na różnych poziomach organizacyjnych. Przykładowo może być planning theme, potem plannigów epic, potem planning backlogów zespołów. Review programów na poziomie strategii, review w tribe'ach, review w zespołach. Wielokierunkowa macierzowość organizacji. Tribe, wspólnoty, zespoły, linie biznesowe, centra kompetencji przenikają się ze sobą. To z jednej strony ma zapewnić wpływ na decyzje firmowe pracownikom, a z drugiej pozwolić na dogadywanie kompromisów w różnych kontekstach.

Strategia

Firmy planują swoje długofalowe działania w sposób kaskadowy. Stawiają cele, przygotowują budżety, rezerwują media, stawiają inwestycje, komunikują zamiary do udziałowców. Literatura oferuje wiele technik planowania strategicznego. Oferuje też kilka koncepcji kaskadowania celów na poziom wykonawczy: OKR, balanced scorecard, KPI, zarządzanie przez cele, Obeya/A3 i pewnie jeszcze kilka innych. Ciekawe jest też spojrzenie na cele strategiczne. Dotąd popularne cele to był zysk, zajęcie udziału w rynku, operacyjne koszty trzymane w ryzach, liczba nowych klientów, retencja klienta, wysoka jakość. Teraz często pojawia się skracanie time-to-market. Mam wrażenie, że ten czynnik staje się kryterium, za którym podążają inne.

Struktura organizacyjna

Na górze mamy szczególnie w dużych organizacjach piony, działy oraz prezesów i dyrektorów. Na dole mamy autonomiczne, małe zespoły. Po drodze pojawiają się menadżerowie programów, menadżerowie produktów, szefowie centrów kompetencyjnych, liderzy tribe'ów, kierownicy projektów, liderzy zespołów, eksperci, product ownerzy, scrum masterzy.

Zakres

Kaskadowa strategia, schodząc w dół, płynnie ewoluuje w kaskadowy zakres, a potem w zwinny. Po drodze spotykane są takie koncepcje, jak WBS, produkt, theme, epic, historyjka, product backlog, sprint backlog, zadanie. Po drodze pojawiają się pojedyncze wątki dotyczące zarządzania wymaganiami i prowadzenia projektów w trybie discovery/exploratory. Przykładem jest koncepcja Dual Track, czy Rapid Learning Cycles.

Czas

Na poziomie strategicznym są z reguły mapy drogowe, kamienie milowe, roczne plany. Na dole mamy sprinty i zmienne incrementy. Sztuką jest pogodzenie takiego ognia z wodą. SAFE próbuje dokonać tej sztuki, ale moim osobistym zdaniem wygląda to kulawo. Ciężko jest bowiem pożenić baseline'y ze sprintami. Osobnym aspektem pozostaje synchronizacja, którą dobrze opisał tylko SAFE. Ciekawa jest tutaj koncepcja Agile Release Trains lub jej mutacje, jakie wytworzyły różne korporacje w oparciu o swoje procesy zarządzania release'ami.

Koszty

Większość frameworków ignoruje ten wymiar, jednak trudno wyobrazić sobie funkcjonowanie organizacji bez aspektu kosztów. Na poziomie strategicznym istotne jest nie tylko to, ile projekt będzie kosztował, ale też, czy firma po drodze nie zbankrutuje i czy zachowa płynność przepływów pieniężnych. SAFE trochę dotyka tego obszaru, wprowadzając Lean budgeting. Ciekawe jest podejście zakładające zdelegowanie decydowania o budżetach z poziomu zarządu na poziom zespołów. Faktycznie jest to spójne z ideą autonomii, ale czy menadżerowie są na to gotowi? Nie wiem.

Ryzyka

Tu silny aspektem są różne rodzaje wspólnot praktyków organizowanych wokół kluczowych kompetencji technicznych i biznesowych. Mają one prowadzić do nieformalnego uczenia się i zapobiegania w ten sposób ryzykom. Drugi aspekt to retrospektywy organizowane w małych zespołach. Pytanie, kiedy, wzorem armii amerykańskiej, rozpocznie się organizowanie retrospektyw strategicznych, na poziomie setek pracowników. Nie spotkałem takich przykładów w literaturze i przypadkach firm, ale w armii już tak. Pomijalny jest narazie aspekt zarządzania ilościowego ryzykiem.

Przywództwo

Idąc z góry na dół następuje płynne przejście od planowania i kontroli do autonomii. Od motywacji wewnętrzno-zewnętrznej do motywacji wewnętrznej, przynajmniej w założeniach. Od tradycyjnego kierowania, czasem wręcz autokratycznego, do wspierającego przywództwa i podejmowania decyzji przez zespół. Podsumowując, kolejne organizacji starają się wyskalować agile, czyli coś, co sprawdziło się w małej skali, a nie wiadomo, jak ma działać w dużej. Kaskadowe podejście oferuje sporo wartości, jak kontrolowalność i przewidywalność, możliwość optymalizacji użycia zasobów i planowania rozwoju architektury technicznej. To wszystko kosztem centralizacji decyzji, spadku elastyczności i często dłuższego czasu time to market. I na te problemy firmy próbują znaleźć remedium w skalowaniu zwinności. Powoli krystalizuje się, w jaki sposób to mogłoby działać. Sądzę, że gdy zbierzemy już 30-50 dobrych przykładów funkcjonowania takich frameworków przez kilka lat, będziemy w stanie wyłuskać z nich dobre praktyki, które generalnie działają. Trzeba tylko trochę poczekać i poświęcić kilka organizacji na ołtarzu postępu.