O dobrych praktykach stosowanych przez zespoły IT, a w tym trochę o agile i skalowaniu.

Niedawno kolega z pracy, zajmujący się jakością procesów i projektów, poprosił mnie o wskazanie paru dobrych praktyk, jakie stosujemy w IT (a konkretnie w tzw. “Pociągu”, czyli SAFe’owym Agile Release Train, czyli bardziej po ludzku, w programie “projektów” zwinnych… eh z tymi “projektami” w SAFe jest dość specyficznie, ale to temat na inny artykuł), a z których mogłyby skorzystać zespoły nie-IT w swojej codziennej pracy. Pisząc o dobrych praktykach myślał tym samym o standardach, pozytywnych inicjatywach, pożytecznych przyzwyczajeniach, słowem na zachowaniach, na które się umówiliśmy w naszych zespołach, które usprawniają pracę i których staramy się przestrzegać, a nawet te których przestrzegania bezwzględnie pilnujemy. Zależało mu przede wszystkich na praktykach na styku biznesu i IT, więc nad takimi w pierwszej chwili zacząłem się zastanawiać. Potem zrobiłem sobie listę wszystkich pozytywnych zachowań, które na szybko przyszły mi do głowy. Gdy zacząłem tą listę przeglądać, pomyślałem że chociaż wiele z nich dotyczy działań związanych z produkcją oprogramowania, to w wielu przypadkach nie stoi nic na przeszkodzie, żeby zacząć stosować je również w innych zespołach. Wierzę nawet, że wiele z nich już jest stosowanych, ba, nawet sam niektóre wdrażałem poza IT.

Dobre praktyki

Poniżej lista dobrych praktyk, które szczególnie zwróciły moją uwagę. Niektóre są być może dość powszechnie znane i stosowane, np. w produkcji, z których się wywodzą, a przez IT zostały w szczególny sposób zaadaptowane,  inne być może mało kto spoza IT przymierzał do swojego obszaru. Mimo, że są to proste rzeczy, to jednak z jakichś względów nie upowszechniły się jeszcze poza produkcją i IT.

Daily Scrum

Rytuał wywodzi się Scruma (zwinnego framework’a do zarządzania rozwojem produktów), ale ja widzę jego wartość potencjalnie w każdym zespole. Polega on na tym, że członkowie zespołu pracujący razem na pewną inicjatywą (projekt, pakiet prac, zadanie itp.) spotykają się codziennie na max. 15 minut i synchronizują się. Każdy mówi krótko czym się zajmował od ostatniego spotkania, czym będzie się zajmował do kolejnego i co go blokuje. Dzięki takiej krótkiej i treściwej wymianie informacji wszyscy wiedzą, na jakim poziomie znajdują się powiązane prace i na jakich zagadnieniach powinni się skoncentrować. Spotkanie realizowane jest na stojąco, żeby zniechęcić uczestników do przedłużania swoich wypowiedzi. Z doświadczeń w pracy poza IT wiem, że często nawet osoby współpracujące ze sobą bezpośrednio, nawet te siedzące biurko w biurko nie zawsze są do końca świadome postępów swoich prac i napotykanych problemów.

Kanban

Genialne w swojej prostocie narzędzie do monitorowania przepływu prac, zwłaszcza jeśli się dobrze wizualizuje konkretne, sensownej wielkości zadania i ich przepływ. Nie będę go opisywał, bo jest bardzo powszechnie znane, a jeśli nie, to łatwe do wygooglania. Dorzuciłem je do listy, bo niestety poza obszarem produkcji i IT nie za bardzo funkcjonuje. W wersji minimum daje obraz tego, co się dzieje, w wersji rozszerzonej pozwala zarządzać np. limitem pracy w toku, priorytetami, płynnością, czy wąskimi gardłami. Niezależnie od tego, czy używamy Kanbana, jako prostej tablicy do wizualizacji, czy jako proces Kanban. Nieważne czy wieszamy tablicę na hali produkcyjnej, czy w biurze. Nie ma również aż tak wielkiego znaczenia, czy używamy wersji cyfrowej czy analogowej. Ważne natomiast jest to, że mamy przed oczyma listę realizowanych prac przez poszczególnych pracowników, możemy śledzić ich postępy i obserwować dysfunkcje w ich przepływie. Wdrażałem Kanbana również poza obszarem IT i produkcji przemysłowej i gwarantuje, że podnosi on znacznie efektywność pracy każdego zespołu.

Czego nie ma w “Jirze”, to nie istnieje*

Ta praktyka mogłaby równie dobrze brzmieć: Jeśli nie ma tego w Jirze/ Asanie/ Trello/ Redmine/ Target Process/ (tu wstaw właściwe Tobie narzędzie do zarządzania zadaniami)/, to nie istnieje. Pozytywów z używania narzędzia do rejestrowania zadań jest mnóstwo. Przede wszystkim konieczność zapisania czegoś i formalnego zaadresowania konkretnej osobie lub zespołowi, mobilizuje do przemyślenia zakresu zadania i oczekiwanego rezultatu. Dodatkowo minimalizuje nieporozumienia, pozwala na odnajdowanie cennych informacji ze statystyk o naszych zadaniach i konsumowanych przez nie zasobach, pozwala lepiej zarządzać priorytetami. Stanowi podstawę do obrazowania i usprawniania procesów. Wiąże się z pozornie dodatkową pracą poświęconą na obsługę narzędzia, ale ta inwestycja zwróci się wielokrotnie.

Definition of Ready

Termin wybitnie IT i odnosi się do kompletności oraz jakości przygotowania wymagań, które zamawiający przekazują zespołom deweloperskim. Można to jednak przetłumaczyć na, mniej więcej, taką oto regułę: Nie przyjmujemy do realizacji zlecenia, które nie jest opisane według ustalonego standardu. Dzięki temu, dostając od kogoś zadanie do wykonania, nie zaczynamy pracy od żmudnej rozkminki i dociekania wszelkimi sposobami i kanałami tego, co autor miał na myśli. Dodatkowo, kiedy zlecający musi się przyłożyć do precyzyjnego opisania zadania, to może dojść do ciekawych przemyśleń, może też dojść do wniosku, że nie jest gotowy na zlecenie tych prac do realizacji, bo na przykład sam nie wie czego oczekuje. Takie przykładowe elementy standardu opisu zleceń lub zadań, to np. szczególna forma opisu (np. konkretny formularz zamówienia), konieczność zamieszczenia rysunku, mapy, schematu, arkusza, makiety, modelu lub konieczność zdefiniowania celu za pomocą metody SMART/ER/EST.

Prace, które są opisane w sposób niezgodny z przyjętymi standardami mogę nie być przyjęte do realizacji, co może zaoszczędzić sporo czasu niedoszłemu wykonawcy.

Decentralizacja podejmowania decyzji

Jest to dobra praktyka zapożyczona z między innymi z SAFe (Scaled Agile Framework) http://atscale.pl/o-skalowaniu/ (patrz tabela Pryncypia SAFe, ostatni punkt), w którym kładzie się na nią szczególny nacisk.

