Agile Project Management z lotu ptaka – Dlaczego warto wziąć udział w symulacji?

Agile Project Management z lotu ptaka – Dlaczego warto wziąć udział w symulacji?

Wyobraź sobie, że Twój szef zaprasza Cię na spotkanie, na którym dowiadujesz się, że w firmie rusza właśnie nowy projekt. W związku z tym ma dla Ciebie specjalne zadanie. Podczas rozmowy okazuje się, że to właśnie Tobie została powierzona rola zbudowania nowej aplikacji. Aplikacji, która w zamierzeniu ma się stać dumą firmy. Aby oderwać się nieco od pracy oraz korpo-języka przenieśmy naszą historię w okres złotego wieku w dziejach Polski.

Tak oto zaczyna się historia, która otworzyła mi oczy na to jak ewoluuje zespół zwinny, a którą, właśnie teraz z Tobą chciałbym się podzielić.

Prolog

Mamy drugą połowę XVI wieku. W wyniku Unii Lubelskiej Rzeczpospolita Obojga Narodów staje się jednym z największych państw ówczesnej Europy. Wtedy to, również magnat Jan Zamoyski decyduje się na założenie miasta, które, w założeniu, ma rozsławić jego rodzinę na całą Europę.

Sponsor – Zamoyski, postanowił zebrać grupę najlepszych specjalistów, która razem byłaby w stanie sprostać zadaniu wzniesienia miasta, które nie dość, że przyćmi swą okazałością pozostałe, to w dodatku będzie w stanie samo się utrzymać. Jako jednemu z najlepszych inżynierów w powiecie to między innymi Tobie przypada zaszczyt uczestnictwa w tym ambitnym przedsięwzięciu.

Akt 1. Kickoff projektu

Zamoyski widząc ogrom przedsięwzięcia, które zdecydował się sfinansować, postanowił, że projekt prowadzony będzie według zasad, zyskującej wówczas w Europie popularność – adaptacyjnej metodyki prowadzenia projektów.

Bazując na zdobytej wiedzy zdecydował, aby podzielić projekt na etapy. Każdy z nich składał się trzech dziesięciominutowych sprintów (w symulacji każdy miesiąc odpowiadał jednej minucie czasu rzeczywistego). Przed każdym sprintem przewidziana była faza planowania trwająca trzy miesiące. Po ostatnim sprincie w danym etapie miała miejsce pięciominutowa retrospekcja.

Do wykonania zadania zebrany został zespół składający się z

  • trzech inżynierów, których zadaniem było wznoszenie różnego rodzaju dróg, placów, oraz budynków miejskiej infrastruktury.
  • Scrum Mastera, odpowiedzialnego za rozpisywanie zadań oraz dbanie o to, aby ich nie brakło (dbanie o backlog)
  • Product Ownera – do którego należała decyzja o ostatecznym wykończeniu i odbiorze danej budowli
  • Architekta, który czuwał aby miasto trzymało się wyznaczonych reguł architektonicznych
  • Project Managera, który czuwał nad finansami całego przedsięwzięcia

Gdy każdy z nas dowiedział się jaką rolę będzie pełnił w projekcie przystąpiliśmy do etapu zero, czyli zapoznania się z własną rolą oraz z zadaniami pozostałych członków zespołu. Etap ten trwał ok dziesięciu minut. Poświęciliśmy go w większości na wszelkiego rodzaju próby. W zależności od roli danej osoby były to wznoszenie budowli z klocków lego, obliczenia kosztów, czy ustalanie ze sponsorem szczegółów wizji wznoszonego miasta.

Co ciekawe, już na tym etapie pojawia się pierwsza bardzo ważna obserwacja, a mianowicie – kompletnie nie wiedzieliśmy co mamy zrobić, a całą swą uwagę każdy z nas bardzo szybko skierował na zrozumienie jego roli i przygotowanie własnego warsztatu.

