16

Organizacje, które wdrażają Scruma można podzielić na dwa rodzaje: te, w których wszystkie rozwijane produkty są częścią jakiegoś projektu oraz te, dla których pojęcie „projektu” nie ma żadnego znaczenia. Bo organizacje te, używają zupełnie innych standardów do zarządzania swoją pracą – innych, niż standardy projektowe.

W dzisiejszym wpisie opowiem wam jak zabrać się za wdrażanie Scruma w organizacjach, w których projekty jednak występują. Przygotowałem dla was siedem praktycznych wskazówek, które pomogą wam takie wdrożenie skutecznie przeprowadzić we własnej firmie.

No to zaczynamy!

Scrum nie jest metodą zarządzania projektami

Zanim przejdziemy do konkretów, warto sobie uświadomić, że w Scrumie pojęcie projektu, w tradycyjnym tego słowa znaczeniu, w ogóle nie występuje.

Scrum jest metodą organizacji pracy zespołu, który pracuje nad rozwojem określonego produktu.

To natomiast, czy dany produkt rozwijany jest w ramach konkretnego projektu, czy nie – z punktu widzenia Scruma, nie ma żadnego znaczenia.

To oczywiście nie oznacza, że metody tej nie da się stosować w organizacji projektowej. Da się, ale wymaga to odpowiedniego dopasowania procesu zarządzania projektami do nowej, zwinnej filozofii pracy.

Inaczej, stosowanie Scruma będzie jałowe, nie wniesie żadnej dodatkowej wartości.

Czym jest projekt?

Istnieje przynajmniej kilka różnych definicji projektu – w zależności od organizacji, która je rozwija i utrzymuje (np. PMI, IPMA, PRINCE2, CMMI)

Mimo, iż każda z nich różni się od siebie, wszystkie zwracają uwagę na to, że projekt jest przedsięwzięciem ograniczonym w czasie, a więc ma wcześniej ustalony początek i koniec, posiada określony cel (dostarczyć unikatowy produkt) i zakres.

W Scrumie nic z tych rzeczy nie występuje. Mamy jedynie interdyscyplinarny zespół, który non-stop, w trybie ciągłym przekształca życzenia klienta na gotowe produkty.

I dla członków Zespołu Scrumowego, nie ma absolutnie żadnego znaczenia, czy to, co robią jest częścią jakiegoś projektu w firmie, czy nie. Po prostu. Chcą jak najszybciej dostarczyć gotowy, wartościowy produkt do klienta. To wszystko.

W Scrumie nie ma też żadnej analizy korzyści przed startem działań, tak jak ma to miejsce w przypadku realizacji tradycyjnych projektów. Tu, korzyść rozwijanego produktu jest na bieżąco oceniana i weryfikowana – ze sprintu na sprint. Na koniec każdej iteracji badamy przydatność tego, co dostarczyliśmy.

Jak wdrożyć Scruma w organizacji projektowej – 7 praktycznych wskazówek

Jak w takim razie wdrożyć Sacrum w organizacji projektowej? Na co zwrócić uwagę? Z czym trzeba się zmierzyć?

Poniżej zebrałem siedem, moim zdaniem najważniejszych wskazówek, które pomogą wam wdrożyć Scruma w waszych projektach.

1. Traktuj Scruma i proces zarządzania projektami jako naczynia połączone.

Naczynia połączone, to takie dwa naczynia, w których ciecz może swobodnie przepływać – między jednym, a drugim. Jest to możliwe właśnie poprzez połączenie naczyń (najczęściej w dnie każdego z nich).

Proces zarządzania projektami nie działa w próżni. Ścieżki projektowej nie da się tak po prostu oddzielić od tego, co robicie w Scrumie. Zauważcie, że projekty, też są pewnego rodzaju „narzędziem” do dostarczania produktów w firmie. Podobnie zresztą jak Scrum.

