Pryncypia w Agile

Dziś zajmiemy się PRYNCYPIAMI, po wprowadzeniu które już nastąpiło. Czym są pryncypia i czemu służą, oto mała "wyliczanka" :

- Wszystkie pryncypia razem pozwalają organizacji dostarczyć rozwiązania o najwyższej wartości (dla biznesu / interesariuszy);

- Pryncypia uwydatniają postawę i sposób myślenia zespołu;

- Ryzykiem są ustępstwa wobec pryncypiów, podważają one filozofię;

- Chcąc uzyskać maksymalną korzyść należy zastosować wszystkie pryncypia.

1 - Bądź skoncentrowany na potrzebie biznesowej 

Decyzje oparte na celu biznesowym :

- należy dostarczać biznesowi tego co potrzebuje dokładnie wtedy kiedy tego potrzebuje

To pryncypium wymaga od zespołu :

- Stworzenia solidnego uzasadnienia biznesowego;

- Głębokiego zrozumienia właściwych priorytetów biznesowych;

- Powodowania zaangażowania i ciągłego sponsorowania ze strony biznesu;

- Zapewnienia dostarczenia Minimalnego Użytecznego Podzbioru (Minimum Useable Subset).

Jest wspierane przez:

- Odpowiednie role biznesowe;

- W fazie Podstaw Produkty biznesowe są uzgodnione;

- Kluczowe techniki - MoSCoW i Stosowanie Okienek Czasu (timeboxing).

2 - Dostarczaj na czas

Wymaga to od zespołu :

- Upartego stosowania Okienek Czasu;
- Skoncentrowania na przyznaniu pierwszeństwa dla biznesu;
- Pewnego dotrzymywania ostatecznych terminów.

Wspierane jest przez :

- Te same kluczowe techniki : MoSCoW i Timeboxing;
- Budowanie reputacji dostarczania na czas i zgodnie z przewidywaniami.

3 - Współpracuj

Wymagania dla zespołu :

- Zaangażowania w odpowiednim czasie odpowiednich zasobów w postaci interesariuszy w trakcie trwania całego projektu;
- Zapewnienia, że decyzje są podejmowane przez członków zespołu do tego upoważnionych, w imieniu tych których reprezentują; 
- Budowy kultury jednego spójnego zespołu;
- Ciągłego aktywnego angażowania przedstawicieli biznesu.

Jest to wspierane przez :

• Role biznesowe;

• Kluczową technikę: Warsztaty Facylitowane (facilitated workshops).


C.D.N. - czyli Ciągle Dalej Niżej ;) - w części następnej...

Podstawy Agile - fundamenty

Czas aby przedstawić podstawy filozofii AGILE, poniżej ikonografika "pięknej wręcz urody" - ma ona na celu przedstawić istotę zarządzania zwinnego AGILE, jej podstawy.

Pamiętać należy, że projekty AGILE muszą być powiązane w sposób jasny i ścisły z celami strategicznymi organizacji. 

Podczas wyboru zarządzania Zwinnego należy kierować się rzeczywistym dostarczaniem (we wczesnej fazie) produktów (korzyści) dla biznesu.

Jakie zatem są warunki sukcesu tego rozwiązania ?

Otóż takie :

1. AKCEPTACJA, faktu że zmiana jest nieunikniona;
2. UPOWAŻNIENIA, są istotne i rozdzielone tylko dla odpowiedniego poziomu zarządczego;
3. Należy DOSTARCZAĆ na czas w planie zgodnie z priorytetem biznesu;
4. CELE BIZNESU, są jasne i klarowne a przede wszystkim rozumiane przez kluczowych interesariuszy projektu;
5. Nieunikniona jest WSPÓŁPRACA, w celu osiągnięcia i zrealizowania zamierzonego rozwiązania;
6. rozwiązanie, którego szukają interesariusze będzie odpowiadać swojemu PRZEZNACZENIU.

Następnym razem zajmiemy się PRYNCYPIAMI...ale tym razem w ujęciu AGILE

Procesy - Zarządzanie Dostarczaniem Produktów / Processes - Product Delivery Management

Jak mówi podręcznik PRINCE2 Proces ten służy do  : 