Po tej fazie projektu nie mieliśmy jeszcze doświadczeń związanych z procesem budowy miasta. Posiadaliśmy jednak już pewną praktykę, która pozwoliła nam np. na zrobienie wyceny prac inżynierskich.

Kolejna kwestią, która rzuciła mi się w oczy było to, że w trzyosobowym zespole inżynierów spontanicznie wytworzył się model pracy 2+1. Oznaczało to, że dwóch z nas pracowało równocześnie przy konstrukcji taśmowej drobnych, podobnych do siebie budynków. Trzeci z inżynierów zajął się natomiast projektem bardziej skomplikowanego budynku oraz zadaniami pobocznymi.

Akt 2. Specjalizacja

Posiadając minimum wiedzy o projekcie oraz uzbrojeni w szczątkowe doświadczenie nabyte podczas prototypownia przystąpiliśmy do planowania pierwszego etapu. Postanowiliśmy przyjąć jakieś bezpieczne założenia co do wycen. Z szacunków wyszło nam, że we trzech, spokojnie, będziemy w stanie zbudować trzy proste budynki oraz jeden skomplikowany w ciągu sprintu. Takie też zadania uzgodniliśmy i rozpisaliśmy ze Scrum Masterem. Gdy przyklejaliśmy ma ścianę ostatnią kartkę z zadaniem padł sygnał oznaczający, że pora przystąpić do budowy.

W pełni skupieni – poderwaliśmy się do pracy. Co rusz dało się słyszeć – Szybko! Wysyp klocki! Jak to będzie? Podaj podwójny(klocek)! Po dłuższej chwili pierwszy budynek był już gotowy. Jeszcze tylko rzut okiem na zgodność ze schematem – Błąd! Do poprawy.

W efekcie zbudowanie pierwszego budynku, który spełniał wszystkie wymogi odbioru zajęło nam jakieś pięć minut. Niezwłocznie ruszyliśmy z budową kolejnych kamienic. Tym razem czuliśmy, że “jesteśmy w domu” i nic nas nie zaskoczy. Niestety za chwile kolejny zonk – brakło klocków do budowania. Na szczęście bardzo szybko nasz Scrum Master uzupełnił braki i znów mogliśmy przystąpić do pracy.

Po pierwszym sprincie mieliśmy wybudowane pięć mniejszych budynków oraz jeden budynek specjalny. Jednym słowem – szaleństwo! Planując się na kolejny sprint wiedzieliśmy, że damy radę wybudować sześć budynków plus jeden specjalny. Tak zaplanowani przystąpiliśmy do pracy.

Robota szła jak z płatka. Ty razem nie było problemów z rozczytaniem schematów. Nie było tez problemu z materiałem budowlanym, ponieważ Scrum Master nadal czuwał nad uzupełnianiem materiałów. Wynik – dziewięć małych budynków, jeden budynek specjalny i większość dróg. Nasza wydajność wzrosła trzykrotnie w stosunku do tego, co pierwotnie zakładaliśmy.

Pora zacząć ostatni sprint. Znów rytuał – planowanie, sprint, praca. I znów fenomenalny wynik – wybudowaliśmy dziesięć kamienic i dwa budynki specjalne.

Nadeszła pora aby się zatrzymać i przeprowadzić retrospekcję. Cały zespół zebrał się w jednym miejscu. Usiedliśmy i zaczęliśmy dyskutować nad tym, co zadziało, a co nie. Gdzie są problemy oraz jak je rozwiązać. Co ważne bardzo szybko sprowadziliśmy tę dyskusję do poziomu lokalnego zainteresowanych grup. np PM-architekt, Scrum Master – Inżynierowie, czy Product Owner-Inżynier, gdzie jeden drugiemu wytykał problemy w komunikacji. Po rozwiązaniu większości z zaobserwowanych nieporozumień, pełni optymizmu byliśmy gotowi do dalszej pracy.

Akt 2. Rutyna