Połączenie Scruma z określonymi standardami zarządzania projektami w firmie ma sens tylko wtedy, kiedy te dwa światy potraktujecie jako naczynia połączone.

Popatrzcie na rysunek poniżej. U góry mamy typowe fazy realizacji projektu, które przebiegają sekwencyjnie. Na dole rysunku biegną kolejne sprinty. Jak łatwo zauważyć, poszczególne aktywności, typowe dla realizacji projektu są częścią zakresu prac wykonywanych w sprincie.

W praktyce, najczęściej wygląda to tak, że na początku, zanim jeszcze zostanie formalnie uruchomiony projekt, w głowie Właściciela Produktu rodzą się mniej lub bardziej konkretne pomysły, które najpierw trafiają do „zeszytu” – Backlogu Produktu.

W tym czasie, odbywają się też pierwsze sesje pielęgnacyjne(ang. refinement), podczas których Właściciel Produktu wspólnie z Zespołem Deweloperskim omawia możliwe rozwiązania i formułuje pierwsze wymagania.

W pewnym momencie, jeżeli już mniej więcej wiemy, co chcemy osiągnąć – zbiór pomysłów zostaje formalnie przedstawiony jako propozycja nowego projektu do realizacji.

I tu wszystko się zaczyna. Zbiór pomysłów, zwykle wyrażony w formie epików, uruchamia formalną ścieżkę projektową. Wtedy też, najczęściej pojawia się odpowiednie zgłoszenie w narzędziu do zarządzania projektami w firmie. Do inicjatywy zostaje przydzielony unikalny numer oraz „opiekun”, w postaci kierownika projektu.

Od tego momentu świat zarządzania projektami łączy się ze światem Scruma.

2. Planuj kadencje, a nie cały projekt.

W tradycyjnych projektach mamy najczęściej do czynienia z bardzo długim okresem planowania. Na początku zbieramy wymagania, ustalamy dokładny zakres projektu, potem walczymy o budżet, i w końcu powstaje harmonogram, który obejmuje zakres prac rozpisany na okres dwunastu miesięcy.

Myśląc o wdrożeniu Scruma w organizacji projektowej, pierwszą rzeczą, którą musicie zrobić, to oduczyć się długoterminowego planowania.

W Scrumie planujemy prace w krótkich cyklach wytwórczych. Takie podejście jest jak najbardziej uzasadnione. Im krótszy okres planowania, tym szybciej możemy reagować na zmieniające się warunki otoczenia.

To, co zaplanowaliście dzisiaj za dwanaście miesięcy może okazać się już nieaktualne. Bo konkurencja zrobi to szybciej. Albo zmienią się gusta i potrzeby naszych klientów. Dlatego planujemy krótkoterminowo!

To, co normalnie zaplanowalibyśmy na dwanaście miesięcy, dzielimy na krótsze cykle wytwórcze. Ja, w swoich projektach najczęściej stosuję trzymiesięczne cykle planistyczne.

I taki okres obiegowo nazywam kadencją pracy. Kadencja, to pojęcie, które pochodzi ze świata muzyki. Oznacza pochód określonych akordów, grany w odpowiedniej kolejności.

W naszym przypadku, akordami są sprinty. Każda kadencja składa się z kilku sprintów. Jeżeli przyjmiemy, że długość każdego sprintu wynosi dwa tygodnie, w trzymiesięcznej kadencji zrobimy sześć sprintów.

U was może to oczywiście wyglądać zupełnie inaczej. Ważne jest, żeby nauczyć się myśleć o planowaniu projektu w kontekście krótkich interwałów pracy – kadencji.

3. Wprowadź jeden Backlog Produktu dla wszystkich projektów.

Pomysł, żeby mieć jeden Backlog Produktu dla wszystkich projektów w firmie jest jak najbardziej spójny z tym, jak zarządzamy projektami w naszych organizacjach.