Naszą praktyką jest to, że zespoły posiadają pewną samodzielność zdefiniowaną w ramach ustalonych zakresów (np. architektura systemu, kamienie milowe, moduły i główne funkcjonalności, współdzielone komponenty, itd.) bądź przyjętych standardów (np. definicja kompletności, standardy tworzenia kodu). Określone decyzje są podejmowane samodzielnie przez zespoły funkcjonujące na poziomie operacyjnym, bo wiążą się koniecznością posiadania aktualnych i szczegółowych, często mocno specjalistycznych, informacji, a inne z kolei muszą być zatwierdzane z góry, bo wymagają znajomości szerszego kontekstu. Nie osiągniemy prawdziwej skali i efektywności działań, jeśli nie pozostawimy ludziom na poszczególnych poziomach zarządczych i operacyjnych swobody poruszania się w ustalonym zakresie. Nie tylko niweluje to wąskie gardła i poprawia jakość decyzji, ale zwiększa też motywację ludzi do pracy.

Raportowanie czasu poświęconego na zadania

Jest to zazwyczaj negatywnie kojarzone z nadmierną kontrolą. Służy jednak przede wszystkim budowaniu świadomości odnośnie pracochłonności poszczególnych prac dotyczących np. danej kategorii zleceń, rodzajów działań, czy rozwoju poszczególnych cech produktu.

Coś jeszcze?

To tylko część dobrych praktyk. To, co przyszło mi do głowy w pięć minut. A czy Ty dodałbyś coś do tej listy? Czego można nauczyć się od zespołów IT? Tylko proszę bez haseł w stylu: chodzić w kapciach ;]

Nie jesteś z IT, ale hasła które przeczytałeś zaintrygowały Cię? Podejdź do znajomego programisty, admina lub PMa i poproś o wyjaśnienie. Będzie wiedział o co chodzi.

*(@Leszek – „A w Jirze jest?” ;] )

Zwinność w skali na przykładzie bankowości.

Zaczęło się typowo. Przeczytałem artykuł ..

Potem poszło już z górki.

Wizja zarysowana w podlinkowanym tekście jest być może nazbyt pesymistyczna (dla banków, bo już niekoniecznie dla ich klientów) i lekko przerysowana, pewnie nie zrealizuje się w całości, ale coś chyba jest na rzeczy. No bo popatrzmy, jak kolejne usługi bankowe zgarniane są przez firmy technologiczne. Obrót walutami, pożyczki, usługi rozliczeniowe, kryptowaluty, coraz więcej operacji finansowych realizowanych jest poza systemami bankowymi. Pomyślałem sobie, że może nie świadczy to zbyt dobrze o umiejętności reagowania banków na potrzeby klientów i zmiany na rynku. Wygląda na to, że w obszarach, w których nie jest niezbędne duże zaplecze finansowe (np. kredyty hipoteczne), firmy technologiczne potrafią lepiej rozpoznać potrzeby klientów lub szybciej na nie reagować albo jedno i drugie. Tak to już jest, że jedne myśli rodzą kolejne i zacząłem sobie przypominać, że coś, gdzieś mi świta na hasła: banki i agile.

Deklarowana zwinność

Dużo słyszę od jakiegoś czasu o rewolucji w podejściu do zarządzania projektami w bankowości i ogólnie w branży finansowej. Wiele banków deklaruje, że wytwarza swoje rozwiązania zwinnie już od jakiegoś czasu, bądź że właśnie wdraża agile. Jednocześnie słyszę niepokojące sygnały, takie jak:

“w moim banku jest dwóch Scrum Masterów” (albo nawet “Jestem w naszym banku jedynym Scrum Masterem”)

“mamy agile… to znaczy IT mówi że używa Scruma”

“Jestem Kierownikiem Projektu… to znaczy Biznesowym Kierownikiem Projektu, bo z deweloperami bezpośrednio nie pracuję, od tego jest Kierownik Projektu IT”

“Jestem Kierownikiem Projektów IT, od 6 lat … nie, nie pracowałem nigdy bezpośrednio z zespołem deweloperskim”

“Mamy agile…. hmmm w sensie na etapach realizacji, bo etapy definiowania wymagań, analizy i projektowania robimy waterfallem”

“Agile, tak, jest agile… w IT”

Wiadomo jednak, to tylko słowa. Nie wszystko należy brać zbyt dosłownie. Każdy ma swoje doświadczenia i najlepiej to na nich budować swój obraz, a nie zasłyszanych opiniach. Osobiście trochę widziałem na własne oczy, trochę dowiaduje się od znajomych z branży finansowej, trochę od kandydatów na PMów, czy SMów, którzy przychodzą na rozmowy i opowiadają o swoich dotychczasowych doświadczeniach. Ja to tam w sumie nie wiem, jak to jest w tych bankach. Mówią, że są agile albo że się starają, to czemu im nie wierzyć. Skoro tak mówią, to pewnie jakaś prawda w tym jest. Mają zaplecze finansowe, mogą pozwolić sobie na doświadczonych specjalistów i trenerów. Chcieć to dla nich móc… no tylko jakoś nie widzę tej zwinności. Może źle patrzę?

Po czym poznać, że organizacja jest zwinna?

Po czym poznać, że dana organizacja wytwarza swoje produkty zwinnie? Po używanym frameworku? po ilości Scrum Masterów? Po miernikach agileowych? A może po umiejętności szybkiego reagowania na potrzeby klientów? Jak odróżnić zwiewną baletnicę od słonia w baletkach? Istnieją narzędzia do audytu poziomu dojrzałości projektowej, w tym dojrzałości agile’owej, ale przeznacza się je zazwyczaj do użytku wewnętrznego. A gdybyśmy tak, nie wnikając od kuchni, nie słuchając deklaracji, nie zaglądając w procesy i nie wierząc na słowo, chcieli popatrzeć z zewnątrz i zobaczyć, czy firmy dostarczają swoje produkty zwinnie, to na co byśmy patrzyli? Na atrakcyjność produktów bankowych? Częstotliwość zmian w tychże produktach? Tempo i skalę pojawiania się nowych rozwiązań? Ewolucję narzędzi dla klienta, np. serwisu www albo apki do zarządzania kontem?

O zwinności subiektywnie

Gdybym miał się wypowiedzieć na bazie banków z usług których korzystam, to czysto subiektywnie powiedziałbym o mBanku, że uwielbiam serwis klienta i aplikację mobilną, ale sama oferta produktowa jest mało imponująca. Jeśli z kolei miałbym ocenić Nest Bank, to narzędzia dla klienta jakieś takie mało porywające, ale za to produkty, które mnie obecnie interesują, deklasują większość konkurencji. Zresztą, pozbawione sensu jest zapewne dokonywanie oceny na bazie tak nielicznej i być może mało reprezentatywnej grupy klientów.

Nie potrafię jednoznacznie ocenić jak to jest ze zwinnością w bankach, ale przekonują mnie opinie i relacje mówiące o tym, że nie widać jej ani w procesach, ani po produktach. Zdaje się przy tym na oceny ludzi wiedzących więcej ode mnie. Mogę jednakowoż skorzystać z mojej wiedzy i doświadczeń, żeby zastanowić się nad powodami takiego stanu.

Co jest blokerem zwinności?

Myślę, że agile wciąż jest rozumiany przez większość, jako framework przeznaczony stricte dla zespołów deweloperskich. Moim zdaniem dzieje się tak wszędzie tam, gdzie agile nie jest jednym z filarów funkcjonowania całych organizacji we wszystkich ich obszarach, a jego zasięg ograniczony został do IT. Nie wyskalowany agile, to nieporozumienie. Piszę o tym więcej w tym artykule:

Nie jest co prawda nigdzie zakazane wprowadzenie agile w całych organizacjach, wręcz wspomina się o tym w kontekście obowiązków Scrum Mastera, jednakowoż Scrum i XP, będący zdecydowanie najpopularniejszymi frameworkami agile’owymi, z całą pewnością nie są napisane z intencją do wdrażania zwinności w całych organizacjach, we wszystkich ich istotnych domenach i na wszystkich poziomach zarządczych. Nie wskazują, jak to robić i jakimi narzędziami się posługiwać. Dlatego powstały metody wspierające lub nawet wdrażające zwinność w skali. Samo określenie “skalowanie agile”, mimo że wiąże się z bardzo szczytną ideą, jest w mojej ocenie nie niefortunne. Nie lubię go. Wolę myśleć o wdrażaniu agile od razu w całej organizacji w uwzględnieniem specyfiki różnych jej obszarów, a nie o skalowaniu procesów i narzędzi opracowanych z myślą, przede wszystkim, o zespołach deweloperskich. Więcej o różnicy między skalowaniem, a kaskadowaniem agile znajdziesz Drogi Czytelniku w tym artykule:

A Ty zastanawiałeś się jak dostrzec zwinność w oferowanych przez dostawców produktach z perspektywy konsumenta?

Co o motywacji wie nauka, a co na to biznes.

Uwolnij wewnętrzną motywację Bystrzaków*

Jedno z dziewięciu pryncypiów SAFe’a brzmi Unlock the intrinsic motivation of knowledge workers i mówi o uwalnianiu wewnętrznej motywacji tzw. Pracowników Wiedzy. Tak dla pewności, chodzi o pracowników, których Wikipedia opisuje w sposób następujący:

“Pracownik Wiedzy – jedna z definicji pracownika wiedzy (ang. „knowledge worker”) stworzona przez T. H. Davenporta stwierdza, że mają oni wysoki stopień wiedzy specjalistycznej, wykształcenie lub doświadczenie, a wykonywana przez nich praca wymaga tworzenia, dystrybucji oraz wykorzystywania wiedzy. Pracownicy wiedzy to nowa kategoria specjalistów, których podstawowym zadaniem jest produktywne wykorzystanie i wymiana wiedzy. Odpowiadają oni za kreowanie i wdrażanie nowych pomysłów, dzięki którym organizacje dopasowują strategię do zachodzących coraz szybciej zmian w otoczeniu biznesowym. Ich podstawowym zadaniem jest poszukiwanie, wymiana, łączenie i wykorzystanie wiedzy wewnątrz organizacji i poza jej granicami.”

Wszystkie szkolenia SAFe mają w swoim zakresie przybliżenie 9 Pryncypiów i na wszystkich omawiane jest to z nich, które mówi o uwalnianiu wewnętrznej motywacji zwinnych zespołów, czyli Unlock the intrinsic motivation of knowledge workers. Mechanizmy wewnętrznej motywacji tłumaczone są między innymi przy użyciu odwołania do eksperymentu na małpach, jaki przeprowadził w roku 1940 Profesor Harry F. Harlow. Materiały szkoleniowe SAFe dość lakonicznie opisują, jak wyglądał sam eksperyment i szybko przechodzą do wniosków, przyjrzałem mu się zatem nieco bliżej. Bez nadmiernej dociekliwości i nadgorliwości oczywiście. Tylko trochę głębiej niż ma to miejsce na szkoleniach.

Eksperyment

No dobra, nie dwanaście małp, jak mówi tytuł wpisu, tylko osiem. Dodatkowo zagadnienie nie jest aż tak fantastyczne jak film, do którego nawiązuje tytuł. Nie mniej jednak tematyka jest bardzo ciekawa, a opisana teoria wywraca do góry nogami dotychczasowe podejście do motywacji, prawie jak S-F. Prawie robi różnicę. Po kolei jednak.

Harry F. Harlow, był profesorem psychologii na Uniwersytecie Wisconsin. W 1940 rozpoczął jedne z pierwszych na świecie badań zachowań ssaków naczelnych. Prowadził różne badania, a wśród nich, w roku 1949, uruchomił wraz z dwoma kolegami dwutygodniowy eksperyment na grupie 8 małp dotyczący uczenia się. Naukowcy zmajstrowali prostą zagadkę mechaniczną, taką jak na rysunku poniżej:

Źródło: The Puzzling Puzzles of Harry Harlow and Edward Deci, https://mobileroadie.com/img/extras/232/drivepages1thru4.pdf

Zabawka działała w bardzo prosty, przynajmniej dla ludzi, sposób – aby podnieść blaszkę należało wykonać następujące działania:

1. wyciągnąć wbitą pionowo szpilkę (ta na łańcuszku)
2. odczepić haczyk
3. podnieść blaszkę

Ot i tyle, żadnej nagrody na końcu, żadnego skarbu w miejscu pod blaszką.

Harlow i jego koledzy umieścili zabawkę-łamigłówkę w klatce z małpami i zaczęli je obserwować, planując przeprowadzenie weryfikacji ich umiejętności rozwiązywania problemów po dwóch tygodniach ćwiczeń. Na ciekawe spostrzeżenia nie musieli jednak czekać tak długo. Coś nieoczekiwanego zadziało się niemal od razu. Małpy zaczęły bawić się łamigłówką z niespodziewanym skupieniem, determinacją i jak się wydało obserwatorom, z radością. Do momentu przeprowadzenia testów kończących eksperyment, małpy nabrały już niezłej wprawy w rozmontowywaniu zabawki – nauczyły się rozwiązywać zagadkę szybko i regularnie, w 75% przypadków znajdowały rozwiązanie poniżej 60 sekund. Co ciekawe, nikt nigdy nie uczył je jak doprowadzić do podniesienia blaszki. Nie dostawały przy tym żadnej nagrody.

Takie zachowanie pokazywało mechanizm stojący w sprzeczności z tym, co do tamtej pory sądzono na temat naczelnych, w tym człowieka. Autorzy eksperymentu znali dwa czynniki motywacyjne sterujące zachowaniem. Pierwszy z nich, to popęd biologiczny. Jednak jak łatwo można zauważyć, nie z nim mieli do czynienia, bo małpy za swoje sukcesy nie były wynagradzane jedzeniem, wodą, czy seksem. Drugi znany motywator, kij i marchewka, też nie były adekwatne w tym przypadku. Dlatego Harlow opisał w swojej pracy trzeci czynnik – wewnętrzną motywację. Nagrodą i czynnikiem motywacyjnym była radość z ukończenia wyzwania. Sama już ta obserwacja była niezłym przełomem, ale to, co udowodniono później były już małą rewolucją. Naukowcy, jakkolwiek zauważyli wyraźne obecność wewnętrznej motywacji, nie będącej popędem biologicznym, to jednak domniemywali, że ma ona słabszą moc oddziaływania niż dwa pierwsze motywatory. Zaczęli więc nagradzać małpy rodzynkami za dobrze zrealizowane zadanie zakładając, że dzięki temu ich wyniki będą jeszcze lepsze. No i zdziwili się. Nagradzanie spowodowało, że pojawiło się więcej błędów i rzadziej udawało się dojść do rozwiązania. Świadomość nagrody wyraźnie rozpraszała. Harlow podsumował swoje obserwacje stwierdzeniem, że wewnętrzna motywacja może stanowić równie mocną siłę napędową działań, co potrzeby biologiczne oraz zewnętrzne nagradzanie i karanie.

Czym jest zatem wewnętrzna motywacja?