Kolejny etap projektu w zasadzie zaczął się podobnie. Planowanie, rozpisanie zadań i praca. Nic nie zapowiadało tragedii, która za chwilę miała się wydarzyć. Niestety tuż przed rozpoczęciem drugiego sprintu w wyniku naszego błędu utraciliśmy większość z wybudowanych budynków.

Przygnębienie, smutek, załamanie – to emocje, które towarzyszyły każdemu z nas. Szybko otrząsnęliśmy się z tego co się stało. Zmobilizowani przystąpiliśmy do odbudowy miasta. Wynik? Po trzecim sprincie odbudowaliśmy wszystkie utracone budynki. Mało tego – zrealizowaliśmy również cały pierwotny zakres.

Tak efektywni jeszcze nigdy nie byliśmy. Po raz kolejny poczuliśmy radość i dumę z dobrze wykonanego zadania. Niestety – nie trwało to długo. Tuż przed retrospekcją okazało się, że po podliczeniu budżetu projektu miasto nie jest się w stanie utrzymać. Jego losy stanęły pod znakiem zapytania.

Poruszyliśmy ten wątek na retrospekcji. Zgodnie stwierdziliśmy, że podczas gdy skupiliśmy się byciu coraz to lepszymi w swoim fachu, to równocześnie straciliśmy z oczu cel projektu. Po chwili zastanowienia, odnaleźliśmy przyczynę, wyciągnęliśmy odpowiednie wnioski i byliśmy gotowi do planowania kolejnego etapu.

Akt 3. Nastawienie na cel

Tym razem etap rozpoczęliśmy od zaplanowania prac tak, aby zmaksymalizować zyski i doprowadzić do jak najszybszej rentowności miasta. Był to moment, w którym każdy z nas doskonale znał się już na własnym fachu. Dzięki temu, poza rutynową pracą mogliśmy się skupić na obserwowaniu i reagowaniu na to co się dzieje dookoła.

Na efekty nie trzeba było długo czekać. Pierwszy sprint trzeciego etapu dobiegł końca. Szybkie podliczenie kosztów i zysków – Jesteśmy na plusie! Co prawda nieznacznie na plusie, niemniej zdumiewające jest, to, że wystarczył tylko jeden sprint aby przeorganizować miasto w taki sposób, żeby zaczęło przynosić zyski. Mało tego nasza efektywność również osiągnęła najwyższy poziom w historii.

Epilog

W tym momencie na zegarze wybiła godzina 16:00, co oznaczało, że najwyższy czas podsumować szkolenie. Tym razem jednak zamiast siadać naprzeciw siebie, stanęliśmy dookoła wspólnie wybudowanego miasta. Spoglądając, od czasu do czasu, z tej perspektywy, czuliśmy dumę z osiągniętego efektu. I nie chodziło tu tylko o miasto, ale przede wszystkim o to, jak wiele nauczyliśmy się o mechanizmach, emocjach i zależnościach występujących w projektach zwinnych.

W artykule opisałem jedynie fragment przemyśleń, które wyniosłem ze szkolenia wcielając się tylko w jedną z pięciu ról w projekcie. Jeśli zainteresowała Cię opisana tematyka, to z całą pewnością mogę polecić Ci udział właśnie tego typu symulacjach. Dają Ci one możliwość zaobserwowania procesów zachodzących w prawdziwych projektach w znacznie krótszym czasie. To co normalnie trwa miesiąc, tu możesz zaobserwować w ciągu godziny. Co zrobisz z tą wiedzą – pozostawiam Tobie Drogi Czytelniku.

Brałeś udział w ciekawym szkoleniu? Chcesz się jakoś odnieść do artykułu? Zachęcam gorąco do dyskusji w komentarzach.

Na zakończenie mam jeszcze jedną prośbę.

Jeśli pomogłem Ci rozwiązać Twój problem, to udostępnij proszę ten post. Dzięki temu będę miał okazję trafić do szerszej grupy odbirców. Dziękuję

Leave a Reply

avatar
  Subscribe  
Notify of
Close Menu