W większości organizacji, całkiem spora liczba projektów jest ze sobą, w mniejszym lub większym stopniu, powiązana. Często jest tak, że kilka projektów, mimo odrębnych budżetów dostarcza jeden wspólny produkt. Mówimy wtedy o programie, na który składa się kilka równolegle prowadzonych przedsięwzięć.

Ale to nie wszystko. Może też być tak, że produkty, dostarczane w ramach konkretnych programów i projektów składają się na realizację wyższego celu strategicznego w firmie. Wtedy mówimy, że ta grupa programów i projektów tworzy portfel.

Tak więc, docelowo, mamy trzy poziomy zarządzania projektami w firmie. Poziom portfela, programu i pojedynczego projektu.

I każdy z tych poziomów powinien być odpowiednio „widoczny” w Backlogu Produktu.

Myśląc o backlogu portfela, programów i projektów, cały czas trzeba mieć w tyle głowy, że to jest ciągle jeden i ten sam Backlog Produktu. Mimo różnych widoków.

Portfel, Program, czy Projekt, to tylko pewne atrybuty, które nadajemy określonym elementom naszego Backlogu Produktu. Robimy to głównie po to, żeby było nimi łatwiej zarządzać.

Taki Backlog przypomina wielką szafę z szufladami. Każda szuflada ma przyklejoną etykietę, która informuje nas, jaki typ rzeczy w niej przechowujemy. W jednej szufladzie będziemy przechowywać bieliznę, w innej szaliki, czy skarpetki. Ale ciągle jest to jedna szafa, w której mieści się cała nasza garderoba. Podobnie jest z jednym Backlogiem Produtku i projektami.

4. Powołaj Zespół Product Ownerów w firmie.

Do zarządzania takim złożonym Backlogiem Produktu, nie wystarczy jeden Właściciel Produktu. Każdym z odrębnych poziomów zarządzania projektem – portfela, programu, czy projektu wymaga wprowadzenia odrębnej roli.

Scrum mówi tylko o jednej roli – Właściciela Produktu, którym powinna być jedna osoba, nie komitet.

Jest to jak najbardziej słuszny postulat i zawsze bardzo mocno się przy nim upieram, prowadząc wdrożenia u klientów.

Jednak w przypadku dużych organizacji, ta reguła ma sens, ale tylko w przypadku danego atrybutu Backlogu Produktu.

Innymi słowy, Zespół Deweloperski powinien mieć jedną pojedynczą osobę, która będzie odpowiedzialna z rozwój produktu. Program powinien mieć jedną, pojedynczą osobę, która będzie odpowiedzialna za realizację celów programu. I konsekwentnie, portfel powinien mieć jedną, pojedynczą osobę, która będzie odpowiedzialna za wizje i cele strategiczne, realizowanych inicjatyw.

Takie podejście, siłą rzeczy wiąże się ze stworzeniem specjalnego zespołu, który na różnych poziomach będzie odpowiedzialny za rozwój produktu w firmie. Zwykle, roboczo nazywam go Zespołem Właścicieli Produktu.

Taki zespół ma zwykle trój-poziomową strukturę: Głównego Właściciela Produktu (ang. Chief Product Owner, w skrócie CHPO), Właściciela Liniowego (ang. Line Product Owner, w skrócie LPO) oraz Właściciela Produktu (ang. Product Owner, w skrócie PO).

Każda z ról odpowiada innemu poziomowi zarządzania projektem. CHPO odpowiada za portfel, LPO za program, a PO za konkretny projekt lub grupę projektów, realizowanych wspólnie z Zespołem Deweloperskim.

5. Określ jak wygląda Backlogu Produktu, rozwijany przez Zespół Deweloperski.

Stosując Scruma w organizacjach projektowych, trzeba liczyć się z tym, że produkty, które są rozwijane i dostarczane w sprintach, zawsze w jakiś sposób będą powiązane z projektami w firmie.

Najbardziej pożądana, z punktu widzenia procesu zarządzania projektami, sytuacja występuje wtedy, gdy Zespół Deweloperski implementuje wymagania, związane tylko z jednym projektem tak, jak przedstawia to rysunek poniżej

