Trendy w zarządzaniu projektami

Trendy w zarządzaniu projektami

Spójrz proszę na poniższy wykres. Prezentuje trend wyszukiwań dwóch haseł w Google w USA. Zwróciłeś uwagę, jak czerwona linia opada i przecina się z rosnącą linią niebieską? Otóż czerwona linia to hasło „pmbok”, a niebieska to „agile waterfall”.

Wielokrotnie w artykułach na blogu odnosiłem się do analiz firmy Gartner o nazwie Hype Cycle. Jednak dziś po spędzeniu poranka na przeglądania tuzinów wykresów hype’u w różnych kategoriach nie znalazłem odpowiedzi, co będzie trendem w zarządzaniu projektami w najbliższym okresie.

Sięgnąłem więc do drugiego źródła – aplikacji Google Trends. Google Trends pokazuje częstotliwość wyszukiwań wybranych haseł. Choć nie wyświetla bezwzględnej wartości w danym okresie, to pozwala na porównanie różnych haseł do siebie oraz spojrzenie wiele lat wstecz, aby dostrzec trendy.

Uznałem, że dla potrzeb prognoz tego, co się będzie działo w biznesie dobrze jest wybrać duży, dojrzały rynek, który inspiruje często resztę planety, czyli USA.

Oczywiście hasło „agile waterfall” może być użyte w wielu różnych kontekstach. Na przykład dla poczytania o różnicach między tymi podejściami, znalezienie rozwiązania na projekty hybrydowe, dowiedzenia się w ogóle więcej na temat tego, co dzieje się w świecie project management. Podobnie „kanban” może być wyszukiwany w kontekście zarządzania projektami, jak i produkcją lub magazynem. To są dwa różne światy. Ale zaryzykuję stwierdzenie, że ogólna dynamika i wzajemne proporcje popularności tych terminów są symptomatyczne.

Dla porównania kolejny wykres pokazuje takie terminy, jak: „scrum” (niebieski), „kanban” (czerwony), „pmbok” (źółty), „prince2” (zielony). Nie użyłem słowa „waterfall”, bo ma ono jeszcze inne znaczenia, co bardzo zaburzyłoby wykres.

Jak widać w 2004 wszystkie te hasła za wyjątkiem „prince2”, były na tym samym poziomie popularności. Ale… „pmbok” od lat powoli tracił, a „kanban” i „scrum” zyskiwały. Teraz widać, dlaczego PMI tak mocno przebudował PMBOK Guide w kierunku zwinności.

Dla porównania przyjrzałem się jeszcze innym czterem terminom: „pmbok” jako punkt odniesienia (niebieski), „kaizen” (czerwony), „six sigma” (żółty), „scrum” (zielony). Jak widać niesłychanie niegdyś modna Six Sigma w USA, zalicza spadek, choć wyhamowujący. Zgaduję, że odnalazła swoją niszę i tam jest stosowana, ale jest to dużo mniejszy obszar niż niegdyś. Podobnie ma się sytuacja z Kaizenem.

Moja interpretacja

Sądzę, że metody zwinne z sukcesem zdobywają kolejne dziedziny gospodarki i teraz sięgnęły do obszarów, które były zarządzane w sposób tradycyjny. Albo pracownicy z tych obszarów chcą dowiedzieć się, o co chodzi z tym agilem, albo szukają sposobu na wdrożenie go. Jeżeli prawdą jest, że próbuje się go wdrażać w dziedzinach nie związanych z produkcją oprogramowania, to zobaczylibyśmy to na wykresie popularności słów w wyszukiwaniach.

I… ta dam. Niebieska linia to słowo „pmbok”, a czerwona to „hybrid project”.

Widzisz trend opadający tej pierwszej i wznoszący tej drugiej?

Moja teza jest taka, że aktualnie mnóstwo organizacji poszukuje formuły połączenia filozofii kaskadowej ze zwinną. Z jednej strony chcą zachować kontrolę nad kosztami, celami, efektywnością zespołów i całych firm, a z drugiej chciałyby dać zespołom operacyjnym więcej autonomii, bo zauważają, że poczucie sprawczości wzmacnia motywację wewnętrzną, zwiększa reaktywność na zmiany oraz podnosi poziom innowacyjności. Przy okazji organizacją chcą jeszcze załatwić sobie problem skalowania Scruma do dużych struktur.

