Prezentacja z PMI Connect, 22.05.2019.
Artykuł ten jest podsumowaniem spotkania PMI Connect z 22.05.2019 „Skalowalny Agile & Budżetowanie Leanowe by SAFe”, które prowadziliśmy z Andrzejem Gajewskim z ProPM. Zebraliśmy w nim:
- prezentację okraszoną komentarzem,
- dodatkowe wyjaśnienia zagadnień sygnalizowanych przez uczestników,
- podsumowanie części warsztatowo-networkingowej.
Zapraszam do przeczytania zarówno te osoby, które były na spotkaniu i chcą je sobie przypomnieć, odświeżyć, podsumować, jak również osoby które na spotkaniu nie były, a chcą zapoznać się z tematyką zwinnego budżetowania.
Część teoretyczna
Spotkanie dotyczyło stricte budżetowania zwinnego w formie, jaką proponuje SAFe. Ciężko jednak mówić o tak konkretnym aspekcie zwinnego zarządzania rozwojem produktów nie wiedząc, przynajmniej pobieżnie, czym jest SAFe i czym w ogóle jest agile w skali. Ważne dla nas było, żeby uczestnicy spotkania znali podstawy i kontekst opisanego przez nas mechanizmu. Czasu przeznaczonego na tą część było bardzo, bardzo mało, 20 minut, a finalnie skończyło się na mniej, więcej 30 minutach, bo mam duży problem ze zwięzłym mówieniem, a ponadto starałem się w miarę możliwości i zasadności odpowiadać na bieżąco na zadawane z sali pytania. Prezentacja, którą posłużyłem się na spotkaniu w dużej mierze bazowała na tej, na której oparłem się na Śniadaniu PMów https://project-management.pl/scaled-agile-odczarowany/. Z racji ograniczenia czasowego, musiałem ją nieco skrócić, ale w tym artykule mogę sobie pozwolić na nieco więcej, więc do prezentacji, którą uczestnicy oglądali na PMI Connect dorzuciłem parę dodatkowych slajdów z odpowiednimi komentarzami. Materiał powinien być czytelny niezależnie od tego, czy czytelnik był uczestnikiem spotkania, czy nie. Kto jednak była na Śniadaniu PMów i widział dedykowany temu wydarzeniu artykuł może się nieco nudzić w tej części artykułu. Żeby nie było, że nie ostrzegałem ;]
Instrukcja obsługi – najpierw patrzymy na slajd, a potem na komentarz pod nim ;]
Przygotowując się na to wystąpienie myśleliśmy z Andrzejem od razu o cyklu trzech spotkań poruszających najistotniejsze i najbardziej charakterystyczne według nas aspekty SAFe’a:
- zwinne budżetowanie
- priorytetyzacja prac metodą WSJF (Weighted Shortest Job First)
- PI Planning, czyli planowanie iteracji w skali
Idea spotkań PMI Connect jest taka, żeby dawać na nich jak najwięcej przestrzeni uczestnikom na dzielenie się doświadczeniami i uszanowaliśmy tą formułę. Chcieliśmy jednak dać jakąś ciekawą podstawę do tej dyskusji. Wymyśliliśmy to sobie tak, że za oś dyskusji w podgrupach przyjmiemy podejście SAFe’a do budżetowania proje…. no właśnie nie projektów (ale to tego jeszcze dojdziemy, nie uprzedzajmy faktów) do którego to podejścia uczestnicy będą mogli się odnieść ze swoimi przykładami lub kontrprzykładami. Dodatkowo postanowiliśmy zdekomponować zagadnienie budżetowania w SAFe na pewne jego aspekty, żeby dyskusja była konkretniejsza. Żeby ta podstawa do rozmów w grupach była wartościowa istotne było przybliżenie specyfiki budżetowania w SAFe, no ale żeby z kolei to było zrozumiałe należało osadzić SAFe’a w kontekście kultury lean-agile i jej skalowania. Zrobiło się przez to dość długie wprowadzenie, no ale jak to tak rozmawiać o tak złożonych tematach i tak oryginalnym podejściu nie będąc właściwie uzbrojonym w wiedzę?
Celem spotkania, niezależnie od tego jak udało się nam wprowadzić uczestników w temat i jak dużą jego część skonsumowało, było porównanie SAFe’owej koncepcji budżetowania z praktykami mającymi miejsce w firmach uczestników.
Jako się zatem rzekło zaczęliśmy od przybliżenia koncepcji agile w skali.
Zwinne zespoły potrafią być niesamowicie efektywne. Z takiego założenia wyszli twórcy SAFe’a, których celem jest rozpowszechnienie praktyk lean i agile, w tym Scruma, XPka, Kanbana, czy Scrum-Bana, a nie zastąpienie ich.
Siła zespołów zwinnych polega na tym, że w regularnych, krótkich iteracjach dostarczają podobnej wielkości przyrosty funkcjonalne produktu. Dzięki podejściu empirycznemu, czyli budowaniu swojej wiedzy nie na hipotezach, modelach i wyobrażeniach, tylko na obserwacji efektów prac w naturalnym środowisku, interesariusze na ogół szybciej niż w projektach waterfallowych otrzymują działające rozwiązanie, które realizuje przynajmniej ich podstawowe potrzeby. Następnie, w kolejnych iteracjach, produkt jest usprawniany, zaspokajając bieżące oczekiwania użytkowników i wymagania biznesowe. Dzięki drobnym przyrostom i związanym z tym częstszym wprowadzaniem korekt produkt jest bliższy oczekiwaniom użytkowników. Oczywiście tzw. Waterfall jest przez SAFe nieco demonizowany i nadto upraszczany, ale wiemy o co chodzi i można na to nadużycie z pobłażaniem przymknąć oko. Już w tym miejscu można natomiast zacząć zauważać, że to nie projekty, lecz produkt jest obiektem zainteresowania agile w skali.
Tak to przynajmniej powinno funkcjonować zgodnie z intencjami twórców agile. Brzmi jak sielanka…
…ale wiadomo, że życie różni się od podręczników…
… próby zwinnego zarządzania projektami bywają źródłem frustracji…
… a życie zespołów zwinnych delikatnie mówiąc nie zawsze jest usłane różami.
Przyczyn i objawów może być wiele. Szczególne miejsce wśród nich mają różnice w sposobie myślenia między zespołami zwinnymi, a resztą organizacji.
Zobaczmy zatem jak to zazwyczaj wygląda w rzeczywistości.
Weźmy pod lupę zespół pracujący w Scrumie, który jest zdecydowanie najpowszechniejszym frameworkiem agile’owym. Jego założenia są proste, a zasady łatwe do zrozumienia. Trudności natomiast pojawiają się najczęściej dopiero na etapie implementacji jego mechanizmów. Zwięzłość jest być może największą zaletą Scruma, ale możliwe też, że jego największą wadą. Pozostawia on bowiem sporo miejsca na interpretację i rozwinięcia, nie obejmując wielu ról, procesów i innych mechanizmów wpływających na funkcjonowanie organizacji i mających wpływ na rozwój produktów, a co za tym idzie na pacę zespołów projektowych. To trochę tak, jak w szachach, kilka chwil na poznanie zasad, a następnie lata na zgłębienie strategii lub wypracowanie własnych zagrań.
Zacznijmy od Product Ownera. Jest to osoba, która optymalizuje wartość biznesową rozwiązań dostarczanych przez zespół. Wie jakie są potrzeby użytkowników i jak powinno funkcjonować rozwiązanie. Ma też świadomość tego, jako cele stawia sobie organizacja sponsorująca rozwój produktu. Mało tego, dobrze by było, żeby był Właścicielem Biznesowym rozwiązania, czyli żeby w swojej osobie skupiał kompetencje i odpowiedzialności nie tylko z obszaru projektowania rozwiązania, ale również z zarabiania na nim, jeśli to jest celem, a na najczęściej jest. Zespół scrumowy oczekuje, żeby PO był jego interfejsem do świata interesariuszy. To on podejmuje wszystkie decyzje biznesowe i chroni zespół przed rozpraszającym wpływem konkurujących ze sobą wymagań.
Oznacza to konieczność podejmowania przez Właściciela Produktu bardzo dużej ilość decyzji. Musi posiadać wiedzę na temat strategii produktu i wymagań rynku. Zna profile użytkowników i ich potrzeby, wie jak się zachowują. Podejmuje decyzje na temat tego, jakie cechy powinien posiadać produkt i jakie funkcjonalności powinien realizować. Wie za co i ile chcą zapłacić klienci. Potrafi określić MVP rozwiązania i moment, w którym nadaje się ono do wdrożenia. Najczęściej podejmuje całą masę decyzji odnośnie działania produktu od jego modułów, poprzez funkcjonalności, walidację danych, często do poziomu pojedynczych formularzy, a nawet buttonów i infografik.
Zakres jego odpowiedzialność jest bardzo szeroki, a przy dużych produktach ogromny.
Czy to jest w ogóle realne? Czy PO ma właściwe przełożenia w organizacji? Co z managerami odpowiedzialnymi za całe linie produktowe, co z marketingiem, co z dyrektorami dywizji biznesowych, co z całą masą wszelakich interesariuszy biznesowych? W jakich firmach pozostawia się jednej osobie tak dużą decyzyjność? Kto jest faktycznie WŁAŚCICIELEM produktu? Prezes, Zarząd, Managerowie Produktu? Kto równoważy w swojej roli finansowanie rozwoju z osiąganiem przychodu na sprzedaży rezultatów? Czy są to osoby, które mają możliwość i chęć do współpracy na co dzień z zespołem deweloperskim? A nawet jeśli pełnienie tej roli nie polega na autonomicznym podejmowaniu decyzji, tylko umiejętności wypracowania rozwiązań z innymi reprezentantami biznesu, tudzież po prostu znalezienia odpowiedzi na zaadresowane pytania, to czy taki zakres zadań koncepcyjnych i operacyjnych jest możliwy do realizacji przez jedną osobę?
Jak małe musiałoby być produkowane rozwiązanie, żeby faktycznie realne było wystawienie zespołowi jednego Właściciela Produktu? Czy nie czujemy potrzeby podchodzenia inaczej w przypadku rozwoju pojedynczych aplikacji, a inaczej w przypadku wielkich systemów informatycznych, np. klasy ERP? Zostawię Cię na chwilę z tym pytaniem ;]
Spójrzmy teraz na Scrum Mastera. Jego rola polega na uczeniu organizacji zasad scruma i wprowadzaniu ich w życie.
Kto jednak chce z nim rozmawiać? Na kim faktycznie jest w stanie wywrzeć realny wpływ i zachęcić lub zmusić do stosowania się do agile’owych reguł gry. Czy nie zdarza się tak, że funkcjonuje w totalnie innym świecie wartości i przekonań niż reszta organizacji? Czy to nie jest tak, że zasady scruma są rozumiane i respektowane głównie przez zespoły deweloperskie? Ile osób w organizacji faktycznie chce i potrafi zrozumieć na czym polega zwinność i stosować agileowe mechanizmy? Wciąż jeszcze Scrum i agile traktowane są jak magiczne zabawki IT, więc jakim językiem mają zatem rozmawiać z organizacją Product Owner i Scrum Master?
No i sam zespół deweloperski. Powinien posiadać komplet kompetencji niezbędnych do zamienienia wymagań biznesowych w działający produkt. Powinien mieć też decyzyjność odnośnie technicznych aspektów realizacji rozwiązania. W jakich organizacjach jest to realne?
Jak często udaje się zagwarantować w zespole wszystkie niezbędne kompetencje techniczne? Czy potrafimy zmieścić się w 9 osobach z jego składem? Przy jakich rozwiązaniach realne jest, aby taki zespół autonomicznie tworzył architekturę nie dostając jej szkieletu od osób odpowiedzialnych za architekturę korporacyjną?
A co ze standardami jakości, regułami pracy, systemem rozliczeń. Jak dużą część ogromnych systemów zespół jest w stanie dostrzec ze swojej perspektywy?
Jak duży musiałby być zespół, żeby być w stanie wykonać oprogramowanie zarządzające lotem wahadłowca?
Nie możemy liczyć na to, że takimi samymi mechanizmami będzie się posługiwał 9 osobowy zespół i armia tysiąca ludzi podzielona na dziesiątki zespołów pracujących wspólnie nad jednym rozwiązaniem.
Jak mały musi być tworzony produkt, żeby w pierwszej iteracji (nie większej niż miesięcznej) dostarczyć przynajmniej częściowo używalne rozwiązanie? Co musi się wydarzyć, żeby pierwszy sprint mógł tak wyglądać?
Kto wykona wszystkie te działania, które doprowadzą do uruchomienia projektu? Ile projektów zaczyna się od tego, że zespół Deweloperski, Scrum Master i Product Owner biorą się do realizacji iteracji podczas której zdefiniują potrzeby, zaprojektują rozwiązanie i wykonają coś dostrzegalnego z poziomu użytkownika. Jakie mechanizmy regulują pojawienie się pozycji w backlogu, zagwarantowanie finansowania prac zespoły. Czy zespoły zwinne faktycznie przygotowują sobie infrastrukturę do pracy, środowiska programistyczne, narzędzia do wdrażania kodu, w pierwszym sprincie, a na jego koniec są w stanie dostarczyć cokolwiek, co użytkownik może nazwać działającym, chociaż częściowo oprogramowaniem? I to wszystko podręcznikowo maksymalnie w miesiąc?
Samodzielność i autonomiczność zespołów zwinnych jest trudna do osiągnięcia w realnym świecie. Jeśli nie jest to zespół startupowy, to funkcjonuje często w złożonym środowisku biznesowo-technologicznym, w którym musi dostosować się do ogólnie przyjętych norm i reguł.
Przyjemniej i efektywniej pracuje się, jeśli to środowisko nie jest wrogie.
Organizacja nie nagnie się do małej jednostki. Nie da sobie tak po prostu narzucić zasad funkcjonowania, zwłaszcza jeśli tych zasad nie zna i nie rozumie. W rzeczywistości sposób funkcjonowania zespołu jest mocno uzależniony od jego otoczenia.
Ważne jest zatem to, żeby zespoły były kompatybilne z resztą organizacji. Żeby intencje, cele i ogólne reguły funkcjonowania były wspólne niezależnie od tego, czy nad rozwiązaniem będzie pracowało 15 osób,150, czy 1500. Muszą być przy tym dostosowane do skali organizacji i tworzonych przez nią produktów.
Te elementy budują leanowo-agileowe DNA organizacji.
W kontekście mechanizmów organizujących w sposób zwinny pracę wielu zespołów mówi się najczęściej o skalowaniu, czyli o adaptacji ról, procesów i narzędzi, które sterują pracą pojedynczego zespołu zwinnego, do poziomu grup zespołów. To jednak nie wystarczy do wdrożenia agile. Nie wszystko kręci się wokół zespołów deweloperskich. Wiele rzeczy dzieje się w organizacji na dużo przed uruchomieniem prac wytwórczych,. To co dotyczy zespołów jest konsekwencją tego, jak myślą i funkcjonują inne obszary. Aby wdrożyć zwinne podejście do rozwoju produktów niektóre mechanizmy będziemy skalować z poziomu zespołów do wyższych poziomów, a inne kaskadować z poziomu zarządzania strategicznego do operacji. Niektóre elementy z kolei nie są ani skalowane z poziomu zespołów, ani kaskadowane z poziomu strategii, rozwijają się, często w sposób niekontrolowany, we wszystkich domenach firmy, tworząc jej kulturę. W ten sposób stworzony zostanie system funkcjonujący na wielu poziomach i w wielu obszarach organizacji.
Skalujemy między innymi role, zdarzenia, narzędzia. Dla przykładu: jeśli deweloper jest odpowiedzialny z produkcję rozwiązania, to aby móc się skupić na swojej pracy funkcjonuje w ramach architektury przygotowanej w szerszym kontekście przez architektów, ci z kolei tworzą szkielety rozwiązań kompatybilne ze współpracującymi systemami i uwzględniające strategiczne cele organizacji, nad spójnością całości systemu systemów czuwa często architekt korporacyjny lub np. CTO. Każdy skupia się na swoim poziomie abstrakcji tworzonych rozwiązań jednak ich koncepcje i produkty muszą być ze sobą spójne i rozwijane w sposób zwinny.
Kaskadujemy z kolei do poziomu zespołów elementy związane z realizację portfeli projektów i programów, tak aby prace deweloperskie były ich przemyślaną konsekwencją. Kaskadowane są też elementy tworzące kulturę organizacyjną. Polityka kadrowa, apetyt na innowacje, system pracy, podejście do budżetowania i rozliczania prac. To nie są elementy definiowane na poziomie zespołów, tylko z myślą o całej organizacji. Aby zespoły mogły być zwinne, te mechanizmy muszą tą zwinność wspierać, a nawet budować.
Bo jeśli myślimy o zwinnym i stabilnym rozwoju produktów, to zwinna musi być cała organizacja, a nie wybrane zespoły. Czy jest to możliwe do osiągnięcia? Od czego zacząć?
Funkcjonuje już parę frameworków mówiących o pracy co najmniej kilku zespołów zwinnych. Najpopularniejszym i jednocześnie najbardziej rozbudowanym jest Scaled Agile Framework. Warto natomiast poznać wszystkie, bo każdy z nich podchodzi do tematu agile w skali nieco inaczej.
Scaled Agile Framework to kobyła i może odstraszać swoją wielkością. Popatrzmy jednak na niego przez filtr paru wybranych aspektów.
Tak jak ogry i cebule mają warstwy, tak SAFe ma poziomy. Kiedy zespołów jest wiele, potrzeba mechanizmów żeby je koordynować, pojawia się poziom programu, jeśli programów jest wiele, to pojawia się poziom Large Solution, żeby je koordynować…
… w związku z tym spora część SAFe’a to skalowanie fajnych mechanizmów znanych z poziomu zespołów.
Czym innym jest z kolei poziom Portfolio. To on steruje kierunkami rozwoju, głównymi inicjatywami i kulturą organizacji.
To, co trafia do backlogów zespołów (User Story, Enabler Story) nie pochodzi z próżni, jest konsekwentną dekompozycją dużych inicjatyw uruchamianych na poziomie portfela w celu realizacji strategii (Portfolio Epic, Epic Enabler).
Biznes i dewelopment pracują we wspólnym rytmie. Zsynchronizowane są wszystkie poziomy zarządcze.
Architectural Runway tworzy mocne i spójne podstawy techniczne pod rozwiązania biznesowe dostarczane przez zespoły.
Mechanizmy inspekcji i adaptacji wprowadzane są w życie na każdym poziomie i dotyczą charakterystycznych dla danego poziomu zarządczego aspektów.
Teraz już przechodzimy do meritum spotkania – lean’owo-agile’owego budżetowania rozwoju produktów.
Agile wywraca klasyczny trójkąt ograniczeń projektowych do góry nogami. Więcej możesz o tym przeczytać tutaj https://project-management.pl/agile-czyli-waterfall-do-gory-nogami/ więc nie będę powielał informacji. W skrócie: w projektach waterfallowych zazwyczaj będziemy dążyć do możliwie dokładnego zdefiniowania celu i zakresu prac jeszcze przed rozpoczęciem właściwych prac projektowych. To zakres będzie stanowił ograniczenie, na bazie którego będziemy optymalizować czas i koszt realizacji. W agile’u zakładamy pewien ograniczony czas (nie w kontekście długości trwania projektu, tylko jako rytm prac i iteracji w ramach których będziemy dostarczać kolejne przyrosty działającego rozwiązania), jak również zakładamy pewien poziom finansowania produktu, który określa nasz apetyt na jego rozwój (oczywiście po pomniejszeniu założonego budżetu o koszt utrzymania). Żeby znać koszt nie potrzebujemy znać zakresu – zamiast tego określamy jakich kompetencji będziemy potrzebować i ustalamy jaki wolumen kompletnych zespołów deweloperskich jesteśmy w stanie utrzymywać, przy założonym budżecie. Zakres w takim układzie będzie tym, co uznamy za istotne do dostarczenia w ramach danego nam czasu i kosztu. Dzięki potraktowaniu czasu i budżetu jako ograniczenia dochodzimy do tego, że dane cele biznesowe można osiągnąć różnymi produktami projektu, a finalny rezultat będzie z pewnością różnił się od przewidywanego pierwotnie zakresu. I dobrze. Niechaj się różni, jeśli oczywiście przynosi oczekiwane efekty…
… bo koniec końców nie chodzi o zrealizowanie planu, tylko o dostarczenie wartościowych rezultatów. Wszystkie rzeczy jakie wymyślą Product Ownerzy będą najprawdopodobniej wzbogacały nasze rozwiązanie. Wszystkie te elementy będziemy chcieli wdrożyć, jednak w ramach zadanych mocy przerobowych w danym czasie będziemy mogli dewelopować jedynie ograniczoną ich ilość. Będziemy zatem skupiać się na ciągłej priorytetyzacji rzeczy, jakie chcemy zrobić, niezależnie od tego, czy dane elementy były częścią pierwotnego wyobrażenia o produkcie, czy pojawiły się wczoraj. W takiej formule nie chcemy usłyszeć czegoś w stylu „Jasne, świetna funkcjonalność, niestety jednak nie była przewidziana w budżecie. Już 5 razy w pocie czoła przeplanowywaliśmy cały projekt, nie chcemy tego robić ponownie, to zbyt pracochłonne, a Wy i tak po miesiącu wymyślicie coś nowego.”.
Żeby zmiany w wymaganiach nie wiązały się z mozolnym przeplanowywaniem starannie zaplanowanych projektów i uciążliwym przebudżetowywaniem ich, co może za sobą pociągać zmiany budżetowe w wielu różnych obszarach biznesowych zaangażowanych w projekty, SAFe odchodzi od projektów w tym aspekcie i budżetuje Strumienie Wartości. Wyróżniamy dwa rodzaje Strumieni Wartości: Operacyjne i Developerskie.
Operacyjny Strumień Wartości (Operational Value Stream) opisuje kolejne kroki na ścieżce doświadczeń klienta z produktem. Od potrzeby, poprzez zapoznanie się z naszym rozwiązaniem, użytkowanie, aż po zaspokojenie potrzeby i rozliczenie. Dla produktu, jakim jest kredyt hipoteczny interakcja konsumenta z naszym rozwiązaniem zaczyna się np. od reklamy kontekstowej w przeglądarce, z której przechodzi on do bardziej precyzyjnych informacji o produkcie, potem może za pomocą prostego kalkulatora wyliczyć przybliżone parametry swojego kredytu, następnie wypełnia formularz, otrzymuje decyzję itd. Na poszczególnych krokach w procesie, zwanym też User Journey, pojawiają się zarówno żywi konsultanci, jak i systemy informatyczne (www, aplikacje mobilne, silniki finansowe, systemy wspierające pracę back-office itp.). Deweloperskie Strumienie Wartości (Development Value Streams) rozwijają te systemy i budują lepsze doświadczenie klienta z naszym produktem i usługami. To ciągi działań (od definiowania celów i wymagań, poprzez projektowanie rozwiązania, jego dewelopment, a następnie udostępnianie), które podejmujemy by dostarczyć określone rozwiązanie. Dany Development Value Stream może rozwijać jeden lub parę systemów/aplikacji, może też mieć miejsce sytuacja, w której to jedno rozwiązanie rozwijane jest przez parę Deweloperskich Strumieni Wartości. Jesteśmy już o krok od najważniejszego konstruktu w SAFe – Agile Release Train (ART).
Agile Release Train, czyli „Pociąg”, to zwinny program, czyli zespół zespołów wraz z mechanizmami, które regulują współpracę między nimi, powołany do stałego rozwoju danego rozwiązania (systemu) wspierającego Operacyjny Strumień Wartości, czyli daną „przygodę” użytkownika/klienta z naszym produktem.
Relacje pomiędzy Systemem, Deweloperskim Strumieniem Wartości oraz zespołami, które je obsługują mogą być różnorakie, od jeden do jednego, do wiele do wielu.
Programy zwinne w SAFe są porównywane z pociągami ze względu na stabilność i cykliczność. Tak jak pociąg zatacza wiele cykli danej trasy, powtarzając ją nieokreśloną ilość razy, tak zwinny program na bieżąco dla danego rozwiązania powtarza cykl, w ramach którego szuka wartości biznesowej i definiuje wymagania, następnie projektuje komponenty rozwiązania, wytwarza je w różnych zespołach i integruje, potem dostarcza na kolejne środowiska wytwórcze, by ostatecznie dostarczyć na środowisko produkcyjne i udostępnić użytkownikom.
Najwygodniej byłoby gdyby jeden ART rozwijał/integrował wszystkie systemy wchodzące w skład danego Operacyjnego Strumienia Wartości (dla uproszczenia powiedzmy „w skład danego produktu”), tak żebyśmy mieli w jednym budżecie wszystkich ludzi rozwijających dany produkt i mieć w ramach niego pełna autonomię, ale to nie zawsze będzie takie proste. Na przykład możemy potrzebować częściowo tych samych ludzi by utrzymywali jeszcze stary produkt, a już jednocześnie wprowadzali nowy, zbudowany na bazie starych komponentów technologicznych.
W SAFie nie mówimy praktycznie o zarządzaniu projektami i realizacji projektów. Zamiast „project management” pojawia się określenie „product management”. Nie chcemy dla danego rozwiązania powoływać wielu projektów, co wiązałoby się z tworzeniem business case’ów, kart projektów, precyzyjnym planowaniem i budżetowaniem, z powoływaniem zasobów, a potem z ich uwalnianiem. Nie chcemy się w to bawić. Nie chcemy estymować dokładnie i wyceniać poszczególnych funkcjonalności, by przydzielać pod nie budżet. Nie chcemy rwanego projektowego rytmu start-stop. Wiemy że mamy jeden produkt i całą masę funkcjonalności, którymi chcemy go budować lub rozbudowywać. Będziemy oczywiście z grubsza planowali wydania i kamienie milowe, ale nie będziemy pod nie tworzyć osobnych budżetów. Budżetujemy sobie armię zespołów o określanych kompetencjach i wielkości ograniczonej budżetem. Ci ludzie będę już tylko czekali na Product Backlog Items, które będą realizowali w kolejnych iteracjach, w kolejności określonej priorytetami. Budżetujemy strumień wartości, bo i przychody ewidencjonujemy dla strumienia wartości, a nie dla funkcjonalności, czy historyjek użytkownika. Stawiamy sobie cele biznesowe i z nich się rozliczamy, nie z dostarczonych itemów z backlogów, te ostatnie mogą zmieniać się dość dynamicznie, chcemy tego i możemy sobie na to pozwolić, bo budżet na nie już mamy na starcie. Tak rozumiana jest zwinność w skali dużych rozwiązań.
Część warsztatowa
Po takim wprowadzeniu zaprosiliśmy uczestników do skonfrontowania wiedzy o SAFe’owym podejściu do budżetowania z ich własnymi doświadczeniami.
Wydzieliliśmy 5 grup i przydzieliliśmy im moderatorów, którzy dbali o to, żeby mimo ograniczonego czasu wypracować jakieś pożyteczne rezultaty.
Podejście do budżetowania podzielone zostało na 5 aspektów, żeby lepiej ukierunkować dyskusje. Zespoły otrzymały arkusze, na których mogły zapisać swoje przykłady i/lub kontrprzykłady praktyk związanych z danym aspektem budżetowania.
Punktem odniesienia było podejście SAFe’a do danego aspektu i tak oto:
- przedmiotem budżetowania w SAFie nie są poszczególne projekty, lecz całe Strumienie Wartości,
- aby zapewnić otwartość zespołów na zmiany wymagań rozliczamy ich pracę w formule Time and Material, faktycznie biorąc na siebie, czyli na zamawiającego, odpowiedzialność za maksymalizację wartości biznesowej rezultatów prac zespołów,
- zgodnie z podejściem opisanym w tym artykule https://project-management.pl/agile-czyli-waterfall-do-gory-nogami/ tym co optymalizujemy jest wartość biznesowa dostarczanego zakresu, a tym co nas ogranicza jest budżet w zadanym okresie czasu, ograniczenie czasowe mówi nam też o tym, w jakim rytmie będziemy pracować, dostarczać owoce tej pracy i oceniać rezultaty,
- horyzont budżetowania Strumieni Wartości jest zazwyczaj roczny, z możliwością wprowadzania korekt np. po półroczu,
Najtrudniejszym aspektem do dyskusji było to, w jaki sposób oceniane są rezultaty prac. W SAFie na każdym poziomie hierarchii wymagań poszukuje się MVP/MMP (Minimum Viable Product/Minimum Marketable Product).
Planując większą partię prac dedykowaną osiągnięciu istotnych korzyści biznesowych (SAFe taką inicjatywę nazwa Epikiem) tworzymy pod niego uzasadnienie biznesowe wskazując, jakich hipotetycznych korzyści oczekujemy. Dobrą praktyką jest też wskazanie metryk, którymi będziemy oceniali obiektywne osiągnięcie tych spodziewanych korzyści. Następnie projektujemy minimalne rozwiązanie, które w naszym wyobrażeniu spełni oczekiwania. To jest najtrudniejszy moment, bo z jednej strony zawsze jest chęć do wymyślania dodatkowych funkcjonalności, które mogą wzbogacić nasze rozwiązanie i umiejętność wskazania granicy MVP jest ważną cechą dobrego Product Ownera, z drugiej strony nie chcemy zrobić falstartu i wypuścić do użytkowników czegoś, co ich bardziej zrazi niż zachęci. Niezależnie od tego jak dobrze potrafimy przewidzieć potrzeb klientów i zamodelować rozwiązanie, to dopiero feedback od użytkowników i obserwacja metryk powie nam na ile nasze wyobrażenia były poprawne. Wtedy dokonujemy oceny tego, co dostarczyliśmy i albo rozbudowujemy rozwiązanie (powiedzmy, że moduł, ale dla bardzo dużych systemów może to być nawet cała aplikacja), albo przeprojektowujemy je, albo zakopujemy i zapominamy o nim.
Tak wyglądały założenia pracy w grupach, których liderzy otrzymali następujące instrukcje:
PMI Connect maj 2019 – Instrukcja dla moderatora grupy
Dyskusje, przy piwie i pizzy były żywiołowe i otwarte, a miła atmosfera zachęcała do dzielenia się zarówno dobrymi doświadczeniami, jak i spostrzeżeniami z porażek.
Podsumowanie
Na początku garść statystyk odnośnie spisanych przez zespoły doświadczeń w obszarze poszczególnych aspektów budżetowania:
Wnioski i spostrzeżenia zawarte w podsumowaniu warsztatów opierają się zarówno na analizie danych statystycznych odnośnie udzielanych odpowiedzi i sygnalizowanych praktyk, jak i obserwacji przez nas na żywo pracy w grupach. Wypowiedzi, które pojawiły się w grupach, zostały spisane przez moderatorów na karteczkach post-it i pogrupowane w tematy, których dotyczyły, tak by spróbować złapać szerszy kontekst w dziedzinach, które były omawiane.
I tak …
Przedmiot budżetowania
Najczęściej pojawiającą się odpowiedzią dotyczącą przedmiotu budżetowania był zakres – prawie 60% odpowiedzi. Wskazywany był różny poziom granulacji obiektów opisujących wymagania od Epika do Produktu czy Projektu. Ok. 35% odpowiedzi wskazywało różne formy budżetowania “siły roboczej” rozumianej jako zespoły, zróżnicowane pod kątem wielkości i umiejscowienia w hierarchii organizacji, pojawiały się między innymi takie grupy zespołów, jak plemię, tribe (zapewno to samo), gildia czy departament.
Co to oznacza? Chcemy pracować zwinnie, pojawiają się zajawki takiego podejścia do rozwijania produktów, próbujemy budżetować zespoły chcąc dawać im przestrzeń do wypracowywania wartości biznesowej i funkcjonalnej produktów, zamiast zmuszać je do pilnowania budżetu przypisanego do danego zakresu, jednak jeszcze nadal zdarza nam się działać tradycyjnie, z różnych względów, np. ograniczeń wynikających z kultury organizacji lub niedostatecznie zbudowanego zaufania wobec dostawców.
Rodzaj kontraktowania
Dwie najbardziej popularne odpowiedzi w obszarze rodzaju kontraktowania to surprise, surprise, fixed price i time & material. Uzyskały one odpowiednio ok. 44% wskazań i 31%. Pojawiło się także ciekawe wskazanie „Time to Market”.
Wydaje się, że tak wysoki wynik dla fixed price nie jest zaskoczeniem. Klienci wymuszają takie podejście chroniąc swoje budżety i nie dopuszczając do przekroczenia założeń roku rozrachunkowego. To podejście jest prawdopodobnie pochodną przedmiotu budżetowania, czyli budżetowania zakresu. Podobnie jak w punkcie wyżej są “jaskółki” zwinności – T&M – “My podstawimy ci kompetencje, a Ty decyduj, co chcesz abyśmy dla Ciebie zrobili”. Daleko idącym uproszczeniem wydaje się być stwierdzenie, jakoby time and material i w ogóle podejście agile było podejściem właściwszym. To od charakteru projektu i naszych możliwości dokładnego przewidzenia jego celów i zakresu już na etapie planowania zależy to, jak bardzo stabilne będą wymagania i jak zasadne będzie definiowanie na jego podstawie budżetu. Jeśli nie potrzebujemy podejścia empirycznego, albo nie możemy sobie na nie pozwolić ze względu na wymogi branżowe (jakość, bezpieczeństwo, stabilność, niezawodność, wydajność, kompatybilność z innymi produktami, itd.) to nie ma potrzeby budowania przestrzeni na rozliczanie prac w formule T&M. Jeśli jest to świadoma i przemyślana decyzja, to podejście fixed price jest jak najbardziej zasadne. Problemy pojawiają się najczęściej w projektach, w których nasze chęci przewidzenia zakresu projektu przekraczają naszą wiedzę i możliwości, przez co zafixowany budżet koliduje z naszą potrzebą dostosowywania aktualnych wymagań do obserwacji kolejno dostarczanych produktów projektów i wzrostu naszego rozumienia jego materii.
Co jest Fixed, a co optymalizujemy
Najczęściej zafiksowany jest Zakres i Czas – chcemy mieć to, co sobie zamówiliśmy w umówionym czasie ;-). A co ze zmiennością wymagań? Co ciekawe dokładnie te same elementy zostały wskazane jako optymalizowane. Niestety nie mamy pogłębionych informacji, aby to wyjaśnić. Po prostu tak jest. Może różnorodność branż? Fajnym zjawiskiem jest to, że często pojawiało się podejście mówiące o tym, że najważniejsza jest wartość użytkowa rozwiązania i jego jakość, nawet kosztem czasu i nakładów pieniężnych. Można odnieść wrażenie, że “januszostwo biznesu” i “cebula deal” są relatywnie rzadkim zjawiskiem w reprezentowanych przez uczestników branżach.
Horyzont budżetowania
W tym aspekcie najwięcej wskazań było na szeroko pojęty projekt – kontrakt, zamówienie – 60% wskazań. Można się tu pokusić o uogólnienie, że projekt ma sztywny zakres i zafiksowaną cenę – zgodnie ze wskazaniami z wcześniejszych punktów. Czy nie przypomina to nadal myślenia klasycznego, waterfall’owego? Może z kolei jest inaczej? Jeśli szacowany zakres stanowi podstawę budżetowania, a określony budżet jest ograniczeniem dla zakresu, który później przycinany do MVP, to już możemy mówić o myśleniu bardziej zwinnym.
Budżet vs. korzyści
Ponad 52% wskazań odnosiło się do dwóch elementów: przychodu i zadowolenia klienta. W sumie wszelkie aspekty biznesowe miały ponad 76% wskazań. W kilku przypadkach pojawiła się informacja o tym, że korzyści nie są mierzone, bo są po stronie klienta lub są monitorowane, weryfikowane na innym poziomie zarządzania.
Ogólnie całość materiału wypracowanego przez zespoły można podsumować tak:
chcemy pracować zwinnie, widzimy w tym sens, poszanowanie pracy wszystkich zaangażowanych stron, skupienie na dostarczaniu wartości w szybko zmieniającym się środowisku. Przed nami jednak wyzwania związane ze ułożeniem współpracy z klientami, w taki sposób, by wskazywać im wartość jaką jest podejście zwinne, które pomoże im dostarczyć atrakcyjne dla użytkowników rozwiązania i wartość biznesową, niekoniecznie po prostu zakres w czasie.
Raz jeszcze dziękujemy wszystkim uczestnikom za przybycie,aktywne uczestnictwo i wypracowany materiał.
Autorzy:
Andrzej Gajewski
Łukasz Doliński
Zdjęcie tytułowe dzięki uprzejmości PMI PC ;]