Niestety, bardzo często sytuacja jest taka, że produkt, który rozwijamy ma powiązania z kilkoma projektami w firmie. Takie podejście oczywiście w żaden sposób nie wpływa na prace Zespołu Deweloperskiego, ale ma ogromne znaczenie z punktu widzenia koordynacji i monitorowania prac projektowych. Pojawia się całkiem spora liczba zależności, a projekty najczęściej zarządzane są przez różnych kierowników projektu. I dużo trudniej jest nad wszystkim zapanować, niż w pierwszym przypadku.

Dlatego jeśli tylko możecie, zróbcie wszystko, żeby Backlog Produktu, który rozwija Zespół Deweloperski, był powiązany tylko z jednym projektem. To znacznie ułatwi wam życie.

6. Zdefiniuj listę wymaganych artefaktów w projekcie.

Tradycyjne podejście do zarządzania projektami odzwierciedla filozofię pracy w modelu kaskadowym, sekwencyjnym. Łatwo to zauważyć, przyglądając się artefaktom, wymaganym w poszczególnych fazach realizacji projektu.

Z punktu widzenia Scruma, dostarczanie nie wszystkich artefaktów projektowych ma sens.

Stąd, żeby jakoś pożenić te dwa światy, musicie dobrze zastanowić się, które artefakty wnoszą jakąś wartość do tego, co robicie, a z których możecie spokojnie zrezygnować.

Ćwiczenie:

Zachęcam was do przeprowadzenia krótkiego ćwiczenia, które pomoże wam ustalić, które artefakty projektowe są wam faktycznie potrzebne, a które możecie sobie spokojnie darować.

Krok 1.

Na dużej, najlepiej suchościeralnej tablicy narysujcie aktualny przebieg procesu zarządzania projektami w waszej firmie. Ważne jest, żeby wasz rysunek odzwierciedlał stan obecny, a nie to jak chcielibyście, żeby było. Następnie, na każdym etapie projektu wypiszcie (najlepiej innym kolorem), wszystkie artefakty projektowe, które są z nimi związane. I znowu, skupiamy się na tym, jak wygląda to teraz. Przyszłość na razie nas nie interesuje.

Krok 2.

W kolejnym kroku zastanawiamy się, które artefakty w naszym procesie, są nam, z punktu widzenia Scruma, faktycznie potrzebne. Nie róbcie tego zbyt pochopnie. Zachęcam was do dokładnego przeanalizowania każdego artefaktu, który dostarczacie. Cały czas myślcie, czy jego pojawienie się niesie ze sobą jakąś wartość, czy faktycznie jest potrzebny.

Krok 3.

Jak już mniej więcej wiecie, co jest wam potrzebne, a co nie, zastanówcie się, jak wprowadzić zmiany w życie. Przygotujcie plan działania.

To, co przed chwilą opisałem jest jednym z moich ulubionych narzędzi, które stosuję przy projektach wdrożeniowych u klientów. Pochodzi z filozofii lean i określane jest jako „mapowanie strumienia wartości” (ang. value stream mapping).

Mapowanie strumienia wartości, to narzędzie, którego możecie używać nie tylko do sporządzenia listy najbardziej wartościowych artefaktów w projekcie, ale także do analizy jakiegokolwiek procesu w firmie, który chcecie usprawnić.

Poniżej przedstawiam wam listę artefaktów, która powstała podczas wdrożenia Scruma u jednego z moich klientów. Była to duża organizacja projektowa, która stosowała bardzo zaawansowane podejście do zarządzania projektami.

Co zostawiliśmy:

• Analizę korzyści zgłaszanego projektu. W momencie zgłaszania nowej inicjatywy, Właściciel Produktu wskazywał na listę planowanych korzyści, związanych z realizacją określonego zbiorów epików, które stanowiły wstępny zakres prac w projekcie. Ten krok miał dla nas wartość.
• Kartę projektu. Był to dokument, który zawierał takie informacje jak: krótki opis projektu, cele, które ma osiągnąć, najważniejsze założenia, budżet projektu, główne kamienie milowe i ryzyka, a także powiązania z innymi projektami.
• Budżet. Tak na dobrą sprawę, nie ma znaczenia, czy stosujecie podejście projektowe, czy nie. Także w Scrumie kasa na realizację prac w poszczególnych sprintach jest potrzebna. My zrobiliśmy tak, że Właściciel Produktu razem z Kierownikiem Projektu przygotowywali odpowiedni plan wydatków w projekcie. Przy każdym nowym przedsięwzięciu powstawał szczegółowy plan kosztów.
• Rejestr ryzyk. Identyfikacja i analiza ryzyk projektowych odbywała się przez cały czas trwania projektu. Tak na marginesie, prowadzenie Backlogu Ryzyk jest praktyką, którą niektóre Zespoły Scrumowe stosują bez względu na to, czy stosują określone standardy zarządzania projektami, czy nie.
• Raport stanu prac w projekcie. Raport kierownika projektu zawierał następujące informacje: wykres spalania prac w kadencji (ang. cadence burndown chart), raport ryzyka, kosztów i podstawowe metryki jakości, śledzone w projekcie (np. gęstość błędów).
• Finalne rozliczenie projektu. Po zakończeniu projektu, kierownik projektu razem z Właścicielem Produktu formalnie rozliczali wszystkie koszty poniesione w projekcie.

Co wyrzuciliśmy lub zmieniliśmy:

• Harmonogram projektu. Harmonogram został, ale zawierał tylko działania krótkoterminowe – okres trzech miesięcy (jedna kadencja). W przypadku większych projektów, mieliśmy planowaną listę celów do osiągnięcia w poszczególnych kadencjach, bez bliżej określonych szczegółów.
• Specyfikację funkcjonalną. Tradycyjne podejście do zarządzania projektami zakłada, że kompletna specyfikacja funkcjonalna powstaje przed startem projektu. W Scrumie powstanie takiego dokumentu nie ma sensu, bo w metodzie tej praca nad rozwojem produktu ma charakter „odkrywkowy”. Na początku znamy tylko niewielką pulę wymagań, które ze sprintu na sprint mogą się zmieniać. Na koniec każdego sprintu dostarczamy potencjalnie gotowy do wdrożenia produkt, który jest dla nas cennym źródłem informacji o dalszym kierunku prac nad produktem. W ten sposób, Backlog Produktu jest w ciągłym ruchu. Stąd, nie było sensu utrzymywać dokumentu, który musielibyśmy ciągle zmieniać i aktualizować. Byłaby to sztuka dla sztuki. Dla nas, pewną namiastką specyfikacji funkcjonalnej był po prostu zbiór epików, które Właściciel Produktu chciał zrealizować w pierwszej kadencji.
• Dokument opisujący rozwiązania techniczne. Podobnie, jak w przypadku specyfikacji funkcjonalnej, zrobiliśmy z dokumentem, opisującym rozwiązania techniczne w projekcie. Pracując w Scrumie, nie da się opisać wszystkich możliwych rozwiązań informatycznych przed startem projektu. Powstają ewolucyjnie, w trakcie kolejnych sprintów. W tym wypadku, jedyną sensowną rzecz, którą możecie zrobić, jest prowadzenie dokumentacji technicznej iteracyjnie. Tak było w naszym przypadku. W każdym kolejnym sprincie Zespół Deweloperski opisywał rozwiązania, które zastosował przy implementacji tej, czy innej historyjki w sprincie. Całość lądowała w specjalnym folderze na WIKI, który był sprzęgnięty z narzędziem JIRA.
• Strukturę podziału pracy, czyli WBS projektu. Utrzymywanie WBS-a w Scrumie mija się z celem. Zastępuje go Backlog Produktu oraz Backlog Sprintu.
• Podsumowanie projektu. Tutaj wprowadziliśmy małą zmianę. Tradycyjne spotkanie na zakończenie projektu „Best Practices & Lessons Learned”, podczas którego członkowie zespołu projektowego omawiali listę dobrych doświadczeń i praktyk w projekcie, zastąpiliśmy retrospektywą projektu.

7. Zdefiniuj wszystkie role, które biorą udział w projekcie

Scrum mówi tylko o trzech rolach: Właściciela Produktu, Scrum Mastera i Zespołu Deweloperskiego. Słowem jednak nie wspomina o tradycyjnych rolach, które występują w projektach.

Co z nimi zrobić? Przecież, jeżeli zaczniecie wdrażać Scruma w firmie, te role cudownie nie wyparują.

Jedno jest pewne. Nie możecie przejść wobec tego faktu obojętnie. Ja zwykle organizuję jednodniowy, czasem dwudniowy warsztat w firmie, w trakcie którego każda rola biorąca udział w procesie jest na nowo, dokładnie definiowana.

Jak się za to zabrać? Przygotowałem dla was krótkiego ebooka, w którym dokładnie opisałem jak takie warsztaty zorganizować oraz umieściłem przykłady gotowych opisów ról, które możecie wykorzystać we własnych projektach.

Ebook jest całkowicie bezpłatny. Wystarczy tylko zapisać się na mojego newslettera.

Poniżej przedstawiam rysunek, który przedstawia konstelację ról u jednego z moich projektów wdrożeniowych u klienta.

Rysunek przedstawia trzy różne poziomy ról, które wyróżniliśmy w firmie. Na samym dole zostały umieszczone role, które wspierają codzienne funkcjonowanie wszystkich ról w organizacji. W grupie tej znaleźli się agile coachowie (zespół, z którym pracowałem) oraz nawigatorzy zmiany – osoby, które koordynowały projekt wdrożenia Scruma po stronie klienta.

Ale to nie wszystko. Drugi i trzeci poziom zawiera mix ról zarówno tradycyjnych jak i scrumowych.

Zauważcie też, że takich ról jak: rola kierownika projektu, kierownika liniowego, sponsora projektu, architekta korporacyjnego, pojawią się także role zupełnie nowe. Mam tutaj na myśli rolę: Liniowego i Głównego Właściciela Produktu.

Dla każdej z tych ról powstał szczegółowy zakres obowiązków, który został odpowiednio udokumentowany w firmie.

Na koniec

Jak widzicie całkiem sporo elementów z tradycyjnego podejścia do zarządzania projektami zostało zachowanych.

Fazy realizacji projektu pozostały niezmienione. Mamy portfel, programy i projekty. Jest rola kierownika projektu. Zostawiliśmy sporo tradycyjnych artefaktów.

Ale jest też wiele zmian, które były konieczne, żeby filozofia zwinności mogła na trwałe się zadomowić w organizacji. Bez nich stosowanie Scruma byłoby tylko sztuką dla sztuki, która niewiele wnosi do życia projektów w firmie.

Jeżeli zdecydujecie się na wdrożenie Scruma w organizacji projektowej zawsze musicie liczyć się z tym, że czeka was sporo prac adaptacyjnych.

W dużych organizacjach po prostu nie da się tego uniknąć.

Bo każda organizacja ma swoje dziedzictwo, które przy takim wdrożeniu trzeba uszanować. Przez „dziedzictwo” rozumiem cały świat procesów, standardów i procedur, które na co dzień stosujecie. Także to, jak ze sobą rozmawiacie, jakich macie liderów i jak zarządzacie. Jakich używacie narzędzi i metryk. To wszystko tworzy waszą organizację.

I nie da się tego wszystkiego, tak po prostu, wyrzucić, żeby mieć „miejsce” na wdrażanie Scruma.

Wdrożenie Scruma w organizacji projektowej zawsze będzie wdrożeniem-w-kontekście. Tym kontekstem jest wasza organizacja.