Jedną z kolejnych osób, które zajmują się czynnikami motywacyjnymi, tym razem z ukierunkowaniem na pracowników, jest Daniel H. Pink. Powołuje się on na wyniki paru badań dowodzących istnienie ciekawych zależności:

• Gdy mamy do czynienia z prostymi zadaniami – zwiększanie wynagrodzenia przekłada się na większą motywację i lepsze wyniki
• Gdy realizowane są zadania złożone, wymagające dużej wiedzy i kreatywności, gdy nie widzimy jednego prostego rozwiązania, w większości przypadków zwiększanie premii za sukces prowadzi do gorszych wyników

W przypadku działań, które na co dzień podejmują Pracownicy Wiedzy, czynnikami prowadzącymi do lepszych wyników i większego samozadowolenia są:

• Autonomia
• Mistrzostwo
• Cel

Oczywiście te czynniki zagrają tylko wtedy, gdy poziom wynagrodzenia nie odbiega od standardów rynkowych dla danego stanowiska.

Autonomia, to możliwość podejmowania decyzji w dedykowanym obszarze, to posiadanie realnego wpływu na istotny obszar realizowanych zadań, umożliwiające wdrożenie swoich pomysłów i wykorzystanie pełni swego potencjału.

Mistrzostwo, to nasza wewnętrzna chęć dążenia do doskonałości albo przynajmniej do osiągnięcia ponadprzeciętnego poziomu. Czasem są to rzeczy ściśle związane z pracą, czasem coś absolutnie z nią niezwiązane, jak gra na instrumencie, sztuka ogólnie, sport, gry komputerowe, a czasem takie odjechane rzeczy, jak walka mieczem, czy bicie rekordów w nurkowaniu. Lubimy być w czymś dobrzy i kręci nas jeśli jesteśmy lepsi od innych. Nawet jeśli nie czerpiemy z tego żadnych innych korzyści poza satysfakcją z istnienia tego faktu.

Cel, a może nawet bardziej powód, to wartość która nadaje głębszego sensu tego co robimy. Potrafimy wykrzesać z siebie dużo więcej energii, jeśli mamy przekonanie, że to co robimy jest ważne, potrzebne, pożyteczne, że czyni świat lepszym miejscem.

Zresztą, co ja tam będę się mądrzył, najlepiej o swoich spostrzeżeniach, na dodatek dużo ciekawiej ode mnie, opowie sam Dan Pink. Dlaczego warto poświęcić parę chwil na podlinkowany filmik? Poniżej jedno z poruszonych zagadnień:

dawno, dawno temu, równolegle realizowane były dwa projekty mające dostarczyć dwa konkurencyjne produkty o bardzo podobnych cechach – online’owe encyklopedie. Projekt pierwszy miał duży budżet i był realizowany przez Microsoft, dla którego pracowali profesjonalni deweloperzy, doświadczenie i dobrze opłacani managerowie oraz specjaliści branżowi dostarczający tysiące wpisów do encyklopedii. Drugi projekt był realizowany przez wolontariuszy, którzy pracowali za darmo. Nazwy produktu Microsoftu pewnie nawet nie znasz, ten drugi produkt, to Wikipedia. Zainteresowany dlaczego tak się stało? To tak o motywacji wypowiada się Dan Pink:

Tak działa wzbudzanie wewnętrznej motywacji Pracowników Wiedzy. Potwierdzasz te mechanizmy na własnym przykładzie albo na przykładach z własnego podwórka? Ja się pod tym podpisuję wszystkimi kończynami.

Takie tematy, odnoszące się nie tylko do zwinnych technik deweloperskich i procesów zarządzania zespołami, ale też do kluczowych elementów funkcjonowania organizacji chcących realizować swoje produkty w sposób zwinny poruszane są na szkoleniach SAFe. Jeśli interesują Cię one, to nieco więcej możesz przeczytać tutaj:

Zresztą, może szkoda czasu i pieniędzy, żeby chodzić na te szkolenia. Jeśli jesteś z natury dociekliwy, to pewnie wystarczy Ci przelecieć się przez tematy poruszane w tym frameworku i sprawdzić materiały źródłowe. Wiele z ciekawych spostrzeżeń, odnośnie różnych aspektów zwinności, nie jest wytworem myślowym twórców SAFe’a tylko czerpie z różnych światowych autorytetów. SAFe czasem po prostu wskazuje na kontekst i skalę danego zagadnienia. Takich inspiracji i wskazówek jest w tym frameworku dużo, nawet jeśli nie cenisz SAFe’a albo wręcz do nienawidzisz (kto komu zabroni?), to warto posłuchać/poczytać takich ludzi, jak Daniel H. Pink, Don Reinertsen, W. Edwards Deming, czy Dantar P. Oosterwal. Mondrze gadajo.

*Tak, wiem, ja i te moje tłumaczenia.

PI Planning, czyli jak planować prace wielu zwinnych zespołów na dłużej niż sprint.

Dlaczego warto przeczytać artykuł o PI Planning

Ten artykuł jest długi, a jego czytanie może być męczące. Z PI Planningiem jest podobnie, to wyczerpujące dwudniowe spotkanie, które potrafi dać ostro w kość. Może uda mi się tym podsumowaniem wzbudzić u Ciebie zaciekawienie, które da Ci motywację do przebrnięcia przez te wszystkie linijki tekstu. Myślę, że warto nawet jeśli nie interesuje Cię SAFe, ani Agile w Skali, bo znajdziesz tutaj opis tego, jak planować pracę dla wielu zespołów. Żadne rocket science, ale za to parę praktycznych wskazówek z życia wziętych.

Program Increment Planning, to jedno z ciekawszych narzędzi, z jakimi miałem do czynienia podczas mojej pracy w zarządzaniu projektami, programami i portfelami. Pokazuje ono, że przy zachowaniu pewnych standardów i dobrych praktyk można zaplanować pracę powiązanym ze sobą zespołom zwinnym na okres dłuższy niż sprint, niż dwa sprinty, a nawet trzy. Konkretniej, na mniej więcej kwartał. W niewielu organizacjach doświadczyłem czegoś podobnego. W niektórych nie spotkałem się nawet z czymś zbliżonym do takiego planu, nawet w przypadku programów waterfallowych, a co dopiero zwinnych. Wiąże się to z ogromem pracy, a synchronizacja zespołów przed i podczas tego rytuału jest bardzo męcząca. Każde niedociągnięcie organizacyjne skutkuje przepalaniem dużej ilości czasu deweloperów, a wiadomo jak drogi jest to czas. Presja jest duża, ale mimo to jest w tym całym natłoku prac jakiś urok. Biegający ludzie, latające karteczki, zamazane tablice, charczące głośniki, zapach pizzy i kawy, brak tlenu…  atmosfera jest niesamowita, a poczucie satysfakcji, kiedy choć częściowo jesteśmy w stanie zapanować nad tym szałem twórczym i wiemy jak będzie wyglądała praca dziesiątek deweloperów w ciągu najbliższego kwartału, jest ogromne.

No to teraz możemy zaczynać

Jeśli Agile Release Train, czyli Pociąg Wydań, albo inaczej zwinny Zespół Zespołów, jest głównym mechanizmem napędowym SAFe’a, to PI Planning jest jego silnikiem napędowym. W tym, dość sporym, artykule dzielę się swoimi praktycznymi doświadczeniami z realizacji tego rytuału. Zakładam, że trochę już wiesz o SAFe, muszę tak zrobić, bo gdybym chciał inaczej, gdybym miał wyjaśniać dokładniej każdy element SAFe’a, który pojawia się w kontekście PI Planningu, to nie napisałbym artykułu tylko mini podręcznik tego frameworka. Zakładam zatem, że orientujesz się Czytelniku, czym jest Scaled Agile Framework i do czego służy, albo chociaż czym jest Agile w Skali, a czytając ten artykuł chciałbyś dowiedzieć się jak w praktyce wygląda to wydarzenie, czemu służy, jak się do niego przygotować, jak je poprowadzić i jak wpływa ono na pracę zespołów. Tak od kuchni. Od teorii do praktyki. Jeśli jednak nie znasz SAFe’a, to nic. Możesz śmiało odpuścić sobie te wszystkie niezrozumiałe hasła i patrzeć na PI Planning, jako po prostu sposób na planowanie prac wielu deweloperom. Jestem przekonany, że podobne podejście można zastosować do planowania na przykład etapu lub fazy w projekcie klasycznym. Oczywiście pojawią się istotne różnice, ale znajdziesz też parę cennych analogii.

Czym jest PI Planning

PI Planning (Program Increment Planning, czyli Planowanie Przyrostu Programu), można by w dużym uproszczeniu nazwać wyskalowanym Sprint Plannigniem. Tak jak pojedyncze zespoły agile’owe planują swoje Sprinty i ich Przyrosty oraz prace realizowane w ich ramach, tak Zespół Zespołów, czyli Agile Release Train w ciągu dwóch dni planuje wspólny Przyrost Programu i składające się na niego prace realizowane podczas sumy sprintów zespołów. SAFe zaleca aby Program Increment trwał 8 do 12 tygodni, a jednocześnie zachęca, żeby sprint trwał 2 tygodnie. Najczęściej zatem w ramach PI’a mieści się 4 do 6 sprintów. Z tych sprintów ostatni nazywany jest Innovation and Planning i przeznacza się go na prace nie tworzące bezpośrednio Przyrostu Produktu, czyli takie, jak badania, tworzenie Proof of Concept, czy Proof of Technology, eksperymenty, szkolenia i planowanie kolejnego Program Incrementu. Ze względu na tą specyfikę, z moich obserwacji wynika, że optymalne są Program Increment’y sześcio-sprintowe. Te mniejsze mają narzut innowacyjno-organizacyjny zbyt duży do udźwignięcia dla większości organizacji, z kolei te większe niż sześcio-sprintowe niosą ze sobą ryzyko tego, że ujęte w ich ramach wymagania biznesowe mogą nie być dostatecznie przygotowane i stabilne w tak długim horyzoncie. Dodatkowo, sześć dwutygodniowych sprintów daje nam trzymiesięczne, czyli kwartalne Przyrosty Programu, co ładnie zamyka się w ramach roku kalendarzowego i wprowadza fajny rytm prac.

Poniższy obrazek ilustruje zależność między Przyrostem Programu a Sprintami i umiejscowienie PI Planningu:

Źródło: http://www.scaledagileframework.com

Zanim zacznie się PI Planning

Najważniejsze nie jest samo wydarzenie, podczas którego spotykają się wszystkie zespoły realizujące wspólnie program, tylko to, co dzieje się przed PI Plannigiem. Jeśli liczymy na to, że zespoły są w stanie w dwa dni poznać wymagania i ich kontekst biznesowy, a następnie zdekomponować je, oszacować i zaplanować prace na najbliższy kwartał łącznie z powiązaniami między zespołami, to jest duża szansa, że zarówno samo planowanie, jak i cały PI okażą się porażką. Żeby zespoły mogły zaplanować swoje backlogi na kilka sprintów do przodu i na koniec planowania móc podpisać się pod tym planem, to wymagania muszą poznać już wcześniej. Muszą mieć czas na ich zrozumienie, zdekomponowanie, uzupełnienie, oszacowanie, czy przeprowadzenie rozpoznania w używanych technologiach. To jest też czas, w którym przynajmniej na poziomie ogólnej architektury, tworzone są koncepcje rozwiązań. Na wszystko to nie będzie czasu na samym PI Planningu, na którym deweloperzy powinny skupić się połapaniu zależności między zespołami, weryfikacji wszelkich wątpliwości i rozplanowaniu w czasie prac na cały Program Increment z dokładnością do sprintów i kamieni milowych. Przy dużej ilości zespołów pracujących nad jednym rozwiązaniem, jakiej architektury byśmy nie wypracowali, to sama ilość powiązań będzie na tyle duża, że zespoły powinny właśnie na nie zwrócić największą uwagę, a swoje własne backlogi powinny mieć już zawczasu przygotowane. Przynajmniej na ogólnym poziomie. Dobre przygotowanie przekłada się na sukces spotkania i całego Przyrostu Programu, warto na nie wykorzystać, co najmniej, cały sprint Innovation and Planning.

Jeszcze jedna rzecz, która powinna wydarzyć się przed właściwym PI Planningiem

Drugim bardzo ważnym aspektem przygotowania PI Planningu jest podjęcie decyzji odnośnie tego, które elementy Program Backlogu trafią do estymacji do poszczególnych zespołów i być może ostatecznie do ich Team Backlogów. Nie możemy po prostu pokazać wszystkim zespołom pełnej listy wymagań i liczyć na to, że same się nimi podzielą. Częściowo oczywiście tak będzie, bo nawet wstępnie przydzielone tematy, według np. kompetencji, znajomości poszczególnych istniejących komponentów rozwijanego produktu, pojemności czy używanych technologii, mogą zostać po przeanalizowaniu przekazywane między zespołami. Nie możemy jednak pozwolić sobie na dawanie wszystkiego do zapoznania się wszystkim. Zawsze dysponujemy ograniczonym czasem i wstępnie musimy zdecydować, komu zostaną dane wymagania przydzielone do estymacji. Zanim więc do elementów backlogu siądą zespoły, trafią one do architektów, którzy przygotują zarys planu. Planowanie bowiem też ma w Agile iteracyjny charakter.

Oczekiwane rezultaty PI Planningu

Zanim wejdziemy w szczegóły konstrukcji PI Planningu warto przedstawić, jakie produkty/efekty powinien wygenerować ten rytuał:

• cele na cały Program Increment
  • PI Objectives wspólne dla całego Agile Release Train
  • Team PI Objectives dla poszczególnych zespołów
• zaplanowane wstępnie sprint backlogi na cały PI
• mapa powiązań między zespołami
• synchronizacja pomiędzy biznesem i produkcją
  • dewelopment poznaje aktualną wizję rozwiązania, kluczowe wymagania i plany biznesowe
  • biznes otrzymuje feedback określający ile zespoły są w stanie dostarczyć w ramach danego Przyrostu Programu (w oparciu o ten feedback może urealnić swoje plany)

Rekomendowana agenda spotkania

Dzień 1		Dzień 2
8:00-9:00	Prezentacja kontekstu biznesowego	8:00-9:00	Prezentacja korekt wymagań
9:00-10:30	Wizja tworzonego rozwiązania	9:00-11:00	Planowanie w zespołach
10:30-11:30	Wizja architektoniczna i standardy tworzenia kodu	11:00-13:00	Finalny przegląd planów i lunch
11:30-13:00	Omówienie zasad planowaniai przerwa na lunch	13:00-14:00	Zarządzanie ryzykami programowymi
13:00-16:00	Planowanie w zespołach	14:00-14:15	Głosowanie poparcia dla planu
16:00-17:00	Przegląd planów zespołów	14:15-???	Wprowadzanie zmian do planu
17:00-18:00	Przegląd menedżerski planów i warsztat rozwiązywania problemów	???	Retrospektywa planowania

PI Planning krok po kroku

DZIEŃ PIERWSZY

Prezentacja kontekstu biznesowego

Jedną z wielu fajnych rzeczy w SAFe jest to, że patrzy on bardzo szeroko na to, jak powstają produkty. Nie skupia się na części dotyczącej stricte zespołu, tylko obejmuje powiązania z szeroko pojętym biznesem, nawet do poziomu strategii. Jest to coś, czego brakowało mi w innych frameworkach. Oczywiście inne metody nie zabraniały patrzeć szerzej na dostarczanie wartości biznesowej w organizacji, ale zdecydowanie nie kładły na to tak dużego nacisku i nie proponowały przekonujących narzędzi. Przynajmniej mnie nie przekonywały.

Przedstawienie kontekstu biznesowego jest właśnie jednym z tych miejsc, w których SAFe dba o synchronizację między różnymi poziomami i obszarami organizacji. Oczywiście zespoły mają do dyspozycji swoich Product Ownerów, którzy zarządzają wartością biznesową dostarczanych rozwiązań, ale przy zwinności w skali oprócz informacji o konkretnych zachowaniach produktów, ich komponentów, czy modułów, deweloperom przydaje się świadomość tego, dla kogo jest to rozwiązanie dedykowane, z czego wynika pomysł na jego wytwarzanie, jak planowane jest wejście na rynek lub ekspansja na istniejącym itd. Istotne też jest, jakie są oczekiwania organizacji wobec rozwiązania rozwijanego przez obszar wytwórczy, gdzie chcemy być w tym roku, w przyszłym, co jest potrzebne jeszcze w tym kwartale. Chodzi o informacje, które w wielu firmach dystrybuowane są niemal wyłącznie na poziomie komitetów sterujących. Dzięki takiemu podejściu deweloperzy nie są klepaczami kodu z magicznej skrzynki, tylko częścią większej całości, o takiej samej świadomości biznesowej, jak sprzedaż, czy marketing. Działa to bardzo motywująco i pozytywnie wpływa na utożsamianie się tworzonym rozwiązaniem, z firmą i jej klientami, wiemy dzięki temu jak ważna jest nasza praca i na co się w firmie przekłada. Oczywiście ma to też korzystne odzwierciedlenie w jakości tworzonych produktów.

Wizja dostarczanego rozwiązania

Po zapoznaniu się z kontekstem, w jakim osadzony jest produkt oraz celami strategicznymi, zespołom znacznie łatwiej jest zrozumieć koncepcję rozwiązania. Ten punkt PI Planningu prowadzony jest najczęściej przez Product Management lub w przypadku bardzo dużych rozwiązań przez Solution Management, czyli grupę ludzi którzy projektują rozwiązanie na poziomie strategicznym i całych strumieni wartości (np. linii produktowych). W tym miejscu przekazywane są już precyzyjne informacje na temat tego, jak wygląda rozwiązanie obecnie, jakie mamy role użytkowników, jak wyglądają poszczególne moduły, jak komunikują się między sobą i jak przebiegają główne procesy end to end. Kulminacją tej części jest określenie tzw. Top Features, czyli listy funkcjonalności, jakie powinny być dostarczone w ramach nadchodzącego Przyrostu Programu. Bardzo ważne jest to, że ta lista nie stanowi celu w klasycznym projektowym rozumieniu. Jest to raczej lista potrzeb biznesu, które w zestawieniu z perspektywą technologiczną jest podstawą do planowania prac zespołów. Podczas PI planningu będzie miało miejsce parę iteracji składających się z przedstawienia oczekiwań osób zarządzających rozwojem produktu oraz informacji zwrotnej od zespołów na temat ilości wartości, jaka może być dostarczona w ramach PI’a. Pojawią się kompromisy i korekty, zapewne też małe spory ;] Ostatecznie powstanie zakres prac, pod którym będą mogły “podpisać się” obie strony – biznes i dewelopment.

Wizja architektoniczna i standardy tworzenia kodu

W SAFie duży nacisk kładzie się na synchronizację pomiędzy poziomami zarządczymi i domenami. Każde rozwiązanie powinno wynikać ze strategii, a jego założenia biznesowe, powinny być spójne z wizją technologiczną. To zapewnia zdrowe podstawy do stabilnego, płynnego i przewidywalnego rozwoju produktów. Zaburzenie tej równowagi wyklucza zwinność. Dla przykładu, jeśli w ramach kompromisów kładziemy zdecydowanie większy nacisk na zakres funkcjonalny kosztem narastającego długu technologicznego, to z czasem okaże się, że rozwijanie nowych cech produktu obarczone jest zbyt wielkim narzutem na radzenie sobie z ograniczeniami architektonicznymi. W pewnym momencie może uczynić to rozwój produktu, nawet o małe przyrosty funkcjonalne, zbyt wolnym, zbyt nieprzewidywalnym i zbyt kosztownym, żeby szybko nadążać za rynkiem lub go wyprzedzać. Możemy utracić zdolność do elastycznego reagowania na bieżące potrzeby biznesowe. W zwinnej realizacji projektów w skali, od nagłych zrywów dostarczających duże przyrosty funkcjonalności ważniejszy jest płynny, stabilny rozwój z zachowaniem równowagi pomiędzy korzyściami biznesowymi, jakością rozwiązania z perspektywy użytkownika i jego koszernością w wymiarze technicznym (czyli optymalizacja kodu, otwartość architektury, poziom udokumentowania rozwiązań, stabilność, bezpieczeństwo czy możliwość skalowania).

W związku z tym po wystąpieniu biznesu i zaprezentowania jego potrzeb, czas na odniesienie się do nich przez architektów systemowych. Skoro zatem powstaje lista wymagań funkcjonalnych, równolegle przygotowywana jest też lista tzw. enablerów, czyli rozwiązań technicznych umożliwiających dostarcznie mechanizmów niewidocznych z poziomu użytkownika. SAFe wyróżnia następujące rodzaje enablerów:

• eksploracyjne
• architektoniczne
• infrastrukturalne
• zapewniające zgodność (z przepisami, z politykami wewnętrznymi organizacji, ze standardami branżowymi, itp.)

Omówienie zasad planowania i przerwa na lunch

Po wysłuchaniu kontekstu biznesowego, głównych wymagań oraz koncepcji realizacji wraz z ogólnymi wytycznymi technologicznymi, zespołom pozostaje już niemal tylko rozejść się, złapać oddech i brać się do planowania. Zanim to jednak zrobią przyda się garść informacji organizacyjno-technicznych odnośnie tego, gdzie znajdują się materiały źródłowe, jak planować sprinty, jak przygotować prezentację zakresu, jak uzupełniać Program Board, czyli tablicę ilustrującą ogólny plan prac wszystkich zespołów na cały Program Increment. Każda wskazówka jest cenna i pomaga zapanować nad tym, co będzie się działo w zespołach i między nimi. Trywialne rzeczy mogą zadecydować o tym, czy uda się właściwie zobrazować zakres prac zespołów i relacje między nimi: czy zespoły zaprezentują swoje plany na wspólnej tablicy, czy na arkuszach i karteczkach post-it, a może w Jirze, Redmine, czy we wspólnym arkuszu kalkulacyjnym. Istotne będzie też określenie, jak zaznaczamy relacje, do jakiego poziomu szczegółowości schodzimy, jak formułować cele zespołów na ten PI, co będziemy prezentować na forum? Jest tego cała masa drobiazgów. Te drobiazgi jednak budują produkt końcowy tego spotkania. Żeby można to było zintegrować i uzyskać big picture, plany zespołów muszą być spójne nie tylko merytorycznie, ale też technicznie. Scrum Masterzy będą oczywiście dbali o to, żeby zespoły mogły skupić się na merytoryce i wezmą na siebie facylitację prac, ale będzie tego mnóstwo, a czas bardzo ograniczony, muszą to robić przy zachowaniu spójności i pewnej unifikacji. Im więcej elementów zdefiniujemy, im więcej technikaliów wyjaśnimy, lepiej przygotujemy szablony i podamy przykłady, tym sprawniej pójdzie praca zespołów, a jej wyniki będą bardziej przejrzyste.

Planowanie w zespołach

Zespoły mają około 3 godzin na przygotowanie draftów swoich planów na dany Program Increment i zadbanie o to, żeby te plany były spójne. Można wygospodarować nieco więcej czasu, jeśli skrócimy poprzednie bloki, ale cudów nie ma, jeśli chcemy mieć jeszcze czas na ich prezentacje na forum oraz weryfikację, jeśli mamy się z tym wszystkim zmieścić w jednym dniu, to dużo więcej czasu nie będzie dane zespołom. To jest ten moment, w którym spijamy śmietankę, albo gorzką pianę z piwa, którego sobie nawarzyliśmy podczas sprintu Innovation and Planning. To jest jest ten moment, w którym wychodzi, jak dobrze zespoły poznały i zrozumiały zakres, który chcemy wypracować. Jeśli będziemy teraz czytać historyjki użytkownika po raz pierwszy, jeśli dopiero teraz zapoznamy się z opisami funkcjonalności, to jesteśmy w lesie. Wątpliwe jest, aby zdążyć z zaplanowaniem pracy dla własnego zespołu, a co dopiero zrozumienie tego, co robią inni, żeby połapać zależność. Do tego momentu jasne powinny być nie tylko intencje biznesowe, ale też konkretne wymagania i koncepcje ich realizacji. W idealnym rozwiązaniu, powinniśmy mieć już zdekomponowane i oszacowanie swoje elementy backlogów i skupiać się na zależnościach z innymi zespołami. Ciężko bowiem rozmawiać o relacjach organizacyjnych i technicznych jeśli poszczególne zespoły nie są w stanie pokazać co robią i jaki mają na to pomysł.

W międzyczasie mają miejsce synchronizacje Scrum Masterów Product Ownerów i Architektów, w ramach których weryfikowana jest na bieżąco spójność i kompletność planów.

Przegląd planów zespołów

Zaplanowanie prac na cały PI przez poszczególne zespoły dla siebie samych, jakkolwiek jest sporym wyzwaniem, to tylko połowa sukcesu. Nie mniej ważne jest upewnienie się, jak te wstępne, zespołowe plany prac, zdekomponowane do poziomu historyjek użytkownika i zadań, mają się do wymagań biznesowych i do planów innych zespołów. Plan dla całego Agile Release Train nie jest tylko sumą planów poszczególnych zespołów, tylko wspóldzielonym, zintegrowanym planem. Top management musi uzyskać spójny obraz całości, który może zaakceptować, z kolei poszczególne zespoły muszą upewnić się, ile nieprzewidzianej dotąd przez nich pracy kryje się w relacjach z innymi zespołami. Zaprezentowanie swojego planu prac przez zespół, w taki sposób, żeby zaspokoić te wszystkie potrzeby nie jest łatwe, a im więcej zespołów bierze udział w PI Planningu, tym mniej czasu na wchodzenie w szczegóły. Zespół raczej nie przytarga ze sobą tablicy z miejsca, w którym ją tworzył na salę, w której zbierają się wszyscy interesariusze, odręcznie opisane karteczki post-it i arkusze papieru raczej nie zapewnią odpowiedniej czytelności, narzędzia elektroniczne są bardzo użyteczne, ale współdzielone aplikacje i dokumenty potrafią klęknąć przy takim ruchu. Jako Release Train Engineer odpowiedzialny za przygotowanie i prowadzenie PI Planningu parę siwych włosów zawdzięczam martwieniu się tym, jak zorganizować pracę zespołów. Od narzędzi jeszcze ważniejsze jest wsparcie Scrum Masterów, to o czym zapomni, przekręci, nie zrozumie deweloper, może być jeszcze naprawione przez osobę opiekującą się zespołem. Oczywiście są zespoły, które dodatkowej pomocy nie potrzebują, ale przy realizacji pierwszych PI Planningów lepiej wyjść z założenia, że wszyscy uczestnicy, a może i organizatorzy, będą się poruszali nieco jak goryle we mgle.

Przegląd menedżerski planów i warsztat rozwiązywania problemów

Zespoły zaprezentowały swoje wstępne plany. Teraz top management (właściciele biznesowi, menedżerowie produktów, architekci…) ma chwilę dla siebie, żeby go zrozumieć i odnieść się do niego. Możliwych reakcji jest wiele, z czego najbardziej prawdopodobne, to:

• rozwiązanie problemów zgłaszanych przez zespoły,
• zmiana planów biznesowych,
• wprowadzenie korekt wymagań,
• zmiana decyzji architektonicznych
• wzmocnienie zespołów

W najlepszym scenariuszu może mieć miejsce akceptacja planu bez uwag i z uśmiechem na ustach, ale proponuję nie nastawiać się na to.

Cokolwiek  zostanie postanowione, musi być zakomunikowane zespołom na początku drugiego dnia, żeby to mogły się do tego odnieść i wprowadzić korekty do swoich planów.

DZIEŃ DRUGI PI PLANNINGU

Prezentacja korekt wymagań

Dzień pierwszy PI Planningu zaczął się od wizji i oczekiwań top managementu, potem zespoły tworzyły plan będący odpowiedzią na te oczekiwania, na koniec dnia biznes i architekci przyglądali się temu planu i widzieli, jak symulacja rzeczywistości weryfikuje ich pomysły. Przedstawiony im plan mógł być zgodny z ich życzeniami, ale mógł też mocno od nich odbiegać. W zależności od tego jak bardzo przekonujące było to, co zaprezentowały zespoły, top management programu może wprowadzić korekty do swoich oczekiwań lub oczekiwać korekt po stronie zespołów, wspierając ich w tym. Może to być równie dobrze miks obu podejść. Cokolwiek postanowią osoby zarządzające programem, pierwszym punktem drugiego dnia jest zakomunikowanie tego zespołom.

Planowanie w zespołach po raz drugi

Zespoły ponownie rozchodzą się korygując, dokańczając i szlifując swoje plany. Ten blok może wyglądać bardzo różnie w przypadku poszczególnych zespołów. Jedne będą na spokojnie dokańczały swoje plany, inne będą tworzyły je na nowo, bo zmiany mogą okazać się fundamentalne, reszta znajdzie się gdzieś pomiędzy, bliżej jednego lub drugiego bieguna.

Finalny przegląd planów i lunch 

Finalne plany są ponownie prezentowane na forum. O ile pierwszego dnia to prezentacje mogły być jeszcze lekko chaotyczne, być może nie przedstawiały kompletnych planów, mogły zawierać trochę błędów, przez co traktowane były z pewną dozą pobłażliwości, o tyle w drugim dniu te plany muszą pokazać, że zespoły wiedzą co mają do zrobienia, jak się za to zabrać oraz jak zapewnić spójność rozwiązań z innymi zespołami. Pytań do prezenterów jest zdecydowanie mniej niż pierwszego dnia, bo większość uwag zostało wprowadzonych, ale każde pytanie, czy wątpliwość zgłoszone na tym etapie są bardzo istotne, a odpowiedzi nie powinny pozostawiać wątpliwości.

Autorzy SAFe’a sugerują że jest to dobry moment na lunch. Ja mam jednak nieco inne doświadczenia z serwowaniem posiłków podczas PI Planingu. Są oczywiście niezbędne. Kiedy ktoś myśli o pustym żołądku, to nie myśli o backlogu. Dobrze jest też jeśli te posiłki są zorganizowane, żeby uczestnicy PI Planningu nie kminili “co by tu zjeść” i nie bawili się w logistykę. Sprawdzającym się rozwiązaniem jest dostarczenie pizzy i zagwarantowanie zakąsek dostępnych wtedy, kiedy zespoły rozchodzą się na planowanie. Wtedy czas “lunchowy” jest wykorzystany na pracę, chociażby nawet z pizzą w ręku na kanapie. Jedzenie jest pod ręką i każdy po nie sięgnie w odpowiadającym mu momencie.

Zarządzanie ryzykami programowymi

To zarządzanie ryzykami, to dość szumna nazwa. Skoro mówimy o ryzykach, które zespoły eskalują od razu, bo nie czują się na siłach do zarządzenia nimi, to są to z natury rzeczy skomplikowane i trudne do ujarzmienia. Mało którym z nich jesteśmy w stanie skutecznie zaradzić już podczas PI Planningu, więc ten punkt polega bardziej na zaadresowaniu ryzyk. Najważniejsze z nich są omówione i przypisane do następujących grup:

• rozwiązane – w przypadku ryzyk, które uda się skutecznie rozpracować już na PI Planningu
• zaadresowane – kiedy nie możemy zbyt wiele zrobić z danymi ryzykami, ale potrafimy przypisać je do osoby, która posiada wiedzę i zasoby, żeby się nimi zaopiekować
• zaakceptowane – kiedy nie mamy pomysłu jak zaradzić zmaterializowaniu się tego ryzyka, a nawet może to być niemożliwe, nie pozostaje nam nic innego jak zaakceptować jego istnienie i przygotować się na jego konsekwencje
• mitygowane – w odniesieniu do ryzyk, których co prawda nie możemy wyeliminować, ale już na ten moment wiemy, że możemy minimalizować prawdopodobieństwo ich materializacji, bądź orientujemy się jakimi działaniami możemy łagodzić skutki pożaru

Głosowanie poparcia dla planu

Kiedy uznajemy, że mamy plan, istotna jest wspólna jego akceptacja i przekonanie o jego sensowności. Mówimy tu zarówno o nastawieniu do planu własnego zespołu, jak i pozostałych oraz ogólnie dla całego Agile Release Train. SAFe proponuje głosowanie, tzw. fist of five, w ramach którego każdy pokazuje od 1 do 5 palców, im więcej, tym większa nasza wiara w sukces. W istocie, nie tak ważna jest dokładna znajomość wyników głosowania, jak możliwość podzielenia się swoimi uwagami, przez osoby, które po dwóch dniach pracy wciąż widzą słabe punkty planu. Otwartość i odwaga w komunikacji może zaoszczędzić sporo problemów w przyszłości.

Wprowadzanie zmian do planu

Jeżeli uwagi okazują się bardzo poważne, to nie możemy tak po prostu rozejść się z wypracowanym planem i od kolejnego dnia roboczego zacząć go realizować, jak gdyby nigdy nic. Powinniśmy wprowadzać korekty do momentu, w którym plan stanie się przekonujący. Tak mówią autorzy SAFe’a. Rzeczywistość mówi, że ludzie są już w tym momencie bardzo zmęczeni i myśl o kolejnych godzinach, ba, nawet minutach poświęconych na planowanie jest myślą, którą z całą zawziętością przeganiamy. Bardziej prawdopodobny jest scenariusz, w którym plan mimo pewnych niedociągnięć jest akceptowany, a liderzy skupiają się na jego podsumowaniu i przygotowaniu najbliższych kroków, które ten plan wzmocnią.

Retrospektywa planowania

Oczywiście fajnie jest spisywać wszelkie uwagi i pomysły na usprawnienia na bieżąco i podsumować sobie na gorąco zakończony rytuał. Co się udało? Co było lepsze niż ostatnio? Co można by poprawić? Ale pamiętasz… ludzie są już naprawdę zmęczeni. Osobiście wolę robić takie retro na spokojnie w czasie realizacji Program Incrementu.

Zamiast podsumowania

Chcesz wiedzieć jak PI Planning wygląda u innych?

O doświadczeniach Lego we wdrażaniu SAFe’a i o tym jak wyglądają ich PI Planningi możesz przeczytać tutaj i obejrzeć w podlinkowanym filmiku:

http://atscale.pl/o-paladynach-krzyzowcach-i-gorze-glupcow/

Decentralizacja podejmowania decyzji.

Kiedy prowadzę szkolenia SAFe, zwłaszcza Leading SAFe i SAFe PO/PM, moją ulubioną ich częścią są Pryncypia. Wydają się być dość ogólne, ale doskonale przekazują idee lean i agile w skali. Dają się przy tym bezproblemowo przełożyć na konkretne działania w wielu obszarach produkcji systemów informatycznych. Wszystkie dziewięć pryncypiów są mądre i użyteczne, ale szczególnie przyjemne jest uczenie ostatniego – Decentralize decision making. Nie tylko dlatego, że jest trafione w punkt, a jest, bo bez delegowania decyzyjności i wyznaczania podwładnym obszarów autonomii nie zbuduje się skali w żadnej działalności. Jest takie również dlatego, że na szkoleniu wykorzystywane jest świetne wystąpienie o budowaniu relacji lidera z zespołem, którego narratorem jest kapitan łodzi podwodnej David Marquet. Na szkoleniach użyta jest wersja skrócona z użyciem rysunków, ale polecam wersję dłuższą. Jest to świetna historia, świetnie opowiedziana i z mądrym przekazem, do zastosowania niemal w każdej organizacji.

Ideę zawartą w tym pryncypium oraz w ilustrującej go historyjce rozumiem następująco: przy dużych, złożonych i długotrwałych przedsięwzięciach nie warto próbować być alfą i omegą, w najlepszym wypadku zostanie się bowiem wąskim gardłem i spowolni rozwój organizacji, w gorszych scenariuszach można zacząć generować błędy, niestety często błędy, które będzie powielała organizacja, a w jeszcze gorszym można się zajechać na śmierć. W każdym z tych scenariuszy bycie liderem alfa oznacza brak przestrzeni na myślenie zespołu i wyłanianie się liderów.

Zresztą, sam zobacz:

… a właściwie nie tylko dla Agile.

Czy SAFe jest Agile?

A jakbym powiedział, że dla niektórych organizacji nie ma to znaczenia? Więcej w tym artykule:

SAFe – nie tylko dla zwinnych

Tym razem gościnnie na blogu Karolina Jarocka

BTW: Oczywiście, że SAFe jest Agile ;]

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

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 ;]