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ć.

 

 

 

Zwinni. Zbrodnia i Scrum

Zwinni. Zbrodnia i Scrum

4 maja ukaże się moja książka na temat Scruma pod tytułem Zwinni. Zbrodnia i Scrum.

Tutaj możecie znaleźć linka do sklepu wydawnictwa Helion, gdzie będzie można ją nabyć. Prawdopodobnie ukaże się też w Empiku i internetowych księgarniach.

Zanim będzie dostępna postanowiłem napisać kilka słów, o czym jest. Zwinni… to powieść w gatunku kryminału. Szajka przestępców zostaje zmuszona lub zachęcona do przeprowadzenia kradzieży ponad sześciotonowego dzieła sztuki. Ze względu na jego wielkość ów przedmiot trzeba zwinąć kawałek po kawałku, co staje się pretekstem do zorganizowania projektu scrumowego.

Około 90% książki to fabuła i akcja, natomiast 10% to pokazanie w praktyce zastosowań technik i metod zwinnych. Jest parę trupów, miłość i pieniądze, jak to w projektach.

Zależało mi jednak przede wszystkim na zilustrowaniu czegoś ulotnego, co jednak decyduje o tym, że projekt jest zwinny lub nie. Chciałem pokazać wartości projektu zwinnego, postawy te właściwe i te niewłaściwe w takim projekcie. Aby je dobrze pokazać, musiałem wprowadzić sytuacje konfliktowe, dylematy bohaterów, spadki motywacji i kryzysy. Jak to mówią, na dobre czasy, to i PRINCE2 da radę, dopiero w kryzysie ujawnia się duch zespołu.

Chciałem pokazać też coś jeszcze bardziej ulotnego. Z różnorodności osobowości członków zespołu, z tarć pomiędzy nimi i okazywanego wsparcia rodzi się duch zespołu. W trakcie kolejnych przełomów banda indywiduów staje się zgraną drużyną. Zależało mi na tym, aby na końcu czytelnik pomyślał sobie „chciałbym być częścią tej ekipy”.

Głównym bohaterem książki jest niedoświadczony Scrum Master, który ma za zadanie zorganizować projekt, w którym jeszcze nie brał udziału – kradzież dzieła sztuki. Głównym bohaterem jest też mafioso, który ku swojemu zdziwieniu i rozbawieniu jest wtłaczany w rolę sponsora projektu. Głównym bohaterem jest również dziewczyna, na której zlecenie odbywa się cała akcja, która nieporadnie próbuje odgrywać rolę product ownera. Wreszcie najbardziej głównym bohaterem jest zespół, który nawet nie ma świadomości, że jest zwinny, ale ta ignorancja niespecjalnie mu przeszkadza.

Jeżeli jesteście ciekawi, czy mi się udało, zapraszam do lektury. Tutaj będziecie mogli znaleźć książkę.

Aby przekonać wydawnictwo, że jest to nadal podręcznik, to na końcu książki dodałem słownik terminów ze świata agile. Także jest pełna profeska.

Narzędzia w projektach ekstremalnych – Bardziej niż agile

Narzędzia w projektach ekstremalnych – Bardziej niż agile

Po 30 wywiadach z praktykami projektów ekstremalnych zaczęła zapełniać mi się lista narzędzi, które są stosowane w takich projektach. I często słyszę o wielu z nich po raz pierwszy. Inne, mimo, że znane, natomiast są wykorzystywane w nietypowy sposób.

Poniżej zamieszczam listę narzędzi wspierających zarządzanie projektami bardzo zmiennymi i ryzykownymi, który stosują przedstawiciele uczelni, startupów, agencji reklamowych, korporacji, czy zespołów studenckich.

Przy okazji mam roboczy tytuł nowej książki Bardziej niż Agile. Co sądzicie? (więcej…)

Wiele wskazuje, że na naszych oczach rozwija się nowa metodyka prowadzenia projektów

Wiele wskazuje, że na naszych oczach rozwija się nowa metodyka prowadzenia projektów

Co jakiś czas napotykam podobną myśl, choć różnie nazwaną. Sposób podejścia do wymyślania, produkcji i wdrażania innowacji. Na własne potrzeby nazwałem to podejściem eksploracyjnym. Od kilku lat w różnych blokach powracała idea realizacji projektów z perspektywy weryfikacji hipotez. Idea mi osobiście spodobała się na tyle, że namówiłem wydawnictwo Helion do przetłumaczenia książki, która o tym opowiadała. Mowa o Testowaniu pomysłów biznesowych Blanda.

Kiedy jednak Gartner umieścił na swoim raporcie hype cycle koncepcję hipothesis-driven development (HDD), uznałem, że coś się dzieje. Trochę informacji o HDD można znaleźć tutaj. Gdy poczytałem sobie o HDD, uświadomiłem sobie, że idea jest podobna do pewnych aspektów lean startup. Stawianie hipotez korzyści pojawia się również w SAFe. Jest to od dawna charakterystyczne dla projektów Six Sigma na poziomie Black Belt, gdzie częściej stosuje się wnioskowanie statystyczne oparte także na hipotezach H0 i H1. Delikatne nawiązanie do takiego podejścia znajdziemy też w Disciplined Agile, gdzie jeden z cykli życia projektów nazywa się Exploratory (jego schemat macie poniżej w tekście). Delikatne, bo DAD nie mówi wiele więcej o tym podejściu, nie definiuje technik, nie stosuje nawet terminu – hipoteza. W końcu, albo przede wszystkim, stawianie hipotez jest od około stu lat charakterystyczne dla nauki. Dzisiaj trudno wyobrazić sobie badanie połączone z eksperymentem lub obserwacją, w którym nie stawiano by hipotez, nie budowano by z nich modelu i nie weryfikowano by całości.

Z ciekawszych technik warto wspomnieć, że HDD zakłada specyficzny sposób definiowania wymagań zamiast perspektywy roli użytkownika, jego wymagań funkcjonalnych i spodziewanej korzyści:

  • We Believe 
  • Will Result 
  • We Will Have Confidence To Proceed When

Przykładowo:

  • Wierzymy, że – Dodanie powiadomień w grze mobilnej, które wyświetlają się, gdy gracz nie gra w nią
  • Da efekt – wzrostu retencji i liczby sesji w grze
  • Będziemy pewni, że można potwierdzić hipotezę, gdy – retencja jednodniowa wzrośnie o 5 punktów procentowych a liczba sesji o 10 punktów procentowych liczonych dla kolejnych 10 dni.

Wiele badań pokazuje, że coraz mniej można ufać ocenom eksperckim, czyli pochodzącym z głowy kogoś, kto uważa siebie za mądrego człowieka, czyli często nas samych. Rzeczywistość jest coraz bardziej złożona i dynamiczna, a poczucie pewności siebie bywa coraz bardziej zwodnicze w takich czasach.

Podejścia agile i waterfall mają wiele elementów różnych, ale czymś, co je łączy jest wyjście od wizji przyszłego produktu i dekompozycja jej na mniejsze części reprezentujące funkcje, bądź elementy konstrukcyjne. Zbiór podejść, które zamierzam wrzucić do jednego worka o nazwie eksploracyjne wychodzi natomiast od listy niepewności. Następnie sortuje je albo według skali niewiedzy albo według wartości, którą da wypełnienie ignorancji wiedzą. A następnie z weryfikacji hipotez wynika zakres funkcjonalny.

Podam przykład dla lepszej ilustracji. Załóżmy, że uruchamiamy usługę pisania CV przez internet. Algorytmy AI będą podpowiadały najlepsze sformułowania na bazie tysięcy CV wyciągniętych z Linkedin. W podejściu roboczo nazwanym eksploracyjnym będziemy najpierw zastanawiali się, jakie są kluczowe wskaźniki decydujące o sukcesie serwisu. Załóżmy, że głębokość wizyty, czyli liczba odwiedzonych stron, jest krytyczne, bo użytkownicy, którzy przejrzą więcej niż 5 stron mają większą skłonność do zostawiania swoich danych. Zatem wymyślając funkcję np. generowania seksji w CV dotyczącej edukacji postawimy hipotezę, że wprowadzenie danej funkcji zwiększy głębokość wizyty średnio o 2 strony. Mając tak zdefiniowane propozycje funkcji, można je posortować według jednego z dwóch kryteriów:

  1. Eliminacji niewiedzy
  2. Wartości biznesowej

W podejściu zwinnym lub kaskadowym wyjdziemy od wizji końcowego rozwiązania i podzielimy ją na funkcje do implementacji. W obu tych podejściach można wykorzystać wiedzę jednego guru, który całe rozwiązanie ma w głowie lub zorganizować warsztaty z zespołem albo klientami i wykorzystać wiedzę wielu osób. Tak czy siak korzystamy z jakościowych opinii ekspertów opartych na ich poczuciu pewności siebie. W podejściu zwinnym również sortuje się funkcje, ale według ogólnie rozumianej wartości dla product ownera, czyli jego subiektywnej oceny.

Drugą charakterystyczną cechą, obok sposobu planowania zakresu, w projektach eksploracyjnych jest zwinny cykl życia. Dzieli się je na sprinty, ale z jedną różnicą. Poszczególne sprinty mają różną długość, zależną od zdolności do implementacji zmian i weryfikacji hipotez. Czasem po napisaniu funkcji trzeba długo poczekać, aż uzbierają się dane. Przykładowo zmiana nawigacji po gierce mobilnej może zająć dzień, ale stwierdzenie, czy graczom to się bardzo podoba w sytuacji, gdy jeszcze mało ludzi pobiera daną grę, może zająć dwa tygodnie.

Podejście eksploracyjne, z tego co widzę ma też swoje organiczenia. Pierwsze dwa, które dostrzegam już teraz to:

  1. Koszt nanoszenia zmian na tyle niski, że uzasadniony wartością biznesową lub korzyścią z redukcji niepewności.
  2. Zdolność do zebrania danych, które zweryfikują hipotezę. Wyobraźmy sobie, że budujemy dom eksploracyjnie. Pomińmy na chwilę kwestie bezpieczeństwa, prawa i kosztów przebudowy. Gdyby postawić hipotezę, że mieszkania w budowanym bloku będą się lepiej sprzedawały, gdy strop będzie wyższy o 10 cm, to mielibyśmy szansę jej weryfikacji dopiero po wielu tygodniach, gdy potencjalni klienci dadzą nam wystarczający feedback na podstawie lektury reklam, witryny internetowej osiedla i rozmów. Zakładam, że nie budowalibyśmy domu na próbę, tylko umieścili informację o wysokości stropu w katalogu. Czas zbierania danych byłby bardzo długi, a jakość responsu być może niska. Przez te kilka tygodni budowa albo by stała, albo szła by naprzód z ryzykiem, że trzeba będzie zmieniać wysokość stropu. 🙂

Podsumowując, wydaje mi się, że rosnąca dynamika zmian oraz niepewność podejmowanych decyzji zachęci firmy do stosowania podejścia eksploracyjnego opartego na weryfikacji hipotez. To oznacza, że w niedługim czasie ktoś wypromuje ideę podejścia eksploracyjnego lub inaczej zwąc podejścia R&D (badawczo-rozwojowe).

Nowa książka – recenzenci poszukiwani

Nowa książka – recenzenci poszukiwani

Poszukuję chętnych do recenzowania i komentowania mojej najnowszej książki, która właśnie zaczyna się pisać.

Ponad dwa lata temu rzuciłem hasło i zaprosiłem do współpracy chętnych z Linkedin przy pisaniu książki W tym szaleństwie jest metoda. Obawiałem się tej pozycji, bo forma, którą wybrałem, była nietypowa. Była to powieść. Dzięki wsparciu kilku osób, które wyraziły chęć współpracy powstała książka dużo lepsza, niż gdybym sam się z nią mierzył. Jeszcze raz im dziękuję za to. Książka na https://lnkd.in/d25cUuh otrzymuje całkiem niezłe oceny, bo średnio 8.4 / 10, więc chyba nieźle nam to wyszło. (więcej…)

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany