Kiedy Ken Schwaber i Jeff Sutherland tworzyli Scrum, trudno było im przewidzieć, że dwadzieścia lat później będą musieli ratować swoje dziecko przed zniekształceniem. Kult cargo w Agile, mechaniczne “ceremonie” i „transformacje”, które zmieniają nazwy ról, ale zostawiają nietknięte struktury organizacyjne – to codzienność polskich korporacji. Dlatego Scrum.org postanowił zabrać głos w sposób, którego nikt się nie spodziewał. Zamiast kolejnego frameworku wprowadzili Agile Product Operating Model (APOM) – holistyczne podejście, które wreszcie nazywa rzeczy po imieniu.
To nie jest ewolucja Scrum. To rewolucja w myśleniu o tym, jak organizacje powinny funkcjonować w XXI wieku. Model ten powstał z frustracji praktyków obserwujących setki „zwinnych” transformacji, które kończyły się Scrumem w nazwie, ale waterfallem w praktyce. Scrum.org w końcu zdecydował się odpowiedzieć na fundamentalne pytanie: dlaczego większość wdrożeń Agile kończy się porażką, mimo że framework działa doskonale w małych zespołach?
Anatomia porażki: dlaczego projekty zabijają zwinność
Aby zrozumieć genialność Agile Product Operating Model, trzeba najpierw przeprowadzić analizę przyczyn porażki tradycyjnego modelu projektowego. Problem nie leży w konkretnych narzędziach czy procesach – tkwi w fundamentalnych założeniach o naturze pracy w organizacji.
Projekty z definicji są tymczasowe. Mają określony początek, koniec i zakres. Ta tymczasowość wydaje się logiczna – w końcu każda praca kiedyś się kończy. Problem w tym, że w świecie produktów cyfrowych „koniec” nie istnieje. iPhone nie został „ukończony” w 2007 roku. Netflix nie „zakończył” swojej platformy streamingowej. Te produkty ewoluują, dopóki istnieje potrzeba klientów.
Tymczasem organizacje produktowe nadal organizują pracę w projekty, tworząc fundamentalną sprzeczność. Zespoły są formowane na czas realizacji projektu, potem rozwiązywane i przekierowywane do innych zadań. Wiedza gromadzona przez miesiące ulatuje wraz z końcem projektu. Właściciel produktu, który przez rok uczył się specyfiki domeny, zostaje przeniesiony do „nowego wyzwania”. To jak budowanie domu przez zespół architektów, którzy po położeniu fundamentów zostają zastąpieni zupełnie nową ekipą.
Porównanie programów kosmicznych Boeinga i SpaceX, którego dokonują autorzy modelu APOM, to dobitna lekcja różnic między myśleniem projektowym a produktowym. Boeing, otrzymując większe finansowanie na program CST-100 Starliner, podszedł do zadania klasycznie projektowo – złożona sieć podwykonawców, hierarchiczne zarządzanie, płatności za kamienie milowe. SpaceX podszedł produktowo – zintegrowane zespoły z holistyczną odpowiedzialnością za całość. Rezultat? SpaceX dostarczył działającą kapsułę, podczas gdy Starliner wciąż walczy z problemami integracji.
Trzy filary transformacji – dlaczego połowiczne podejścia zawodzą
Agile Product Operating Model identyfikuje trzy filary, które muszą zostać wdrożone jednocześnie. To nie jest menu opcjonalne – to system naczyń połączonych, gdzie próba implementacji tylko jednego czy dwóch elementów tworzy źródło problemów gwarantujące porażkę.
Pierwszy filar to Product Mindset – kognitywna zmiana w podejściu do pracy. Oznacza to patrzenie na każdy problem holistycznie: kim są interesariusze, jakie rezultaty chcemy osiągnąć, jakie są zależności, kto ponosi odpowiedzialność i – najważniejsze – jaka wartość zostanie dostarczona. To przejście od myślenia zadaniowego („zrób to, co jest w tickecie”) do myślenia kontekstowego („rozwiąż problem klienta”).
Drugi filar to Strategic Alignment – strukturalna reorganizacja wokół produktów zamiast funkcji. W większości polskich organizacji zespoły są budowane wokół aplikacji, technologii lub umiejętności. Model APOM wymaga przejścia do struktur skupiających się na konkretnych produktach lub strumieniach wartości. To oznacza interdyscyplinarne zespoły, które mają wszystko, czego potrzebują, by dostarczyć wartość od początku do końca.
Trzeci filar to Value-driven Investment – finansowa transformacja od opłacania projektów do inwestowania w produkty. Zamiast budżetów na „pracę” organizacja finansuje stabilne zespoły przypisane do produktów. To oznacza dłuższe cykle inwestycyjne dla produktów, ale znacznie krótsze cykle inspekcji i adaptacji na poziomie produktu i portfela.
Craig Larman w swoich prawach dotyczących zachowań organizacji trafnie opisuje, co dzieje się, gdy próbujemy zmienić tylko część systemu. Organizacje będą próbować zachować status quo, używając nowych nazw dla starych praktyk. To właśnie dlatego widzimy „właścicieli produktu”, którzy w rzeczywistości są analitykami biznesowymi bez uprawnień decyzyjnych, czy „zespoły scrumowe”, które nadal muszą prosić o pozwolenie na każdą zmianę w kodzie.
Architektura modelu – cztery komponenty zintegrowanego systemu
Agile Product Operating Model składa się z czterech komponentów, które razem tworzą kompletny system organizacji produktowej. Każdy komponent ma jasno określoną rolę, ale ich prawdziwa siła ujawnia się w integracji.
Strategy (Dlaczego) definiuje kierunek poprzez cztery zintegrowane perspektywy. Perspektywa wartości określa ekonomiczną propozycję produktu – musi on dostarczać więcej wartości, niż kosztuje jego budowa i utrzymanie. Perspektywa biznesowa adresuje możliwości rynkowe i zmiany w krajobrazie konkurencyjnym. Perspektywa technologiczna zapewnia zespołom stabilny widok na krajobraz technologiczny. Perspektywa operacyjna definiuje poziomy usług i wsparcia, jakich mogą oczekiwać interesariusze.
People (Kto) koncentruje się na budowaniu ekosystemu, w którym interdyscyplinarne zespoły mogą prosperować. To nie tylko skład zespołów, ale też styl przywództwa służebnego (servant leadership), rozwój talentów, kultura organizacyjna i system motywacji. W końcu, jak zauważają autorzy APOM, złożona praca to praca oparta na wiedzy (knowledge work), a tworzenie środowiska, gdzie utalentowani ludzie mogą się realizować, to podstawa sukcesu.
Structure (Zasady i narzędzia) zapewnia ramy umożliwiające zwinne działanie. To governance i compliance, procesy, systemy technologiczne i – co kluczowe – kontrakty przyjazne dla podejścia produktowego. To ostatnie jest szczególnie istotne w polskim kontekście, gdzie większość dużych organizacji polega na podwykonawcach.
Value Cycle (Praktyki) to miejsce, gdzie strategiczne intencje przekształcają się w rzeczywistą wartość dla klientów. Chociaż tradycyjnie są one rozdzielone na osobne działy czy fazy, model traktuje te aktywności jako płynną i zintegrowaną całość: Discovery (ciągłe odkrywanie i precyzowanie kierunku produktu), Delivery (budowanie i dostarczanie przyrostów produktu) oraz Operations (zapewnienie, że produkt działa efektywnie).
Evidence-Based Management – empiryczny system nerwowy organizacji
Prawdziwą siłą modelu APOM jest jego zakotwiczenie w Evidence-Based Management – frameworku, który przekształca abstrakcyjne pojęcia w konkretne, mierzalne cele. To nie jest opcjonalny dodatek czy framework raportowania. To empiryczny system nerwowy całej organizacji produktowej.
EBM operuje na czterech Kluczowych Obszarach Wartości, które zapewniają holistyczne spojrzenie na sukces. Current Value mierzy wartość obecnie dostarczaną klientom. Unrealized Value ocenia dodatkową potencjalną wartość, która mogłaby zostać osiągnięta. Time to Market mierzy, jak długo trwa dostarczenie nowej wartości. Ability to Innovate ocenia, jak efektywnie organizacja poprawia swoją zdolność do dostarczania wartości.
Genialność EBM polega na mapowaniu tych obszarów na konkretne odpowiedzialności ról w Scrumie. Product Owner staje się odpowiedzialny za Market Value – interakcję między Current Value i Unrealized Value. Scrum Master odpowiada za Organizational Capability – poprawę Time to Market i Ability to Innovate. To podnosi te role z poziomu administratorów procesów do strategicznych liderów z jasnymi, mierzalnymi domenami odpowiedzialności.
Skalowanie do poziomu przedsiębiorstwa
Model APOM nie ogranicza się do pojedynczych zespołów produktowych. Jego prawdziwa transformacyjna siła ujawnia się, gdy zostaje przeskalowany na poziom przedsiębiorstwa poprzez Agile Product Portfolio Management i Continuous Change Management.
Agile Product Portfolio Management to praktyczna implementacja filaru „Investment” na poziomie korporacyjnym. Zamiast finansowania projektów organizacja zarządza portfelem produktów, przydzielając im ciągłe finansowanie na podstawie strategicznej wartości i dojrzałości. To wymaga fundamentalnej zmiany w sposobie myślenia o budżetowaniu – od rocznych planów wydatków do dynamicznego alokowania zasobów w oparciu o dowody efektywności.
Continuous Change Management wprowadza „meta-zwinność” – organizacja staje się zwinna nie tylko w wykonywaniu pracy, ale też w ewolucji własnej struktury i procesów. Model operacyjny sam w sobie jest traktowany jak produkt organizacji – ma interesariuszy (pracowników, liderów), dostarcza wartość (efektywne środowisko pracy) i musi być ciągle doskonalony na podstawie dowodów.
Dlaczego to przemiana, nie ewolucja
W tym roku obserwowałem dziesiątki polskich organizacji walczących z „transformacją Agile”, która nie przynosi oczekiwanych rezultatów. Zespoły pracują w Sprintach, Product Ownerzy priorytetyzują backlog, Scrum Masterzy facylitują wydarzenia scrumowe – a mimo to nic nie przyspiesza. Czas od pomysłu do wdrożenia nadal liczy się w miesiącach. Decyzje utykają w strukturach hierarchicznych, a klienci czekają na funkcjonalności, które konkurencja dostarcza w tygodnie.
Agile Product Operating Model ze Scrum.org wreszcie nazywa problem po imieniu: nie da się wprowadzić zwinności, nie zmieniając fundamentów organizacji. To nie jest kwestia lepszych procesów czy bardziej doświadczonych Scrum Masterów. To kwestia przebudowy organizacji z maszyny przemysłowej XIX wieku w organizm uczący się XXI wieku.
Ten model to odpowiedź na pierwsze prawo Larmana: „Organizacje są domyślnie zaprojektowane tak, by opierać się zmianom”. Zamiast walczyć z tym oporem, APOM proponuje tak fundamentalną przebudowę, że stary system po prostu przestaje istnieć.
Czy Twoja organizacja jest gotowa na taką przemianę? A może nadal wierzy, że można mieć zwinność bez zmiany struktury władzy, bez reorganizacji wokół produktów, bez porzucenia myślenia projektowego? Jeśli tak, to być może warto zacząć od szczerych rozmów o tym, czy rzeczywiście chcecie być zwinni, czy tylko tak się nazywać.
Podczas szkoleń Professional Scrum Product Owner coraz częściej słyszę pytania o to, jak przekonać zarząd do strukturalnych zmian. Agile Product Operating Model daje wreszcie ramy postępowania i język biznesowy do prowadzenia takich rozmów. Bo prawdziwa transformacja zaczyna się nie od zespołów, ale od zarządu, który ma odwagę przyznać, że dotychczasowy model organizacji jest przestarzały.
Więcej informacji w artykule The Agile Product Operating Model (APOM) — an Evidence-Based Approach na scrum.org