Zarządzania powiązaniami pomiędzy Kierownikiem Projektu a Kierownikiem/Kierownikami Zespołów przez wprowadzenie formalnych wymagań dotyczących przyjmowania do wykonania, wykonywania i dostarczania wykonanych prac w projekcie.

A zatem jest to główny, "formalny" łącznik pomiędzy "fazami DO" ;)

jaka jest celowość tego procesu :

1. Przekazywanie produktów zgodnie z oczekiwaniami i w zakresie przydzielonych tolerancji;
2. Uzgadnianie i zatwierdzanie wszystkich proc nad produktami;
3. Przekazywanie okresowej  informacji o postępach w kierunku Kierownika Projektu; 
4. Widzimy w nim jasny obraz prac przeznaczonych dla członków zespołu, Kierowników Zespołu w aspektach :

• ZAKRESU,
• KOSZTÓW,
• NAKŁADÓW,
• TERMINÓW.

A Proces Zarządzanie Dostarczaniem Produktów, powinien wyglądać tak :

Zarządzanie Dostarczaniem Produktów w aspekcie Sterowania Etapem

Jak widać na powyższym schemacie - proces ten jest potrzebny Kierownikowi Zespołu, pozwala to jemu spojrzeć na projekt i ustalić punkty styku, plan Zespołu jak również pozwala na weryfikację Grup Zadań.

Tutaj Kierownik Zespołu uzyskuje zatwierdzenia produktów, dowodzi o spełnianiu kryteriów jakości posługując się odpowiednimi (określonymi) metodami dla Grupy Zadań. 

Procesy - Sterowanie Etapem / Processes - Stage Management

To jest "sól tej ziemi" (kolejna ?) - tutaj praca Kierownika Projektu jest zdefiniowana. W procesie Sterowanie Etapem znajduje się najwięcej zadań dla Kierownika, ponieważ ten proces polega na: 
- przydzielaniu pracy i jej monitorowaniu;
- raportowaniu Komitetowi Sterującemu o postępach w projekcie;
- podejmowaniu działań korygujących (mieszczących się w tolerancji);
- tutaj obsługuje się również pojawiające się zagadnienia.

Polecam mój wielkiej urody szkic- w którym widać umiejscowienie opisywanego procesu, wśród innych procesów, takich jak :

• Przygotowanie Projektu;
• Zarządzanie Strategiczne Projektem;
• Zarządzanie Końcem Etapu.

Komu to potrzebne - jak już wspomniałem powyżej - głównie Kierownikowi Projektu, dla codziennego zarządzania etapem. Używany jest do zarządzania każdym etapem realizacyjnym, ale można go użyć dla skomplikowanego etapu inicjowania (gdy mamy do czynienia z bardzo dużym projektem).

Dzięki temu procesowi Kierownik Projektu może kontrolować i definiować pracę Kierowników Zespołów, ustalając przy tym odpowiednie tolerancje. Należy wspomnieć o tym, że Kierownik Zespołu może być jednocześnie Kierownikiem Projektu (jeśli projekt nie jest zbyt skomplikowany), tutaj PRINCE2 zezwala na łączenie ról. Jeśli tak się stanie, Kierownik ma dwie role i odpowiada za wykonanie Grupy Zadań.

...na co mi to...

1. by uniknąć "pełzania zakresu", czyli zmian które nie posiadają kontroli;
2. by umożliwić skupienie się na tym co najważniejsze dla projektu - PRODUKT;
3. kontrola, kontrola, kontrola - zagadnień oraz ryzyk;
4. pomaga w przeglądzie Uzasadnienia Biznesowego;
5. daje zapewnienie tego, że zespół zarządzania projektem skupia się na jego realizacji (projektu) w ramach przydzielonych tolerancji, oraz zgodnie z ustalonymi nakładami osiągając zamierzoną jakość.

Występują w opisanym powyżej procesie następujące działania :

- Zezwalanie na wykonanie Grupy Zadań;

- Przeglądanie stanu Grupy Zadań;

- Odbieranie zakończonych Grup Zadań;

- Przeglądanie stanu etapu;

