Pięć fundamentalnych różnic między POM a LeSS. Każdy wybór ma cenę - coś przyjdzie Ci z łatwością, coś będzie bolało. Lepiej mocno przemyśl pod co optymalizujesz swoją organizację, zanim zamienisz transformację na rozczarowanie.
W pierwszej części pisałem, że LeSS i Model Produktowy nie konkurują ze sobą. Mają wspólny mindset produktowy. LeSS daje grunt - strukturę organizacyjną umożliwiającą pracę produktową. POM współdzieli ten mindset i daje wiele ważnych koncepcji i praktyk produktowych.
Ale byłbym nieuczciwy, gdybym zostawił Cię z wrażeniem, że wystarczy wymieszać obydwa i gotowe :)
W kilku miejscach te modele mówią rzeczy wprost sprzeczne. Nie w mało znaczących detalach, ale w fundamentach na których będzie stał twój model operacyjny. I jeśli tego nie zobaczysz przed transformacją, zobaczysz to w jej trakcie jako szereg praktyk, które na slajdach wyglądały spójnie, a w praktyce rozjadą się w pierwszym kwartale.
Jeden wybór, z którego wynika wszystko
Wszystkie różnice między POM a LeSS sprowadzają się do jednego pytania:
Pod co optymalizujesz: pod adaptacyjność całości, czy pod głębię własności?
LeSS optymalizuje pod adaptacyjność całego produktu - definiowanego szeroko i klientocentrycznie. Cała konstrukcja - jeden Product Backlog, jeden PO (strateg i decydent), feature teams, wspólny Sprint - służy jednemu: żeby grupa zespołów mogła w każdej chwili rzucić najwięcej mocy na to, co aktualnie najważniejsze. Mówiąc inaczej, zespoły mają mieć niski koszt zmiany kierunku i silnie współpracować, aby osiągać maksymalną możliwą wartość dla całości produktu. Idealny stan: każdy zespół może wziąć dowolny element z góry backlogu. Gdy zmienia się rynek i zmienia się priorytet, to organizacja skręca bezkosztowo (najdalej w jeden Sprint) na to co stało się najważniejsze, bez reorganizacji.
POM optymalizuje pod głębię własności. Cała konstrukcja - PM w każdym zespole, przydzielone problemy, zespołowe cele, ciągłe discovery w trio - służy czemu innemu: żeby zespół znał swój problem lepiej niż ktokolwiek inny w firmie. Tygodnie rozmów z klientami, testowanych hipotez i danych budują kontekst, którego nie da się przekazać w dokumencie. Idealny stan: zespół, któremu można powierzyć problem i metrykę, i który sam znajdzie najlepsze rozwiązanie dla klienta i dla biznesu.
Oba cele są sensowne. Problem w tym, że nie da się zmaksymalizować obu naraz, bo mechanizmy jednego podkopują mechanizmy drugiego. Głęboki kontekst buduje się przez trzymanie zespołu przy problemie - a to dokładnie to, co zabija zdolność przerzucania mocy (rośnie koszt zmiany kierunku). Adaptacyjność wymaga wspólnego rozumienia całego produktu - a to dokładnie to, co rozmywa poczucie "mojego problemu" w POM.
To nie jest wybór stylu. To wybór, z którego wynika reszta architektury.
Pięć różnic, które nie są kosmetyczne
1. Kto trzyma kierunek produktu
W LeSS kierunek produktu należy do jednego Product Ownera z pełną decyzyjnością nad treścią i kolejnością backlogu. PO w LeSS to strateg, którego zadaniem jest wskazać którymi problemami mają zająć się zespoły. Leadership organizacji dostarcza kontekst biznesowy - cele firmy, decyzje inwestycyjne - ale nie steruje produktem. W POM strategia produktowa to wprost praca product leadership: CPO i liderzy (Head of Design, Head of Product Management etc.) budują ją z insightów, a PM-owie działają w jej ramach.
Konsekwencja: inne miejsce mówienia "nie". W LeSS "nie" mówi jedna osoba. W POM "nie" mówi warstwa liderska. Jeśli w Twojej transformacji nie rozstrzygniesz, gdzie mieszka to "nie", będzie mieszkać wszędzie - czyli nigdzie. Wówczas rozjadą ci się priorytety, bo "ważne zadania" będą wpadać bokiem.
2. Skąd zespół bierze pracę
W POM zespół dostaje problem i trzyma go - typowo przez kwartał, czasem dłużej. W LeSS zespół bierze elementy z góry wspólnego backlogu - a to które weźmie w danym Sprincie, wynika ze wspólnych priorytetów, nie z przydziału.
Konsekwencja: to jest wprost suwak między głębią a elastycznością. Zespół trzymający problem przez kwartał (albo i kilka) zna go fenomenalnie. Jednak staje się wąskim gardłem, gdy najważniejsza praca do realizacji jest gdzie indziej. Zespół biorący cokolwiek z góry backlogu jest elastyczny. Jednak przez pierwsze miesiące płytszy w każdej domenie, bo multi-learning to inwestycja liczona w latach, nie sprintach.
3. Gdzie powstają rozwiązania
W POM właścicielem odkrycia i wyboru rozwiązania jest trio - PM, designer i inżynierowie zespołu, który dostał problem. W LeSS ideacja jest wspólna: dzieje się na (Multi-Team) Product Backlog Refinemencie, z udziałem klientów i wielu zespołów naraz, a zespół (lub zespoły), który weźmie element, domyka projektowanie w Sprincie.
To nie jest różnica rytuału. W LeSS rozwiązania nie mogą być własnością jednego zespołu, bo skoro więcej niż jeden zespół miałby móc podjąć najpilniejszą pracę, rozumienie musi być wspólne. W POM wspólna ideacja nie jest potrzebna, bo element (problem) nie zmieni właściciela. Mechanizm wynika z celu optymalizacji - i dlatego nie da się go podmienić w oderwaniu od reszty.
4. Czym w ogóle jest autonomia zespołu
Tu jest pułapka, w którą wpada prawie każdy, bo oba modele mówią "autonomiczne zespoły" - a znaczą co innego.
POM uwalnia metodę, a wiąże kierunek i craft: zespół sam decyduje, czy pracuje w Sprintach, czy Kanbanem, czy uprawiają "Cowboy Coding" ;-) - Cagan konsekwentnie powtarza, że model nie jest o procesie delivery - ale problem przychodzi od leadershipu, a standardy dyscypliny od menedżerów funkcyjnych. LeSS wiąże kadencję, a uwalnia wnętrze: wspólny Sprint i wydarzenia są narzucone jako mechanizm integracji produktu, współpracy i współuczenia się, ale wewnątrz tej ramy zespół(y) decyduje o organizacji pracy, praktykach i koordynacji.
Konsekwencja: gdy na warsztacie ktoś powie "przecież oba modele dają zespołom autonomię, więc nie ma o czym rozmawiać" - to wiedz, że jest o czym. Pytanie brzmi: autonomię w którym wymiarze oddajemy zespołom, a który wymiar świadomie wiążemy dla dobra całości.
5. Jak rośnie craft
Najbardziej zapalna różnica, bo dotyka linii raportowania - czyli tożsamości i władzy.
POM mówi wprost: designerzy raportują do szefa designu, PM-owie do szefa produktu, inżynierowie do menedżerów inżynierii. Argument Cagana jest mocny: coaching to obowiązek numer jeden menedżera, a craft może rozwijać tylko ktoś, kto sam go opanował. LeSS mówi coś przeciwnego: co najwyżej jeden wspólny menedżer na zespół, a craft rozwijany przez Communities of Practice, gildie, mentoring i rotacje. LeSS nie chce zrobić ze świetnego eksperta, menedżera od coachingu. Woli zostawić eksperta przy pracy i zastosować inne mechanizmy rozwoju kompetencji. Argument też jest mocny: ocena i awans w silosie funkcyjnym kierują lojalność ludzi do funkcji, nie do produktu - struktura generuje zachowanie, niezależnie od dobrych intencji.
Obie strony adresują prawdziwy problem. Craft bez opieki więdnie. Linie funkcyjne odtwarzają silosy. Spór jest o mechanizm, nie o wagę - ale mechanizm trzeba wybrać, bo nie da się raportować do dwóch struktur "po połowie".
Dlaczego "weźmiemy z każdego to, co najlepsze" zwykle nie działa
Bo różnice z tej listy są sprzężone. Pokażę na przykładzie hybrydy, którą widuję najczęściej:
Firma bierze z LeSS jeden Product Backlog (brzmi porządnie), z POM bety trzymane przez zespoły na kwartał (brzmi odpowiedzialnie), i rezygnuje ze wspólnej ideacji, bo "każdy zespół ma swój temat, po co wszyscy mają siedzieć na refinemencie".
Na papierze spójne. W praktyce: backlog jest jeden, ale nikt poza "właścicielem" nie rozumie elementów, więc nikt inny nie może ich wziąć - adaptacyjność, dla której wzięto jeden backlog, nie istnieje. Zespoły czując się odpowiedzialne za swój problem, nie są chętne pomagać innym. Bety są kwartalne, ale PO może repriorytetyzować w każdej chwili - więc albo nie repriorytetyzuje (i po co mu backlog), albo repriorytetyzuje i łamie kwartalną obietnicę zespołom. Każdy element układanki pochodzi z sensownego modelu. Całość nie optymalizuje pod nic i rodzi frustrację.
Struktura generuje zachowanie. Niespójna struktura generuje niespójne zachowanie - a rachunek płacą zespoły, które dostają sprzeczne sygnały i przestają wierzyć w transformację.
Dlatego kolejność jest taka: najpierw decyzja o celu optymalizacji, potem wybór mechanizmów spójnych z tym celem. Nie odwrotnie.
Decyzja zero: pod co optymalizujesz
Zanim narysujesz pierwszy krok zmiany, odpowiedz na trzy pytania:
Jak zmienne są Twoje priorytety? Jeśli rynek, regulacje albo strategia potrafią wywrócić kolejność ważności w miesiąc - adaptacyjność jest warta swojej ceny. Jeśli problemy są stabilne i znane na lata, oraz nie ma częstych spiętrzeń pracy, głębia kontekstu procentuje bardziej.
Czy budujesz jeden spójny produkt, czy portfolio? Im bardziej doświadczenie klienta przecina granice zespołów, tym bardziej boli lokalna optymalizacja - i tym więcej zyskujesz na całościowej priorytetyzacji.
A potem, cokolwiek wybierzesz, wybierz też świadomie cenę. Bo każda z tych dróg ma rzeczy, które przyjdą Ci łatwo, i rzeczy, które będą bolały.
Jeśli optymalizujesz pod adaptacyjność (bliżej LeSS)
Z łatwością przyjdzie: globalna priorytetyzacja - jedna wspólna lista kończy wojny o zasoby i lokalne cele. Spójność produktu, bo wszyscy patrzą na całość. Przerzucanie mocy na najważniejszy temat bez reorganizacji. Prostsza struktura - mniej ról do obsadzenia, utrzymania i synchronizowania.
Utrudnieniem będzie: budowa głębokiego kontekstu w każdym zespole - multi-learning wymaga ciągłej inwestycji, a przez pierwsze kwartały zespoły będą wolniejsze w domenach, których się uczą, i musisz to wytrzymać. Discovery jako nawyk - LeSS milczy o praktykach produktowych, więc musisz je doszczepić z POM, inaczej dostaniesz sprawną machinę dowożącą ficzery, których nikt nie zweryfikował. Rynek pracy i kariery - "nie mamy PM-ów w zespołach" brzmi egzotycznie dla kandydatów i przeraża obecnych PM-ów, którym musisz uczciwie pokazać, kim będą w nowym układzie. I opór menedżerów funkcyjnych, bo likwidacja linii per dyscyplina to dla nich nie zmiana procesu, tylko zmiana tożsamości - pierwsze prawo Larmana zadziała na Tobie, nie obok Ciebie.
Jeśli optymalizujesz pod głębię własności (bliżej POM)
Z łatwością przyjdzie: jasna odpowiedzialność - każdy problem ma gospodarza z imieniem i nazwiskiem. Rekrutacja i ścieżki kariery, bo rynek zna i wycenia rolę PM-a. Głęboki kontekst domenowy i nawyki discovery, które mają naturalnego właściciela w trio. Szybkie lokalne decyzje bez czekania na kogokolwiek.
Utrudnieniem będzie: wszystko, co opisałem w części pierwszej jako problemy 1-3, tylko teraz na Twoim podwórku. Coordination tax rosnący z każdym kolejnym zespołem. Spójność całości, o którą musisz walczyć spotkaniami, bo struktura sama jej nie wytwarza. Repriorytetyzacja między zespołami - zabranie zespołowi "jego" problemu w połowie kwartału to małe trzęsienie ziemi, więc będziesz to robił rzadziej, niż wymaga tego rynek. I cele zespołowe, które przy każdej nieostrożności zamieniają się w piętnaście lokalnych backlogów, lokalnych optymalizacji nie sumujących się do globalnej wartości. Zespoły mogą popaść w tzw. gold-plating w nieskończoność udoskonalając rozwiązanie i adresując pochodne problemy.
Wartości są wspólne. Spór jest o mechanizmy
Na koniec rzecz, która obniża temperaturę każdej dyskusji o "POM vs LeSS", jaką prowadzę z zespołami liderskimi.
Oba modele chcą tego samego: zespołów, które dostają kontekst zamiast listy zadań, rozmawiają z klientami bez pośredników, są rozliczane z outcome'u, a nie outputu, i mają wokół siebie organizację, która rozwija ludzi zamiast nimi dyrygować. W warstwie wartości spór praktycznie nie istnieje.
Spór jest o mechanizmy: kto trzyma kierunek, skąd zespół bierze pracę, gdzie powstają rozwiązania, który wymiar autonomii wiążemy, jak rośnie craft. A mechanizmy wybiera się pod cel optymalizacji - świadomie, spójnie i z otwartymi oczami na cenę.
Transformacja nie wywraca się na tym, że wybrałeś "zły model". Wywraca się na tym, że nie wybrałeś żadnego celu - i poskładałeś mechanizmy, które ciągną organizację w dwie strony naraz.
Gwiazda musi wskazywać jeden kierunek
Na koniec zostawiam ramę, która spina wszystko, co napisałem powyżej.
To Star Model Jaya Galbraitha - klasyczna rama projektowania organizacji, używana od lat siedemdziesiątych. Galbraith mówi, że organizacja stoi na pięciu punktach gwiazdy:
strategia - co chcemy osiągnąć i czym się wyróżnić,
struktura - jak dzielimy ludzi na jednostki i kto o czym decyduje,
procesy - jak płynie informacja i jak zapadają decyzje między jednostkami,
nagrody - za co ludzie są oceniani, awansowani i wynagradzani,
ludzie - jakie kompetencje mamy i jak je rozwijamy.
I jedno twierdzenie, od którego wszystko zależy: te pięć punktów musi ciągnąć w tę samą stronę. Craig Larman dokłada do tego pytanie, którym otwierałem ten tekst: pod co ta gwiazda ma być ustawiona / pod co optymalizujesz? Bez odpowiedzi na nie nie da się ocenić, czy punkty są spójne - bo nie wiadomo, z czym mają być spójne.
Teraz spójrz jeszcze raz na pięć różnic z tego artykułu. To nie jest przypadkowa lista - to punkty gwiazdy. Kto trzyma kierunek i skąd zespół bierze pracę to struktura. Gdzie powstają rozwiązania i który wymiar autonomii wiążemy to procesy. Cele i metryki, z których rozliczasz zespoły, to nagrody. Mechanizm rozwoju craftu to ludzie. A cel optymalizacji - adaptacyjność albo głębia własności - to strategia, pod którą całą gwiazdę ustawiasz.
Jeśli cztery punkty są ustawione pod jeden cel, a piąty pod inny, organizacja zachowuje się tak, jak nakazuje ten piąty. Weźmiesz z LeSS strukturę i procesy, ale zostawisz nagrody per zespół i funkcyjne linie raportowania? Ludzie będą optymalizować lokalnie - dokładnie tak, jak wymusza na nich gwiazda, a nie tak, jak pokazywały slajdy z pięknymi ideami transformacji.
Zmiana jednego punktu bez pozostałych daje rozczarowanie, a nie transformację.
Chcesz wiedzieć więcej? Z przyjemnością porozmawiam.