Prezentacja ze Śniadania PMów, 24.11.2018
Przetestować Scruma, XPka, czy Kanbana w swoich projektach jest dość łatwo. Dużo trudniej jest spróbować pracy z frameworkami zbudowanymi pod agile w skali. Takie próbne czy testowe wdrożenie wymaga zaangażowania tak dużej ilości obszarów organizacji, że wciąż jeszcze mało kto w Polsce decyduje się na taki krok. Dlatego wiedza na temat SAFe, LeSS, czy Nexusa pochodzi najczęściej z drugiej, a nawet trzeciej ręki, dużo rzadziej z własnych doświadczeń, przez rodzi się na ich temat sporo niekoniecznie prawdziwych opinii. Na jednym ze spotkań z cyklu Śniadania Project Managerów https://kjarocka.pl/wydarzenia/sniadanie-project-managerow-8/ dzieliłem się swoimi doświadczeniami i przemyśleniami odnośnie skalowania agile. Poniżej slajdy z prezentacji wraz z komentarzem. Oczywiście ten materiał ma pełną wartość raczej tylko dla uczestników spotkania, dla pozostałych czytelników może być nieco enigmatyczny, no ale cóż zawsze to jakaś forma substytutu.
Popróbować SCRUMa, czy innej techniki zwinnej na poziomie zespołu deweloperskiego jest dość łatwo. Zwłaszcza w tzw. fazie deweloperskiej projektu. Z Agile w Skali nie jest już tak łatwo, tutaj nie wystarczy umówić się na pewien sposób działania z paroma, parunastoma osobami i powiedzieć sobie „spróbujmy tego”. Zabawa w Scaled Agile angażuje dużo obszarów w organizacji i ciężko zbudować sobie pod to piaskownicę. Dlatego wśród opinii na temat skalowania agile przeważają te, które nie wynikają z własnych doświadczeń. W takiej sytuacji nietrudno o mylne wyobrażenia.
Zwinne zespoły potrafią być niesamowicie efektywne.
W regularnych, krótkich iteracjach dostarczają podobnej wielkości przyrosty funkcjonalne produktu. Dzięki temu 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.
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…
… a próby zwinnego zarządzania projektami bywają źródłem frustracji.
Przyczyn i objawów może być wiele. Szczególne miejsce wśród nich mają różnice w sposobie myślania między zespołami zwinnymi, a resztą organizacji.
Zobaczmy zatem jak to zazwyczaj wygląda w rzeczywistości.
Weźmiemy 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. 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. 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.
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? 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 ;]
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ąż scrum i agile traktowane są jak magiczne zabawki IT i 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 jego 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ół zwinny jest w stanie dostrzec ze swojej perspektywy?
Jak duży musiałby być, ż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 sa w stanie dostarczyć cokolwiek co użytkownik może nazwać działającym, chociaż częściowo oprogramowaniem? I to wszystko 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ólnie niezależnie od tego, czy nad rozwiązaniem będzie pracowało 15 osób, czy 150. Muszą być przy tym dostosowane do skali organizacji i tworzonych przez nie 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ą praca 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ą 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 a inne kaskadować z poziomu zarządzania strategicznego. 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 odpowiedzalny 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 abstracji 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.
Oczywiście zachęcam do czytania mojego bloga ;]
Scaled Agile Framework to kobyła, 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.
Parę słów o tym jak MOGŁOBY to wyglądać na konkretnym przykładzie. Firma jest prawdziwa, produkt też, ale cała reszta absolutnie zmyślona przeze mnie.
Szukałem dobrego, przyjemnego przykładu, a że rozkmniniałem to siedząc na fotelu i brzdąkając na gitarze to wzrok mój przykuł multiefekt gitarowy Bossa. Pomyślałem, czemu nie i wymyśliłem taką oto NIEPRAWDZIWĄ, ACZKOLWIEK NIEKONIECZNIE NIEPRAWDOPODOBNĄ historię. Jest zatem firma Roland z Japonii, która między innymi pod marką Boss robi świetne urządzenia dla muzyków, w dużej mierze dla gitarzystów.
Strumienie Wartości kształtują organizację.
Przykładowy Operacyjny Strumień Wartości opisuje kolejne kroki na ścieżce doświadczeń klienta z produktem.
Za poszczególnymi krokami stoją systemy, które wspierają te procesy, Deweloperskie Strumienie Wartości rozwijają te systemy i budują lepsze doświadczenie klienta z naszym produktem i usługami.
Zwinne programy (Agile Release Trains) obsługują Deweloperskie Strumienie Wartości. Tutaj widzimy przykład kiedy relacja Pociągu do strumienia jest 1:1 ale te relacje mogą być różne w zależności od charakterystyki strumienia i kompetencji zespołów tworzących Pociągi.
Na poziomie portfela finansowane nie są projekty tylko Strumienie Wartości.
W pewnym uproszczeniu, w Waterfallu zakres stanowi nasze ograniczenie i podstawę planowania, a koszt i czas są sterowanymi pochodnymi, na bazie ich relacji powstaje plan, który staramy się realizować, a odstępstwa od niego mają być niezwłocznie niwelowane. W Agile staramy się założyć czas (a właściwie rytm pracy) i koszty (czyli stały wolumen zasobów jakimi dysponujemy na co dzień w ramach rozwoju danego Strumienia Wartości), z zakresu zrobimy w danym czasie tyle ile się zmieści do Sprintu, a na poziomie programu do Program Incrementu. Zawsze będzie więcej elementów w backlogu niż mamy aktualnie mocy przerobowych. Zawsze będą one skolejkowane z uwzględnieniem priorytetów. Zrobimy w danym czasie tyle ile się zmieści, ale będziemy się skupiać na wyborze w pierwszej kolejności tych które przyniosą największą wartość biznesową w danej chwili. W tym modelu skupiamy się na priorytetyzowaniu elementów backlogów, przez co maksymalizujemy wartość, a nie optymalizujemy koszty.
Inicjatywy na poziomie Portfela zarządzane są transparentnie w dedykowanych temu poziomowi: Kanbanie i Backlogu.
Elementy na tym poziomie to Portfolio Epiki i Epic Enablery (tak, SAFe wprowadza tu sporo zamieszania bo w większości miejsc nazywa je po prostu Epikami i Enablerami, co jest o tyle mylące, że na innych poziomach te elementy nazywają się tak samo i tylko z kontekstu wiemy, że chodzi i Epiki na poziomie Portfela, a nie o Epiki na poziomie Programu, to jest strasznie słabe, duży minus dla ekipy SAFe’a za to). .
Jednym z takich Epików na poziomie Portfela jest:
Budowa i wprowadzenie na rynek nowego modelu multiefektu – ME-80.
Na etapie lejka może on być jeszcze dość lakonicznie sformułowany. Właściwie jakkolwiek. Na przykład jako parę zdań w mailu.
Kiedy Epic dojrzewa do etapu Przeglądu jego właściwe sformułowanie zaczyna nabierać istotności.
W SAFie używa się takiej formuły do opisu Epika na tym poziomie.
Tak może to wyglądać.
Kiedy Epic dojrzewa do etapu Analizy jego opis staje się już dość poważny.
Do opisania Epika na tym etapie może służyć formatka Lean Business Case. Tutaj link do szablonu:
Lean Business Case zawiera sporo elementów z czego najistotniejsze, to:
- hipotezy odnośnie oczekiwanych korzyści biznesowych (zakładamy że do momentu weryfikacji przez użytkownika, wszystkie zakładane korzyści to tylko hipotezy) or propozycje sposobu ich weryfikacji
- lista funkcjonalności, które budują minimalny produkt, który może stanowić dla użytkownika wartość za którą jest skłonny zapłacić (Minimum Viable Product lub inaczej Minimum Marketable Product)
Realizacja Epika w SAFe ma charakter zbliżony do modelu startupowego – najpierw budujemy MVP, żeby zweryfikować trafność naszych pomysłów, a następnie w zależności od odbioru przez klientów rozwijamy rozwiązanie, zakopujemy je lub cofamy je do etapu definiowania.
Przykładowe MVP i dodatkowe funkcjonalności tego rozwiązania mogłyby być następujące:
Wskazane przykładowe funkcjonalności dotyczą samego skonstruowania urządzenia, wszystkie one składają się na jedno Capability, które jest dedykowane Pociągowi, który odpowiada za tworzenie Hardware’u i Firmware’u. Epik natomiast podzielony zostaje na więcej Capabilities dedykowanych Pociągom odpowiadającym za rozwój WWW do prezentacji produktów, czy aplikacji Boss Tone Central, która stanowi bazę gotowych do pobrania i zainstalowania brzmień.
Pełen zakres wymagań na wszystkich poziomach wygląda następująco:
Poszczególne Capabilities trafiają do właściwych Pociągów, które są ze sobą synchronizowane na poziomie Large Solution. Poszczególne programu (ART) odpowiadają za dostarczenie funkcjonalności (Features) a zespoły za Historie Użytkownika. Całość rozwiązania jest integrowana na bieżąco, nie rzadziej niż raz na Program Increment.
Pojawiają się kolejne Epiki, które są dekomponowane na Capabilities, które trafiają do właściwych Pociągów, te z kolei dekomponują je na Features, a konkretne zespoły na Stories. Poszczególne systemy rozwijane są w ramach dedykowanych ich Strumieni Wartości w tempie dyktowanym przez wielkość przydzielanych im budżetów.
Tak wiem, że to ogromne uproszczenie ;]
