Frameworki skalujące zwinne podejście do zarządzania projektami

Scrum zadomowił się już na dobre w polskich organizacjach IT (firmach i działach). Teraz na krzywej hype cycle koncepcji biznesowych wspinają się tzw. frameworki rozszerzające zwinną filozofię na duże przedsiębiorstwa. W jednym z poprzednich wpisów (patrz: Defiliada koncepcji biznesowych) przedstawiłem analizę z 2016 roku koncepcji zarządzania projektami i wówczas Enterprise Agile Frameworks było na samym początku drogi, jeszcze przed dostrzeżeniem przez biznes, w fazie zwanej Innovation Trigger.

Rzut oka na raport State of Agile z 2019 roku (tytułowy wykres kołowy) pokazuje, że na razie jedną trzecią rynku zagarnął SAFe, a po nim Scrum of Scrums. Jednak opcji jest dużo więcej. Przykład rozwoju metodyk zwinnych dowodzi, że po okresie rozkwitu dziesiątków podejść, nastąpiło wymieranie i trzy czwarte rynku zagarnął Scrum z technikami zapożyczonymi z Kanban, XP, czy Lean. Moim zdaniem ten scenariusz powtórzy się również na poziomie enterprise agile. Na placu boju za parę lat pozostaną dwa lub trzy frameworki, przy czym pierwsze z nich zgarnie zdecydowaną większość rynku… Albo cała idea skalowanego agile’a ustąpi miejsca kolejnemu pomysłowi na organizację pracy dużych zespołów.

Poniżej widać diagram z Google Trends dotyczący zapytań o 'Enterprise Agile Framework’ od roku 2004 do dzisiaj. Jak widać nieznaczny trend wzrostowy wystąpił w 2016 roku i od tego momentu zainteresowanie tym hasłem utrzymuje się na stałym poziomie.

Wiele dużych korporacji sięga po różne modele skalowalnego agile. Powodów zainteresowanie może być wiele: chwilowa moda, chęć pochwalenia się przed kolegami z zarządów innych korporacji, naciski ze strony pionu HR, bo chwilowa moda lub chęć pochwalenia się przed kolegami z pionów HR innych korporacji, albo bardziej merytorycznie potrzeba pokazania kandydatom do pracy, że mimo swojej skali organizacja ma przyjazną kulturę organizacyjną lub wreszcie rzeczywiste pragnienie podniesienia efektywności organizacji, w sytuacji, gdy inne, bardziej tradycyjne podejścia nie przyniosły wystarczających owoców. Nie znam raportu Gartnera z 2019 roku (nie jest dostępny za darmo), ale według raportu z 2016 roku faktycznie ta koncepcja była na początku swojej drogi.

Metodyki zwinne świetnie sprawdzają się w niewielkich zespołach. Moim zdaniem oprócz rozmiaru takie zespoły powinny mieć jeszcze kilka cech:

brak czynników nastawiających negatywnie do pracy, jak frustracja, niechęć do kolegów lub firmy, brak pieniędzy na podstawowe potrzeby,
brak konfliktów na bazie rywalizacji o lepsze zadania, pensję, wdzięki współpracowników,
brak próżniactwa społecznego w zespole, czyli „wożenia się” na pracy wykonywanej przez innych,
conajmniej przeciętne kompetencje w obszarze merotyrycznym projektu, np. w danej technologii. Moim skromnym zdaniem, jeżeli cały zespół jest na poziomie „nie wiem, że nie wiem”, albo innymi słowy na początkowym wzniesieniu wykresu Krugera-Dunninga.
wstawienie zespołu pod klosz Scruma, w którym mogą mieć poczucie autonomii.

Jak to się ma natomiast do dużych, macierzowych organizacji. Można tu znaleźć szereg czynników ograniczających stosowalność filozofii zwinnej:

budżetowanie – na ogół w cyklu rocznym planuje się i rozlicza budżety działów, świat projektów jednak nie rządzi się taką kalendarzową dynamiką.
hierarchia dowodzenia – kadra menadżerska bierze większe pieniądze za to, że jest odpowiedzialna za większy fragment organizacji, to oznacza, że będzie starała się kontrolować działania w podległych obszarach. Szczególnie ważne będą dla niej aspekty organizacji, za które menadżerowie mogą zostać zwolnieni lub dostać większą premię albo awans. Posiadanie władzy i rywalizacja o dostęp do pysznej termitiery, padłego mamuta, stada samic, czy pokoju na dwudziestym piętrze są stałą cechą naszego gatunku.
raportowanie do zagranicznych właścicieli lub na giełdę – na duże firmy nakładane są rozmaite obowiązki kontrolne, które mogą zaburzać autonomię zwinnych zespołów.
wielozadaniowość ludzi – macierzowość struktury organizacyjnej oznacza, że pojedynczy specjalista może przynależeć do wielu zespołów realizujących równolegle odmienne zadania. To z kolei prowadzi do błędnego planowania prac i przeciążenia ludzi.
trudne sytuacje decyzyjne – istnieją sytuacje, których rozwiązywanie wspólnym konsensusem jest najprostszą drogą do wojny domowej. Znajomy opowiadał mi o zwinnym zespole, który stanął przed wyzwaniem podzielenia między siebie premii. Oczywiście pieniędzy było za mało, aby zadowolić wszystkich. Zawsze jest za mało, bo tu włącza się teoria perspektywy. Podwyżka o 10% przestaje cieszyć, gdy ta wredna jędza siedząca biurko obok otrzymała 15%.

Pomocą we wdrażaniu kultury zwinnej starają się być tzw. frameworki. Poniżej krótko jest scharakteryzowałem i dokonałem ich porównania. Najpopularniejsze to SAFe 5.0, Scrum@Scale, Nexus, model Spotify, Large Scale Scrum, DAD 4.

SAFe

Aktualnie najpopularniejszy framework zwinny, ale z pretendentem depczącym mu po piętach (patrz DAD). Obejmuje poziom zespołu, wielu zespołów, portfela, wielu portfeli projektów, w końcu kultury całej organizacji. Zaczyna od definiowania strategii i uzasadnień biznesowych, a następnie przechodzi przez poziom portfela i dochodzi do pojedynczego zespołu.

Na poziomie zespołu SAFe czerpie ze Scrum, wymieniając typowe role, spotkania i cykl życia projektu. Zakłada się, że zespoły zwinne pracujące w swoich obszarach kompetencji mogą łączyć się, aby wspólnie stworzyć funkcjonującą całość, np. zwinny zespół z marketingu może zacieśniać współpracę ze zwinnym zespołem IT.

Z perspektywy zakresu prac na najwyższym poziomie mamy strategię, potem portfolio wspierane przez Kanban, a następnie release’y, które zbierają wykonane funkcjonalności z różnych zespołów. Ciekawie w SAFe ukazana jest perspektywa finansowania strategii. Zakłada się partycypacyjne podejmowanie decyzji o wydatkach, budżetowanie strumieni korzyści, a nie projektów oraz kategoryzowania inwestycji z perspektywy horyzontów zdarzeń.

Typowe techniki to business/lean canvas, epic, agile release trains, design thinking, scrum, kanban i wiele innych.

To króciutkie omówienie może sprawiać wrażenie zbagatelizowania, czym SAFe jest, więc jeszcze raz podkreślę, że jest to rozległy framework wspierający zarządzanie całą organizacją oraz kilkanaście ról i dziesiątki technik. Jednak w przeciwieństwie do DAD, SAFe stara się pełnić rolę metodyki, czyli konkretnych wytycznych działań, które powinny być wykonywane, aby być zgodnym z tym frameworkiem.

Disciplined Agile Delivery

Zbiór wiedzy nazywany DAD adresowany jest przede wszystkim do zespołów produkujących oprogramowanie. Jednak DAD stara się podejść szeroko do tej kwestii. Nie tylko opisuje moment produkowania funkcjonalności, ale również ich projektowanie, utrzymanie, wdrażanie. Stąd twórcy proponują aż 10 ról, 21 procesów zarządzania projektami oraz inspiruje się całym wachlarzem różnych innych metodyk, 6 cyklów życia projektów, technik. Takim podejście przypomina nieco PMBOK Guide, które nie jest metodyką, a encyklopedią. Z resztą na pierwszy rzut oka DAD wygląda, jak groźna konkurencja tegoż w świecie zwinnych projektów… Zaraz, przecież PMI pozbył się tej konkurencji, wykupując ją w sierpniu zeszłego roku :).

Podsumuję krótko, bo DAD jest naprawdę obszerny i wymaga osobnego artykułu. DAD to encyklopedia dobrych praktyk zwinnych projektów poukładana trochę na wzór PMBOK Guide. Z niej dopiero tworzy się firmową metodykę do różnych celów: zwinnego zarządzania całym przedsiębiorstwem, albo poprowadzenia dużego projektu.

Możemy też spodziewać się, albo równoległego body of knowledge wypuszczonego przez PMI (w formie dodatku do PMBOK o nazwie Agile Practice Guide), albo rozszerzenia PMBOK Guide o framework DAD. Tak, czy siak życzę powodzenia na przyszłych egzaminach PMP!

LESS

Robi wrażenie konkretnej metodyki zarządzania wieloma zespołami. Koncentruje się na produkcji oprogramowania w dużych projektach. Podstawową jednostką organizacyjną jest zespół Scrumowy, zakres jest dekomponowany na sprinty z użyciem backlogu itp. To, co pojawia się ponad Scrum, to:

Planowanie zakresu prac najpierw na poziomie wielu zespołów, a potem dopiero przydzielanie do konkretnego. Mamy też dwie role: product owner i area product owner.
Product backlog refinement odbywa się również dwupoziomowo, dla wszystkich zespołów razem, a potem każdy indywidualnie.
Analogiczna sytuacja dwupoziomowego działania ma miejsce przy retrospective.
W przypadku sprint review sugeruje się dokonywanie tego przez wszystkie zespoły razem ale z użyciem tzw. bazaru. Przypomina to Obeya, postery na konferencji naukowej, albo metodę wernisażową. Klient ma zaprezentowane oddawane funkcjonalności i sam kieruje się tam, gdzie są rzeczy, które go interesują.

Na to została nałożona filozofia myślenia w stylu Lean, w której z konkretów wymienia się: kaizen, 5why, WIP, VA/NVA, rodzaje strat, czas cyklu i wizualizację w zarządzaniu, karty A3. Rola kadry menadżerskiej została zredukowana do komunikacji z właścicielem produktu i zapewniania finansowania, a także usuwania przeszkód administracyjnych. Metodyka LESS adoptuje szereg technik inżynierii oprogramowania, jak TDD, RAD, automatyzację testów.

Scrum of Scrums

Podobną do LESS filozofię skalowania Scruma przyjmuje SOS, czyli Scrum of Scrums. Duży zespół dekomponuje się na mniejsze 5-10 osobowe, różnica polega na tym, że każdy taki mały zespół wybiera przedstawiciela, który komunikuje się i współpracuje na wyższym poziomie. Backlog ma dwa poziomy, codzienne spotkania są dwupoziomowe, product owner ma dwa poziomy.

Z nowych rzeczy sugeruje się utworzenie Enterprise Action Team, czyli zespołu składającego się z kluczowych menadżerów w organizacji, z Chief Product Ownerem w składzie. Ta formuła może okazać się znajoma dla członków zarządów, którzy dotychczas zasiadali w komitetach sterujących projektów.

Scrum at Scale

Kolejny framework i kolejne dwupoziomowe klonowanie Scruma. Obie koncepcje, SoS i S@S używają nawet podobnych terminów: chief product owner, scrum of scrums, EAT. Z nowości jest tutaj nawet Chief Scrum of Scrums Master w skrócie SOSM oraz Executive Meta Scrum Team, taki grupowy product owner na poziomie całej firmy. Koncepcja S@S zakłada fraktalność organizacji, więc jak mamy Scrum of Scrums (SoS), to za chwilę możemy mieć SoSoS, czyli trzy poziomową skalowalność scruma. Z resztą załączam fraktalną strukturę organizacyjną z dokumentacji tej metodyki.

Model Spotify

To właściwie nie tyle jest model zwinnego prowadzenia prac (tu rozległy artykuł na ten temat), co ogólne wytyczne dotyczące kultury organizacyjnej i sposobu formowania zespołów. Same praktyki zwinne w modelu Spotify pozostawione są poszczególnym zespołom. Spotify podkreśla, że właśnie częścią zwinnej kultury jest pozostawienie swobody zespołom, co do sposobu organizacji pracy. A to oznacza, ograniczoną egzystencje standardów.

Techniki, które Spotify promuje to: daily standup, retrospective, fail board, wspólnoty praktyków zwane tu gildiami, małe, autonomiczne zespoły, rola właściciela produktu, dekompozycja strategii na mniejsze, bardziej operacyjne części, które są zarządzane przez owe zespoły.

Plusem Spotify jest to, że skupia się nie tylko na produkcji nowych funkcji i usług przez zespoły IT, ale stara się zapewnić bazę do strategicznego zarządzania firmą. Z mojej perspektywy słabością jest zaś to, że ze względu na niewielką ilość konkretnych reguł, ról, praktyk i technik, nie jest metodyką. To oznacza, że musi polegać na zapale, konsekwencji i osobowości zarządu korporacji. Gdy tego zabraknie, cała układanka może się szybko rozsypać.

Podsumowanie

Cechą wspólną wszystkich wymienionych frameworków jest:

Silne skupienie się na daniu ludziom autonomii, co jest zgodne z Agile Manifesto, na które się powołują.
Przyjęcie, że najmniejszą jednostką organizacyjną jest zespół zwinny, zwykle Scrumowy.
W związku z poprzednim punktem pojawienie się typowo scrumowych ról.
Conajmniej dwupoziomowa dekompozycja zakresu prac: poziom Scrum of Scrums i poziom podstawowy Scruma.
Użycie backlogu jako podstawowego narzędzie planowania zakresu.

W mojej osobistej opinii rywalizację wygrają najbardziej rozbudowane frameworki, które skutecznie przekonają zarządy dużych firm, czyli SAFe i DAD. Pozostałe mogą się rozwodnić w krajobrazie różnych mutacji Scruma. Bo, gdy przychodzi do uzwinnienia całej firmy, już nie da się działać lokalnie, trzeba przekonać prezesa.

bizlog