Jest pewna koncepcja, która obiecuje skalowalność Scruma, poczucie kontroli na poziomie strategicznym oraz pozostawienie zwinności na dole. To Scaled Agile Framework (SAFE). W internecie można znaleźć mnóstwo artykułów o zaletach i być może jeszcze więcej o słabościach tej koncepcji. Jednego nie można jej jednak zabrać, jest coraz bardziej popularna. Kilka lat temu PMI próbował gonić SAFE, nabywając metodykę Disciplined Agile Delivery (DAD). Jednak zobaczcie na efekty.

Żółta linia to właśnie „discipllined agile delivery”, to ta której nie widać. Czerwona to dla porównania „pmbok”, zaś niebieska to „scaled agile framework”.

Widzisz, drogi czytelniku, jak przecięły się w 2016 roku i jaką dynamikę mają teraz?

Nie sądzę, aby SAFE załatwił problem hybrydowości zarządzania. Zbyt wiele jest problemów przy jego wdrażaniu. Jednak jestem bardzo przekonany, że projekty hybrydowe oraz powiązane z tym skalowanie zwinności, będą istotnym trendem w przyszłości. Pewnie pojawią się kolejne koncepcje, aż w końcu znajdziemy coś, co będzie dostatecznie dobre.

Dodam jeszcze mój osobisty wkład w hybrydyzację projektów. Idea połączenia zwinności z kaskadą chodziła za mną od dłuższego czasu. Szczególnie interesował mnie wymiar zakresu. Z jednej strony mamy WBS, czyli hierarchiczną strukturę prac. Jest wygodny, bo zachowuje logikę, pozwala przechodzić od ogółu do szczegółu, a dzięki temu jest skalowalny. Z drugiej strony mamy Product Backlog, którego zaletą jest łatwość zarządzania, przejrzystość oraz prezentacja istotności poszczególnych wymagań.

Jakiś czas temu wymyśliłem koncepcję połączenia tych dwóch technik i wyszło mi coś takiego. Pierwsze wrażenia są bardzo obiecujące, sam własne projekty trzymam w takiej tablicy. Możliwość budowania hierarchii ułatwia utrzymanie porządku na liście zadań, a możliwość automatycznej konwersji do tablicy Kanban pozwala na płynne przejście do zarządzania ich wykonanie. Nie spotkałem takie funkcjonalności w komercyjnych systemach i ciekaw jestem, czy Ty, drogi czytelniku, gdzieś już ją widziałeś. Jeżeli tak, to koniecznie daj mi znać.

 

 

 

Projekty zwinniejsze niż Scrum

Projekty zwinniejsze niż Scrum

Pod hasłem projekt ekstremalny, eksploracyjny, eksperymentalny odnalazłem przedsięwzięcia z różnych obszarów:

  1. Hackathony – to bardzo krótkie projekty od 24 do 36 godzin zwykle. Ekstremalność w nich wynika z innowacyjności rozwiązania i krótkiego czasu na produkcję.
  2. Początkowe fazy startupów – przez kilka pierwszych lat (od 2 do 5) istnienia startupy często podlega on rewolucyjnym zmianom modelu biznesowego, obietnicy wartości, sposobu organizacji. Nazywane są one pivotami a wynikają z olbrzymiej niepewności rynkowej i czasem technologicznej młodego biznesu.
  3. Testowanie nowych technologii – takie projekty można spotkać w dużych korporacjach, np. lotnictwie, jak i w mniejszych firmach, które niekiedy wręcz specjalizują się w usługach walidowania nowych technologii. Na wejściu projektu jest hipoteza, że określona technologia zadziała, a na wyjściu jest prototyp albo negatywna informacja zwrotna. Taką technologią może być prototyp urządzenia albo model AI.
  4. Projekty naukowe – ich niepewność wynika z obszaru, w którym są realizowane. Jeżeli celem projektu jest dokonanie odkrycia naukowego, to musi on być niepewny. Paradoksalnie instytucje finansujące takie badania często wymuszają planowanie i kontrolę takich projektów w sposób kaskadowy.

Koncepcję prowadzenia projektów w sposób bardziej elastyczny niż oferuje to Scrum pojawia się w wielu miejscach, np.:

Prowadząc rozmowy z kilkudziesięcioma praktykami projektów bardziej zwinnych niż agile zauważyłem kilka cech wspólnych. Za każdym razem wywiad prowadzony był w formie pytań otwartych i starałem się unikać naprowadzania rozmówcy na z góry założone wnioski. Mimo tego wielu rozmówców przywoływało podobne spostrzeżenia. Poniżej prezentuję pierwsze z nich. Kolejne będę publikował w późniejszych wpisach oraz w książce, którą prawdopodobnie skończę pisać po wakacjach 2022.