- Raportowanie Okresowe;

- Wychwytywanie i analizowanie zagadnień i ryzyk;

- Przekazywanie zagadnień i ryzyk

A to wszystko zamyka i spaja Podejmowanie Działań Korygujących...

Procesy - Zarządzanie Końcem Etapu / Processes - End of Stage Management

Oczywiście i ten Proces ma służyć Komitetowi Sterującemu, ale nie tylko. A po cóż on temu Komitetowi, jest on potrzebny z paru powodów :

• Komitet Sterujący musi w jakiś sposób dokonywać przeglądu osiągnięcia celów bieżącego etapu;
• Komitet Sterujący musi w jakiś sposób dokonywać przeglądu uaktualnionego Planu Projektu;
• W jakiś sposób (właśnie dzięki Zarządzaniu Końcem Etapu) Komitet zatwierdza Plan następnego Etapu;
• Jest to "narzędzie" dzięki któremu łatwo jest potwierdzić dalszą zasadność biznesową projektu i tak zwaną "akceptowalność" ( poziom dopuszczalnych ) ryzyk
• Tutaj jest miejsce na stwierdzenie sytuacji nadzwyczajnej i opracowanie Raportu Nadzwyczajnego oraz Planu Nadzwyczajnego, który zatwierdzany jest jak Plan Etapu

Czego jeszcze możemy oczekiwać od Procesu Zarządzanie Końcem Etapu - na pewno przeglądu i uaktualnienia Dokumentacji Inicjowania Projektu.

Mała dygresja  - DIP to :

1. Opisy ról i struktury zespołu zarządzania projektem;
2. Uzasadnienie Biznesowe;
3. Plan Projektu;
4. Strategie Zarządzania (są to strategie zarządzania : Konfiguracją, Jakością, Komunikacją, Ryzykiem);
5. Mechanizmy sterowania Projektem;
6. Opis (definicja) projektu i jego forma realizacji;
7. Opis dostosowania metodyki (bo PRINCE2 jest skalowalny - prawda ;) ?)

Bardzo istotnym jest również zarejestrowanie informacji i doświadczeń w odpowiednich rejestrach - będą one pomocne przy realizacji dalszych etapów ( i możliwe że przy innych projektach).

A po co ten proces Kierownikowi Projektu ? Jest on konieczny dla Uzyskania zezwolenia na rozpoczęcie Kolejnego Etapu.

To czy projekt jest skoncentrowany na osiągnięciu celu i uzasadniony biznesowo, jest każdorazowo potwierdzane właśnie tym procesem. 

Należy również pamiętać,że decyzja o zaniechaniu kontynuowania projektu nie jest porażką.

Tutaj raportowanie zakończenia etapu da nam odpowiedź , czy otrzymamy akceptację Planu Etapu / Planu Nadzwyczajnego - oczywiście raport należy rozesłać wszelakim interesariuszom.

Procesy...Zarządzanie Strategiczne Projektem / Programme Management

Jesteśmy na saaaamej górze...kto by tu nie chciał siedzieć ?

Tak PRINCE2 mówi o tym że Zarządzanie Strategiczne umożliwia przyjęcie odpowiedzialności przez Komitet Sterujący, ale przecież to jest właśnie ta "śmietanka z tortu".

To właśnie dzięki temu procesowi Komitet jest w stanie podjąć kluczowe decyzje, deleguje uprawnienia, takie jak bieżące zarządzanie projektem ( kierownikowi).

Zarządzanie strategiczne polega na weryfikacji i kontroli czy dany projekt pozostaje zasadny, polega również na upewnieniu się że istnieje przepływ informacji między poziomami zarządzania. Dzięki temu procesowi Komitet Sterujący jest w stanie przeglądać korzyści projektowe (czyli CLUE zabawy w projekt;)).

Zarządzanie Strategiczne jako proces rozpoczyna sie zaraz po Przygotowaniu Projektu, i dzięki Tolerancjom Komitet Sterujący jest w stanie działać we wspomnianym procesie, jednocześnie powodując jak najmniejszą ingerencję. 

Nie chodzi o to by Komitet interesował się nawet najmniejszym etapem i cząstką projektu, dzięki delegacji uprawnień i przypisaniu odpowiednich tolerancji, może zająć się innymi projektami - dzięki temu doglądając kilku naraz

Komitet Sterujący, dzięki procesowi Zarządzanie Strategiczne Projektem zezwala na :
- zainicjowanie projektu;
- realizację projektu;
- realizację Planu Etapu, lub Planu Nadzwyczajnego;
- podejmowanie decyzji doraźnej
- zamknięcie projektu

Pryncyp 7 - dmy - Dostosuj Metodykę do warunków projektu / Just adjust your methodology to project environment

To jest, że tak powiem "Last but not Least" z pryncypiów, zarazem mój ulubiony. PRINCE2 nakazuje, by metodykę dostosować do warunków projektu. Zacna to teza, i trafne stwierdzenie. Nie jest to co prawda "unikanie odpowiedzialności" za niepowodzenia projektu, ale raczej "krojenie na miarę potrzeb".

Co bierzemy pod uwagę:

1. Warunki konkretnego projektu - czy chodzi nam o wykształcenie pięknego ABS, czy też o zdobycie medalu mistrzostw świata, tak jak pisałem wcześniej. Warunki są różne projekty są jeszcze bardziej zróżnicowane - chodzi o to by PRINCE2 dostosować, ale dlaczego PRINCE2...może lepiej Agile PM - ten jest jeszcze bardziej "giętki", nie posiada wad w postaci opasłych ram formalnych. pamiętajmy, zawsze możemy użyć metodyki Kaskady (Waterfall), ona sprawdza się w środowiskach nieskomplikowanych z ustalonymi z góry i przewidywalnymi "zmiennymi".

2. Rozmiar Projektu, jasne jest tutaj stanowisko metodologii, ponieważ opisuje ona jak bardzo można "ścisnąć" dokumentację dla mniejszego projektu, które role można łączyć etc. natomiast w przypadku wielkiego projektu, PRINCE2 dostarcza wszelkich instrumentów do kontroli i pomocy w jego realizacji zgodnie z założonym Uzasadnieniem Biznesowym.

3. Złożoność Projektu, metodologia daje nam wybór ilości faz projektu, daje nam możliwość w podziale produktów na produkty cząstkowe. To wszystko umożliwia sprawne zarządzanie nawet najbardziej złożonymi projektami gdy oprzemy się na metodologii.

4. Znaczenie Projektu, wiadomo że dla każdego Kierownika Projektu jego projekt jest najważniejszy, jest nieco inaczej z Komitetem Sterującym, który może brać udział i rozdzielać swój czas pomiędzy inne projekty. Tutaj zarządzanie tolerancjami, odpowiedzi zdefiniowanie ról i obowiązków pomaga zaoszczędzić czas decydentom - definiując zarazem znaczenie konkretnego projektu.

5. Możliwości i Ryzyko, metodyka PRINCE2 w przypadku ryzyka odsyła nas do odrębnego działu -  MOR (Management Of Risk). Gdybyśmy jednak chcieli znać podstawy i pragnęli zabezpieczyć się w podstawowy ( często wystarczający ) sposób, ryzyko jesteśmy w stanie "ogarnąć" również przy pomocy dostępnych w PRINCE2 / Agile metodologii. Każdy projekt ma inne możliwości, myślę że ten truizm jest jasny sam w sobie.

Dodam jeszcze tylko, że metodykę PRINCE2 można stosować w każdej kulturze pod warunkiem spełnienia wszystkich siedmiu pryncypiów.

To w jaki sposób metodykę dostosowano do warunków danego projektu powinno być opisane w DIP, czyli Dokumentacji Inicjowania Projektu.

Produkt / Product – to wszystko przez niego ten cały PRINCE2

No bo gdyby go nie było, to by PRINCE2 nie było… tak mądrym wstępem pragnę zacząć. Czymże jest produkt – niby każdy wie. Wie pan, wie pani…wie społeczeństwo…ale jak się okazuje nie do końca. Koncentracja na produkcie w podejściu PRINCE2 jest bardzo dobrze opisana – jako „clue” całej tej zabawy.

Zależnie od klienta – poziomu odbioru – produktu widzimy specyfikację i określenie produktu finalnego i cząstkowego.  To od klienta zależy, jaki produkt będzie dla niego odpowiedni, od klienta zależą również tolerancje dla niego na różnych zakresach.

Zależnie od kryteriów jakościowych wiemy jak dobrze jest opisany produkt – dzięki temu powinniśmy wiedzieć czy będzie on odpowiadał opisowi produktu końcowego.

To Opis Produktu mówi nam o wszelakich właściwościach wytwarzanego przez nas produktu, niezależnie od tego czy produktem będzie: dokument, decyzja, kubek do kawy, kosiarka, impreza charytatywna, koncert, czy też książka… etc.

Dlaczego jest to tak istotne – jest to zdrowe podejście dla wszelakich metodyk Agile, przyczyną działań powinien być produkt końcowy, choć jak pisałem w Agile PM – akceptuje się czasem inny jego wygląd , dla sprostania „stałym” funkcjom „trójkąta”. To i tak musi to być zawsze produkt akceptowalny przez interesariuszy, oraz ogólnie rzecz biorąc rynek/odbiorcę, czyli klienta (w rozumieniu pejoratywnym).

Jeden z Siedmiu Wspaniałych – Zarządzanie z wykorzystaniem Tolerancji / one of the Seven the Greatest – Management with usage of tolerances.

Po co nam tolerancja, wg. mnie tolerancje są najlepszym, co znajdziemy w metodyce ( lub ewentualnie musimy znaleźć) w Prince2.

Tolerancje pomagają nam w zdefiniowaniu ryzyka, pomagają w określeniu czy jesteśmy już blisko celu, czy ciągle daleko.

W Prince2 uprawnienia przekazywane są razem z tolerancjami dla sześciu wskaźników, pomagających określić stopień wykonania planu. Oczywiście w odpowiednim poziomie. Są to już cytowane.

Dla każdego z nich ustalone tolerancje mówią nam, kiedy powinno się eskalować problem. Przekroczenie tolerancji dla poszczególnych wskaźników powinno ( no chyba że ktoś np. Kierownik Projektu  to „czajnik” – i zaczaja problemy J) skupić uwagę naczelnego Kierownictwa oraz Komitetu Sterującego. W Agile natomiast, tolerancje traktowane są nieco bardziej po macoszemu. W wartości istotnej - takiej jak ZAKRES, możemy mieć nieoczekiwany efekt projektu, ale to właśnie dzięki temu projekt często jest skuteczny i uzasadniony biznesowo.

Tak jak na poniższym trójkącie.

Stałe i Zmienne - czyli "z czym możemy poszaleć" w podejściach do zarządzania projektami

Jest to porównanie zakresów, ale i tolerancji. Widać tutaj bardzo dobrze co można zmienić w podejściu standardowym – KASKADA, a co jest zmienną w podejściu AGILE. 

Etapy / Stages

Etapy etapami, Panie Kierowniku, ale my jesteśmy w czarnej ...

Jak jest "ZAZWYCZAJ"

Panie Kierowniku - tym razem naprawdę...damy radę...

Jak powinno być

Zarządzanie etapowe / Stages and management

Trudno sobie wyobrazić PRINCE2 bez etapów, to dzięki nim dokładnie widać jak ruch w projekcie generuje przyrost – w najgorszym wypadku przyrost kosztów i niespełnionych oczekiwań ;).

Podział projektu na etapy pozwala na zdefiniowanie bardzo ważnego czynnika, czyli tolerancji. To dzięki tolerancji wiemy tak naprawdę czy projekt jest jeszcze w zakresie i w realnej fazie ukończenia go z zyskiem.

Etapy już raz rozrysowałem, na szkicu tej pięknej urody widać dokładnie jak Projekt może zostać podzielony. Oczywiście tutaj wspomina się jedynie o etapach projektu, inne ważne etapy, dzięki którym da się mierzyć postępy to etapy Techniczne.

Etapy techniczne i etapy zarządcze pozwalają na pomiar Postępów. Te z kolei są monitorowane na poziomie – Projektu – Etapu i Grupy Zadań