Zmienne iteracje

Cechą powszechnie wymienianą w tytułowych projektach jest to, że iteracje trwają różne odcinki czasu. Jeden z rozmówców wskazał, że u nich sprint w jednym projekcie może trwać od kilku godzin do dwóch tygodni.

Kiedy sprint powinien się skończyć? Otóż wymienia się tutaj dwa warunki. Po pierwsze, gdy zostanie dostarczona wiedza albo wykonany zadany zakres. Estymacje czasowe są tak niepewne, że regularnie sprint trwa krócej lub dłużej niż zakładano. Czasem długi czas wynika z tego, że trzeba czekać wiele dni na wyniki, a czasem dlatego, że zadania są niedoszacowane. Po drugie iteracje może zakończyć „zwrotnica” (termin użyty przez jednego z rozmówców). Projekt dochodzi do punktu, gdy pojawia się rozbieżność nie do wyeliminowania w ramach bieżących założeń. Sprint jest wówczas zakańczany, a zespół musi rozwiązać kolizję, stworzyć nową koncepcję i zaplanować dalszy zakres.

Ponadto generalnie iteracje są dużo krótsze niż w typowym projekcie Scrumowym. Zdarza się, że zespół integruje rozwiązanie co 2 dni i na nowo je planuje.

Mały zespół niezależnych ekspertów

Generalnie zespoły w takich projektach są conajmniej o połowę mniejsze niż w Scrumie. Typowy zespół to 4-6 osób, ale niektórych firmach zajmujących się sztuczną inteligencją podano mi przykłady zespołów dwuosobowych.

Dodatkowo często członkowie zespołu tak planują prace, aby móc działać niezależnie od pozostałych. Wszelkie interface’y między zadaniami tylko podnoszą złożoność projektu, a przez to ryzyko niepowodzenia. Super, gdy ludzie w ekipie projektowej mają rozdzielne kompetencje, np. ktoś od hardware, ktoś od programowania, ktoś od prezentacji, ktoś od modelu AI.

Współpraca stacjonarna

Nawet w hackathonach zdalnych zespół regularnie spotyka się u kogoś w mieszkaniu lub w biurze. Praca twórcza wymaga spędzania ze sobą czasu. Przykuwanie uwagi do problemu, szczególnie, gdy zespół jest zmęczony lub zestresowany, wymaga spotykania się. Jeżeli zespoły pracują w osobnych lokalizacjach to i tak regularnie się spotykają, aby uzgodnić postęp prac.

Powraca spostrzeżenie, że efektywność działań innowacyjnych w formule zdalnej spada i to znacząco. Brakuje dynamiki, brakuje poczucia wspólnego rytmu dowożenia zadań, brak koncentracji na celu, brakuje nieformalnego komunikacji, która potrafi przenosić góry w kilka minut.

Zmienne przywództwo

Wydawało mi się, że w projektach bardziej zwinnych niż Scrum lider będzie wzorem servant leadershipu. Pomyłka! Projekty tak zwinne często doświadczają pivotów, zmian kierunków, koncepcji, wizji. Dodatkowo są narażone na dużą presję ograniczeń czasu, kosztu, wymogów jakościowych. Ktoś musi podejmować szybkie decyzje.

To, co jest często wymieniane to lider z silną wizją, niekiedy wpadający w autokratyzm. Jednocześnie jednak taki, który w chwilach spokojnego produkowania zadanego zakresu oddaje władzę ludziom. Gdy wiadomo, co robić servant leader, gdy trzeba narzucić kierunek – autokrata. To działa w startupach i na hackathonach. Co więcej członkowie zespołów zdają się doceniać takie podejście, bo to dużo porzadkuje.

Podsumowanie

Na liście mam jeszcze kilkanaście wniosków, które nasuwają się po ponad 30 rozmowach z praktykami skrajnie niepewnych projektów. Chętnie będę o nich opowiadał w miarę zdobywania nowej wiedzy od moich rozmówców. Więc jeśli interesuje was tematyka projektów ekstremalnych, to wracajcie do bloga Octigo.

 

 

 

Zwinna metodyka Komisji Europejskiej

Zwinna metodyka Komisji Europejskiej

Wiedzieliście, że Komisja Europejska rozwija własną metodykę prowadzenia projektów w duchu agile? Okazuje się, że tak.

Efektem prac tego zespołu jest stworzenie dwóch książek, które za darmo można pobrać ze stron Unii Europejskiej. Metodykę opracowała organizacja pod nazwą PM2 Alliance. Ku mojemu zaskoczeniu, bo nie wiedziałem do niedawna o jej istnieniu, PM2 Alliance oferuje sześć certyfikatów, członkostwo i własne standardy, a nawet program afiliacyjny dla firm szkoleniowych. Sprawdziłem jednak, czy są jakieś oferty pracy wymagające tych certyfikacji i na terenie EU nie znalazłem żadnej (szukałem w Linkedin). Więc chyba organizacja nie jest jeszcze zbyt rozpoznawalna. Ciekawe, jak się rozwinie.

PM2 Alliance prowadzi działalność również przez regionalne oddziały, organizując konferencje i seminaria. Jednak nie znalazłem żadnej aktywności w Polsce. Nie ma też oddziału w Polsce. Może to jest dobry moment, aby grupa wolontariuszy przejęła inicjatywę i ściągnęła PM2 Alliance do Polski? Trzecia konkurencyjna organizacja do IPMA i PMI? Czemu nie 🙂

Książka pierwsza to zwinne projekty. Podręcznik do zwinnego prowadzenia projektów ma 114 stron i jest za darmo do pobrania z pm2alliance.eu. Nazywa się PM2 – Agile Guide 3.0.1. Napisano go w formule tzw. body of knowledge, czyli leksykony zawierającego omówienie najważniejszych zagadnień z zarządzania zwinnego projektami. Nie jest to zatem metodyka tylko opis różnych podejść wrzuconych do wspólnego worka pod nazwa agile. Treści podzielono rozdziały o różnych metodykach zwinnych, rolach, ceremoniach (głównie chodzi o spotkania), dokumentach i technikach. Aby nie był to tylko spis zagadnień, autorzy dodali wstęp omawiający, czym jest agile i jak go stosować. Do poszczególnych technik dopisano też tabelki RAM, aby pokazać, jakie role są zaangażowane w daną technikę.

Książka druga to kaskadowe. Podręcznik do kaskadowego prowadzenia projektów ma 147 stron i napisano go w bardzo podobny sposób do PMBOK Guide. Nawet układ rozdziałów przypomina tą książkę tyle, że podziału dokonano nie na obszary wiedzy a na grupy procesów: inicjacja, planowanie, kontrola, koordynacja, zamykanie. Zaś podrozdziały z kolei przypominają procesy PMBOKowe. Mają inputy, role, kroki, outputy. W książce proponuje się całą listę nowych dla mnie ról, np. User Representative, Project Owner, Solution Provider, Business Implementation Group. Mam wątpliwości, czy to nazewnictwo się przyjmie, bo w projektach raczej zadomowił się Sponsor. Mam też spore wątpliwości, gdy metodyka oferuje dużo predefiniowanych ról. Pachnie mi to wówczas Prince2 lub AgilePM, czyli malowaniem strusia w barwy kolibra.

Książki są dość obszerne i są za darmo. To ich niewątpliwa zaleta. Jednak układ treści przypomina nieco PMBOK Guide, co utrudnia uczenie się z nich od deski do deski. Raczej mogą pełnić rolę reference book, czyli pozycji, które otwiera się na właściwej stronie, gdy ma się konkretny problem. Mi bardzo brakuje w nich przykładów zastosowania. W książkach pojawia się mnóstwo terminów, np. ArOw (architecture owner), ale brakuje pokazania, jak dany termin w praktyce ma funkcjonować. Wrzucenie tabelki RAM to za mało moim zdaniem, aby dobrze to zrozumieć. Książki natomiast mogą się sprawdzić przy podejściu do certyfikacji oferowanych przez PM2 Alliance, podobnie jak PMBOK Guide pomaga w egzaminie PMP. Wadą obu pozycji jest jeszcze pominięcie opisów technik. Uważa, że właśnie techniki najlepiej jest przedstawić w formie takiego body of knowledge / leksykonu, bo czytelnik może sobie z nich sam dobierać, co mu pasuje do sytuacji.

Ta inicjatywa przypomina inicjatywę, w której sam brałem udział w Polsce. Jej celem było stworzyć podręczniki, rekomendacje i program rozwoju kompetencji zarządzania projektami dla sektora publicznego. Była ona prowadzona pod egidą KPRM. Więcej informacji o niej znajdziecie tutaj.

Więcej informacji o inicjatywie Komisji Europejskiej znajdziecie tutaj. Natomiast samą książeczkę możecie pobrać tutajtutaj.

Polski standard zarządzania projektami i portfelem

Polski standard zarządzania projektami i portfelem

Wspólnie z grupą zapaleńców podjęliśmy się kilka la temu wyzwania polegającego na spisaniu dobrych praktyk zarządzania projektami, programami i portfelem, które mogłyby być stosowane w administracji publicznej.

Początkowo inicjatywa była prowadzona pod egidą Biura Monitorowania Portfela w Ministerstwie Rozwoju, ale potem została wraz z tym biurem przeniesiona do Kancelarii Prezesa Rady Ministrów.

Zakres inicjatywy realizowanej pod egidą KPRM obejmował napisanie trzech rekomendacji, które być może w przyszłości rozwiną się do standardu: dla projektów, programów i biur portfeli projektów. Dodatkowo jej częścią miał być podręcznik, które stałem się autorem. Podręcznik wyszedł pod nazwą Przewodnik po zarządzaniu.

Wierzę, że tylko chwilowo jestem wyłącznym autorem tej książki, bowiem zamysł strategiczny jest taki, aby powołać komitet autorów, którzy wkrótce zajmą się pisaniem drugiej edycji tego podręcznika. Z mojej perspektywy najważniejsze jest to, aby powyższe pozycje żyły, rozwijały się, były stosowane w praktyce i stały się wspólną własnością. Być może dzięki nim będziemy marnowali nieco mniej pieniędzy na projekty „sasinowe”.

Wszystkie te dokumenty dostępne są w postaci elektronicznej za darmo. Zapraszam zatem do korzystania.

Tu możecie znaleźć wspomniane dokumenty: https://www.gov.pl/web/zarzadzanie-projektami/materialy-do-pobrania

Instrukcja obsługi projektu już w księgarniach i na liście bestsellerów Onepress

Instrukcja obsługi projektu już w księgarniach i na liście bestsellerów Onepress

Moja najnowsza książka na temat technik i metod zarządzania projektami oraz sposobu budowania organizacyjnej metodyki już jest dostępna.

I od razu wskoczyła na listę bestsellerów wydawnictwa Onepress.

Książkę można nabyć w sieci Empików, ale i w księgarniach internetowych.

Zawiera ponad 100 technik, metod i narzędzi stosowanych w zarządzaniu projektami. W tym zawiera uproszczoną listę procesów z PMBOK Guide 6, dla tych, dla których PMBOK Guide jest opasłą encyklopedią napisaną prawniczym żargonem.

Link do księgarni Onepress zamieszczam poniżej, jakby ktoś był zainteresowany: https://onepress.pl/ksiazki/instrukcja-obslugi-projektu-marcin-zmigrodzki,inopro.htm#format/d

Frameworki skalujące zwinne podejście do zarządzania projektami

Frameworki skalujące zwinne podejście do zarządzania projektami

Scrum zadomowił się już na dobre w polskich organizacjach IT (firmach i działach). Teraz na krzywej hype cycle koncepcji biznesowych wspinają się tzw. frameworki rozszerzające zwinną filozofię na duże przedsiębiorstwa. W jednym z poprzednich wpisów (patrz: Defiliada koncepcji biznesowych) przedstawiłem analizę z 2016 roku koncepcji zarządzania projektami i wówczas Enterprise Agile Frameworks było na samym początku drogi, jeszcze przed dostrzeżeniem przez biznes, w fazie zwanej Innovation Trigger.

Rzut oka na raport State of Agile z 2019 roku (tytułowy wykres kołowy) pokazuje, że na razie jedną trzecią rynku zagarnął SAFe, a po nim Scrum of Scrums. Jednak opcji jest dużo więcej. Przykład rozwoju metodyk zwinnych dowodzi, że po okresie rozkwitu dziesiątków podejść, nastąpiło wymieranie i trzy czwarte rynku zagarnął Scrum z technikami zapożyczonymi z Kanban, XP, czy Lean. Moim zdaniem ten scenariusz powtórzy się również na poziomie enterprise agile. Na placu boju za parę lat pozostaną dwa lub trzy frameworki, przy czym pierwsze z nich zgarnie zdecydowaną większość rynku… Albo cała idea skalowanego agile’a ustąpi miejsca kolejnemu pomysłowi na organizację pracy dużych zespołów.

Poniżej widać diagram z Google Trends dotyczący zapytań o 'Enterprise Agile Framework’ od roku 2004 do dzisiaj. Jak widać nieznaczny trend wzrostowy wystąpił w 2016 roku i od tego momentu zainteresowanie tym hasłem utrzymuje się na stałym poziomie.

Wiele dużych korporacji sięga po różne modele skalowalnego agile. Powodów zainteresowanie może być wiele: chwilowa moda, chęć pochwalenia się przed kolegami z zarządów innych korporacji, naciski ze strony pionu HR, bo chwilowa moda lub chęć pochwalenia się przed kolegami z pionów HR innych korporacji, albo bardziej merytorycznie potrzeba pokazania kandydatom do pracy, że mimo swojej skali organizacja ma przyjazną kulturę organizacyjną lub wreszcie rzeczywiste pragnienie podniesienia efektywności organizacji, w sytuacji, gdy inne, bardziej tradycyjne podejścia nie przyniosły wystarczających owoców. Nie znam raportu Gartnera z 2019 roku (nie jest dostępny za darmo), ale według raportu z 2016 roku faktycznie ta koncepcja była na początku swojej drogi.

Metodyki zwinne świetnie sprawdzają się w niewielkich zespołach. Moim zdaniem oprócz rozmiaru takie zespoły powinny mieć jeszcze kilka cech:

  • brak czynników nastawiających negatywnie do pracy, jak frustracja, niechęć do kolegów lub firmy, brak pieniędzy na podstawowe potrzeby,
  • brak konfliktów na bazie rywalizacji o lepsze zadania, pensję, wdzięki współpracowników,
  • brak próżniactwa społecznego w zespole, czyli „wożenia się” na pracy wykonywanej przez innych,
  • conajmniej przeciętne kompetencje w obszarze merotyrycznym projektu, np. w danej technologii. Moim skromnym zdaniem, jeżeli cały zespół jest na poziomie „nie wiem, że nie wiem”, albo innymi słowy na początkowym wzniesieniu wykresu Krugera-Dunninga.
  • wstawienie zespołu pod klosz Scruma, w którym mogą mieć poczucie autonomii.

Jak to się ma natomiast do dużych, macierzowych organizacji. Można tu znaleźć szereg czynników ograniczających stosowalność filozofii zwinnej:

  • budżetowanie – na ogół w cyklu rocznym planuje się i rozlicza budżety działów, świat projektów jednak nie rządzi się taką kalendarzową dynamiką.
  • hierarchia dowodzenia – kadra menadżerska bierze większe pieniądze za to, że jest odpowiedzialna za większy fragment organizacji, to oznacza, że będzie starała się kontrolować działania w podległych obszarach. Szczególnie ważne będą dla niej aspekty organizacji, za które menadżerowie mogą zostać zwolnieni lub dostać większą premię albo awans. Posiadanie władzy i rywalizacja o dostęp do pysznej termitiery, padłego mamuta, stada samic, czy pokoju na dwudziestym piętrze są stałą cechą naszego gatunku.
  • raportowanie do zagranicznych właścicieli lub na giełdę – na duże firmy nakładane są rozmaite obowiązki kontrolne, które mogą zaburzać autonomię zwinnych zespołów.
  • wielozadaniowość ludzi – macierzowość struktury organizacyjnej oznacza, że pojedynczy specjalista może przynależeć do wielu zespołów realizujących równolegle odmienne zadania. To z kolei prowadzi do błędnego planowania prac i przeciążenia ludzi.
  • trudne sytuacje decyzyjne – istnieją sytuacje, których rozwiązywanie wspólnym konsensusem jest najprostszą drogą do wojny domowej. Znajomy opowiadał mi o zwinnym zespole, który stanął przed wyzwaniem podzielenia między siebie premii. Oczywiście pieniędzy było za mało, aby zadowolić wszystkich. Zawsze jest za mało, bo tu włącza się teoria perspektywy. Podwyżka o 10% przestaje cieszyć, gdy ta wredna jędza siedząca biurko obok otrzymała 15%.

Pomocą we wdrażaniu kultury zwinnej starają się być tzw. frameworki. Poniżej krótko jest scharakteryzowałem i dokonałem ich porównania. Najpopularniejsze to SAFe 5.0, Scrum@Scale, Nexus, model Spotify, Large Scale Scrum, DAD 4.

SAFe

Aktualnie najpopularniejszy framework zwinny, ale z pretendentem depczącym mu po piętach (patrz DAD). Obejmuje poziom zespołu, wielu zespołów, portfela, wielu portfeli projektów, w końcu kultury całej organizacji. Zaczyna od definiowania strategii i uzasadnień biznesowych, a następnie przechodzi przez poziom portfela i dochodzi do pojedynczego zespołu.

Na poziomie zespołu SAFe czerpie ze Scrum, wymieniając typowe role, spotkania i cykl życia projektu. Zakłada się, że zespoły zwinne pracujące w swoich obszarach kompetencji mogą łączyć się, aby wspólnie stworzyć funkcjonującą całość, np. zwinny zespół z marketingu może zacieśniać współpracę ze zwinnym zespołem IT.

Z perspektywy zakresu prac na najwyższym poziomie mamy strategię, potem portfolio wspierane przez Kanban, a następnie release’y, które zbierają wykonane funkcjonalności z różnych zespołów. Ciekawie w SAFe ukazana jest perspektywa finansowania strategii. Zakłada się partycypacyjne podejmowanie decyzji o wydatkach, budżetowanie strumieni korzyści, a nie projektów oraz kategoryzowania inwestycji z perspektywy horyzontów zdarzeń.

Typowe techniki to business/lean canvas, epic, agile release trains, design thinking, scrum, kanban i wiele innych.

To króciutkie omówienie może sprawiać wrażenie zbagatelizowania, czym SAFe jest, więc jeszcze raz podkreślę, że jest to rozległy framework wspierający zarządzanie całą organizacją oraz kilkanaście ról i dziesiątki technik. Jednak w przeciwieństwie do DAD, SAFe stara się pełnić rolę metodyki, czyli konkretnych wytycznych działań, które powinny być wykonywane, aby być zgodnym z tym frameworkiem.

Disciplined Agile Delivery

Zbiór wiedzy nazywany DAD adresowany jest przede wszystkim do zespołów produkujących oprogramowanie. Jednak DAD stara się podejść szeroko do tej kwestii. Nie tylko opisuje moment produkowania funkcjonalności, ale również ich projektowanie, utrzymanie, wdrażanie. Stąd twórcy proponują aż 10 ról, 21 procesów zarządzania projektami oraz inspiruje się całym wachlarzem różnych innych metodyk, 6 cyklów życia projektów, technik. Takim podejście przypomina nieco PMBOK Guide, które nie jest metodyką, a encyklopedią. Z resztą na pierwszy rzut oka DAD wygląda, jak groźna konkurencja tegoż w świecie zwinnych projektów… Zaraz, przecież PMI pozbył się tej konkurencji, wykupując ją w sierpniu zeszłego roku :).

Podsumuję krótko, bo DAD jest naprawdę obszerny i wymaga osobnego artykułu. DAD to encyklopedia dobrych praktyk zwinnych projektów poukładana trochę na wzór PMBOK Guide. Z niej dopiero tworzy się firmową metodykę do różnych celów: zwinnego zarządzania całym przedsiębiorstwem, albo poprowadzenia dużego projektu.

Możemy też spodziewać się, albo równoległego body of knowledge wypuszczonego przez PMI (w formie dodatku do PMBOK o nazwie Agile Practice Guide), albo rozszerzenia PMBOK Guide o framework DAD. Tak, czy siak życzę powodzenia na przyszłych egzaminach PMP!

LESS

Robi wrażenie konkretnej metodyki zarządzania wieloma zespołami. Koncentruje się na produkcji oprogramowania w dużych projektach. Podstawową jednostką organizacyjną jest zespół Scrumowy, zakres jest dekomponowany na sprinty z użyciem backlogu itp. To, co pojawia się ponad Scrum, to:

  • Planowanie zakresu prac najpierw na poziomie wielu zespołów, a potem dopiero przydzielanie do konkretnego. Mamy też dwie role: product owner i area product owner.
  • Product backlog refinement odbywa się również dwupoziomowo, dla wszystkich zespołów razem, a potem każdy indywidualnie.
  • Analogiczna sytuacja dwupoziomowego działania ma miejsce przy retrospective.
  • W przypadku sprint review sugeruje się dokonywanie tego przez wszystkie zespoły razem ale z użyciem tzw. bazaru. Przypomina to Obeya, postery na konferencji naukowej, albo metodę wernisażową. Klient ma zaprezentowane oddawane funkcjonalności i sam kieruje się tam, gdzie są rzeczy, które go interesują.

Na to została nałożona filozofia myślenia w stylu Lean, w której z konkretów wymienia się: kaizen, 5why, WIP, VA/NVA, rodzaje strat, czas cyklu i wizualizację w zarządzaniu, karty A3. Rola kadry menadżerskiej została zredukowana do komunikacji z właścicielem produktu i zapewniania finansowania, a także usuwania przeszkód administracyjnych. Metodyka LESS adoptuje szereg technik inżynierii oprogramowania, jak TDD, RAD, automatyzację testów.

Scrum of Scrums

Podobną do LESS filozofię skalowania Scruma przyjmuje SOS, czyli Scrum of Scrums. Duży zespół dekomponuje się na mniejsze 5-10 osobowe, różnica polega na tym, że każdy taki mały zespół wybiera przedstawiciela, który komunikuje się i współpracuje na wyższym poziomie. Backlog ma dwa poziomy, codzienne spotkania są dwupoziomowe, product owner ma dwa poziomy.

Z nowych rzeczy sugeruje się utworzenie Enterprise Action Team, czyli zespołu składającego się z kluczowych menadżerów w organizacji, z Chief Product Ownerem w składzie. Ta formuła może okazać się znajoma dla członków zarządów, którzy dotychczas zasiadali w komitetach sterujących projektów.

Scrum at Scale

Kolejny framework i kolejne dwupoziomowe klonowanie Scruma. Obie koncepcje, SoS i S@S używają nawet podobnych terminów: chief product owner, scrum of scrums, EAT. Z nowości jest tutaj nawet Chief Scrum of Scrums Master w skrócie SOSM oraz Executive Meta Scrum Team, taki grupowy product owner na poziomie całej firmy. Koncepcja S@S zakłada fraktalność organizacji, więc jak mamy Scrum of Scrums (SoS), to za chwilę możemy mieć SoSoS, czyli trzy poziomową skalowalność scruma. Z resztą załączam fraktalną strukturę organizacyjną z dokumentacji tej metodyki.

Model Spotify

To właściwie nie tyle jest model zwinnego prowadzenia prac (tu rozległy artykuł na ten temat), co ogólne wytyczne dotyczące kultury organizacyjnej i sposobu formowania zespołów. Same praktyki zwinne w modelu Spotify pozostawione są poszczególnym zespołom. Spotify podkreśla, że właśnie częścią zwinnej kultury jest pozostawienie swobody zespołom, co do sposobu organizacji pracy. A to oznacza, ograniczoną egzystencje standardów.

Techniki, które Spotify promuje to: daily standup, retrospective, fail board, wspólnoty praktyków zwane tu gildiami, małe, autonomiczne zespoły, rola właściciela produktu, dekompozycja strategii na mniejsze, bardziej operacyjne części, które są zarządzane przez owe zespoły.

Plusem Spotify jest to, że skupia się nie tylko na produkcji nowych funkcji i usług przez zespoły IT, ale stara się zapewnić bazę do strategicznego zarządzania firmą. Z mojej perspektywy słabością jest zaś to, że ze względu na niewielką ilość konkretnych reguł, ról, praktyk i technik, nie jest metodyką. To oznacza, że musi polegać na zapale, konsekwencji i osobowości zarządu korporacji. Gdy tego zabraknie, cała układanka może się szybko rozsypać.

Podsumowanie

Cechą wspólną wszystkich wymienionych frameworków jest:

  • Silne skupienie się na daniu ludziom autonomii, co jest zgodne z Agile Manifesto, na które się powołują.
  • Przyjęcie, że najmniejszą jednostką organizacyjną jest zespół zwinny, zwykle Scrumowy.
  • W związku z poprzednim punktem pojawienie się typowo scrumowych ról.
  • Conajmniej dwupoziomowa dekompozycja zakresu prac: poziom Scrum of Scrums i poziom podstawowy Scruma.
  • Użycie backlogu jako podstawowego narzędzie planowania zakresu.

W mojej osobistej opinii rywalizację wygrają najbardziej rozbudowane frameworki, które skutecznie przekonają zarządy dużych firm, czyli SAFe i DAD. Pozostałe mogą się rozwodnić w krajobrazie różnych mutacji Scruma. Bo, gdy przychodzi do uzwinnienia całej firmy, już nie da się działać lokalnie, trzeba przekonać prezesa.

bizlog

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany