12

W dzisiejszym wpisie odpowiadam na pytanie, które otrzymałem w ramach Pytajnikowa.

Przypominam, że dla autorów najciekawszych pytań i pomysłów, które pojawią się na moim blogu lub w podcast’cie, czekają fajne nagrody. Tym razem nagroda trafia do Wojtka. Wybrałem książkę Zarządzanie projektami ze Scrumem, ufundowaną przez Wydawnictwo Helion/ OnePress.

Oto pytanie:

Na Twoim blogu można znaleźć naprawdę sporo użytecznych informacji na temat wdrożenia Scruma w organizacjach. Zarówno tych dużych, gdzie potrzebne jest skalowanie i mniejszych które ewoluują, a także tych pracujących z dostawcami. Dzięki, użyteczna lektura!

Mnie szczególnie interesuje spojrzenie na to, jak możemy efektywnie korzystać ze Scruma w firmie, która jest dostawcą usług IT.

Przyjmijmy następujące założenia:

Jesteśmy niewielkim software house’m, który realizuje różne projekty dla zewnętrznych klientów (typowa organizacja projektowa).

Każdy projekt jest inny, ale każdy z klientów ma podobne oczekiwania w chwili, gdy do nas przychodzi.

Klient wysyła do nas zapytanie (listę życzeń) i chciałby w odpowiedzi otrzymać: przybliżony czas realizacji całego projektu i jego koszty.

Nie jest to fanaberia klienta i raczej trudno będzie go przekonać że „my pracujemy inaczej”. 🙂

Klient musi wiedzieć w jakim czasie orientacyjnie zrealizujemy cały projekt ponieważ np. musi zdążyć przed swoim kluczowym sezonem sprzedażowym.

Klient musi znać całościowy koszt realizacji projektu przed podpisaniem umowy, bo chce wiedzieć czy zmieści się w budżecie, a dodatkowo, jest to najczęściej najważniejsze kryterium wyboru dostawcy (niestety tak wygląda rynek).

Tu pojawiają się pytania:

1. Jak podchodzić do wyceny kosztów całego projektu?
2. Jak szacować czas wykonania całego projektu?
3. Jak obejść się bez specyfikacji, która do tej pory stanowiła załącznik naszej umowy z klientem? – klient lubi wiedzieć, za co będzie płacił.
4. Jak zarządzać backlogiem produktu? Mamy jeden zespół scrumowy który realizuje czasami kilka projektów jednocześnie, każdy projekt dla innego zewnętrznego klienta a zatem nie mamy jednego Product Ownera. 🙁

Nie pytam jak podzielić role, bo ten temat był już poruszany w wielu Twoich artykułach i uważam, że jest to opisane wyczerpująco.

Żeby było prościej to zacznę od końca. 😉

Jak zarządzać backlogiem produktu w organizacji projektowej?

Mamy jeden zespół scrumowy który realizuje czasami kilka projektów jednocześnie, każdy projekt dla innego zewnętrznego klienta a zatem nie mamy jednego Product Ownera. 🙁

Stosowanie Scruma w organizacji projektowej, wiąże się ze zmianą dotychczasowego modelu zarządzania projektami w firmie.

Najczęściej jest tak, że tradycyjne organizacje projektowe kręcą się wokół projektów i ich klientów. Co jest w pełni zrozumiałe. Inaczej nie byłyby organizacjami projektowymi. 🙂

Sęk w tym, że Scrum z projektami, które są rozumiane w sposób tradycyjny, ma niewiele wspólnego. Scrum jest metodą organizacji pracy zespołu, który pracuje nad rozwojem określonego produktu, nie projektu.

Tu pojawiają się dwa, bardzo zasadnicze pytania:

• Co jest produktem dla zespołu scrumowego, który pracuje w takiej organizacji? Bo projekt nie zawsze jest produktem, zwłaszcza w dużych firmach.
• Jak zarządzać projektami w takiej organizacji? Do tego, dochodzi jeszcze czasem kwestia zarządzania portfelem i programami.

Organizacje projektowe, które wdrażają Scruma bez zmiany swojego dotychczasowego podejścia do zarządzania projektami, najczęściej robią tak, że tworzą zespoły scrumowe pod konkretny projekt. Projekt się kończy i „kończy się” zespół, który nad nim pracował.

Tak, mniej więcej, wygląda „zwinna” organizacja pracy w wielu współczesnych firmach.

Dużym minusem takiego podejścia jest na pewno tymczasowość zespołów. Zespoły powoływane są pod konkretny projekt, a potem się je rozwiązuje. Podobnie jest z rolą Product Ownera, która też jest „chwilowa”. Product Owner jest dedykowany do konkretnego projektu. Potem się go „zdejmuje”.

Drugim, poważniejszym chyba minusem jest to, że takie podejście, rzadko kiedy przystaje do naszej firmowej rzeczywistości. Nie spotkałem jeszcze firmy, która pracowałaby tylko nad jednym projektem jednocześnie. Bo brakuje ludzi, kompetencji. Bo gonią nas terminy. Bo klient ciśnie. I tak dalej. Powodów jest wiele. Zresztą, z tego co piszesz, to w Twojej firmie jest bardzo podobnie.

Tak więc, chcąc nie chcąc, realizuje się kilka projektów na raz. Efekt jest taki, że zespół scrumowy pracuje z kilkoma Product Ownerami. Oczywiście jest jeden „formalny”, dedykowany do konkretnego projektu. Ale są przecież jeszcze inne projekty, które toczą się równolegle. Nad nimi też pracuje ten sam zespół.

W takim zestawieniu, pojawia się pytanie: kto odpowiada za priorytety? Czyje projekty są ważniejsze, a czyje mniej ważne? Dodatkowym wyzwaniem jest utrzymanie produktu. „Formalny” Product Owner raczej nie garnie się do „wpuszczania” do sprintów zadań utrzymaniowych. Dotyczą one przecież innych projektów, za które on nie odpowiada.

Wcześniej, czy później robi się z tego niezły bajzel, który jest wprost proporcjonalny do rozmiaru firmy.

Skądinąd wiem, że wiele dzisiejszych organizacji projektowych tak właśnie pracuje. Trzeba sobie jednak szczerze powiedzieć, że w takim podejściu, stosowanie Scruma kompletnie mija się z celem. Jest to sztuka dla sztuki – z aktorami, którzy są ofiarami we własnym spektaklu.

Jeden backlog produktu dla całej organizacji

Podejście, które chciałem wam zaproponować, i które przećwiczyłem już w kilku dużych organizacjach projektowych – polega na wprowadzeniu jednego backlogu produktu dla całej organizacji. Tak!

Zapomnijcie na chwilę o wszystkich swoich projektach. Jest jeden wielki worek, do którego wrzucamy wszystkie „życzenia” naszych klientów. Projekty i ich wymagania stanowią jedną wielką uporządkowaną listę zadań, które wcześniej, czy później trafią do zespołów scrumowych w firmie.

I uwaga! W tym podejściu zespoły scrumowe są stałe. Pracują z jednym i tylko jednym, dedykowanym Product Ownerem.

Zespoły nie są powoływane pod konkretny projekt. Prawdę mówiąc, to czy dane „życzenie klienta” jest projektem – nie ma dla nich większego znaczenia.

W tym podejściu, zespoły scrumowe zamieniają się w małe „fabryki produkcyjne”, które każdego dnia podążają w kierunku, wyznaczonym przez Product Ownera.

Jeden backlog, ale kilka widoków

Mimo, że pracujemy nad jednym backlogiem produktu, ma on kilka widoków. Pomyślcie o wielkiej szafie z różnymi szufladami. Każda rola ma tutaj swoją szufladę. Inaczej z backlogu produktu będzie korzystał Product Owner, inaczej kierownik projektu, a jeszcze inaczej szef portfela wszystkich projektów w firmie. Mamy jedną wielką szafę projektów z różnymi szufladami.

To założenie, prowadzi nas do kolejnego. W skład backlogu zespołu scrumowego wchodzi kilka projektów – nie jeden, jak w poprzednim podejściu.

Jak zarządzać backlogiem „wielo-projektowym”?

Mając jeden wspólny backlog produktu dla wszystkich projektów w firmie bardzo ważne jest, żeby:

Porządek (priorytety) w backlogu zespołu scrumowego były pochodną porządku (priorytetów) w backlogu całej firmy.

Tutaj, bardzo zachęcam was do zwizualizowania sobie całego procesu zarządzania popytem w firmie. Krok po kroku. Od momentu zgłoszenia „życzenia” klienta, poprzez fazę formułowania koncepcji biznesowej, jej wycenę, przygotowanie propozycji projektu, jego realizację i zamknięcie.

Spróbujcie sobie wszystko dokładnie rozrysować. Jak by to mogło wyglądać, gdybyśmy mieli jeden backlog produktu z różnymi widokami w firmie?

To jest bardzo ważny obrazek. Ja zwykle przepracowuję go z klientami od tygodnia nawet do jednego miesiąca.

Jeżeli już, mniej więcej będziecie mieli obraz całości, spróbujcie zastanowić się, jak będzie rozkładał się podział odpowiedzialności między poszczególnymi backlogami. Czy jeden Product Owner wystarczy?

W dużych organizacjach, które realizują nawet do kilkudziesięciu projektów w jednym cyklu wdrożeniowym, nigdy nie jest tak, że jeden PO wystarczy. Jeżeli ktoś twierdzi inaczej, nigdy nie miał do czynienia z dużą organizacją projektową.

Oczywiście, ważne jest, żeby zespół scrumowy miał jednego PO i tylko jednego. Natomiast, jeśli chodzi o całą organizację, musicie jednak zaangażować kilka ról do zarządzania backlogiem produktu w całej firmie.

Na czele takiej hierarchii Product Ownerów stoi najczęściej Chief Product Owner (CHPO) – ktoś, kto będzie odpowiadał za całość inicjatyw realizowanych w firmie.

Poniżej przedstawiam wam typowy zakres obowiązków roli CHPO w organizacji projektowej:

• Dystrybucja budżetu dla poszczególnych inicjatyw
• Zatwierdzanie priorytetów i rozstrzyganie konfliktów pomiędzy inicjatywami
• Monitorowanie inicjatyw (budżet, korzyści)
• Realizacja strategii i celów biznesowych

I znowu, w zależności od skali, ta rola może być jednoosobowa lub, co zdarza się częściej, jest to komitet. W skład takiego komitetu wchodzą zwykle reprezentanci biznesu i członkowie zarządu firmy.

CHPO, w zależności od skali, odpowiada za cały portfel (lub kilka portfeli) inicjatyw w firmie.

Niżej od CHPO jest Line Product Owner (LPO). Ta rola przydaje się, jeżeli w waszym backlogu macie wyróżnione obszary funkcjonalne, konkretne produkty, programy projektów itp.

Na samym dole tej układanki mamy Product Ownerów, którzy operacyjnie pracują z zespołami scrumowymi.

Wszystkie role, ze szczegółowym opisem zakresu odpowiedzialności przedstawiłem w eBooku „Zwinny Kapelusz”. Jeśli jeszcze nie macie, zachęcam do pobrania.

Jak podchodzić do wyceny kosztów i szacowania czasu wykonania całego projektu?

Jest takie ogólne przekonanie (bardziej mit chyba), że projektów zwinnych nie da się wyceniać w całości.

Ale to oczywiste przecież, że klient będzie chciał wiedzieć na kiedy coś będzie zrobione. Ja też, jak zlecam Kamilowi i Sebastianowi jakieś zmiany na mojej stronie internetowej, też chcę wiedzieć na kiedy będą gotowe.

Nie wiem, skąd wzięło się takie przekonanie, że w metodach zwinnych nie ma planowania, nie ma dokumentów, nie ma narzędzi i całej masy innych rzeczy, których nie robimy, bo nam się albo nie chce albo nie potrafimy ich robić. A później zasłaniamy się „agile’m” jako świetną wymówką na omijanie reguł gry.

Jednej rzeczy w podejściu do planowania projektów musimy się oduczyć…

… jest nią myślenie długoterminowe. Planowanie w bardzo długim horyzoncie czasowym.

Zauważcie, że tradycyjne projekty najczęściej bardzo długo trwają. Pomijam już fakt różnego rodzaju obsuw i tym podobnych rzeczy. One są też tak planowane. Na dziewięć miesięcy i więcej.

Jeżeli chcecie pracować w Scrumie i nadal być organizacją projektową, takiego myślenia musicie się oduczyć.

Planujemy projekty w krótkich interwałach czasu. Ja bardzo lubię określenie, które wywodzi się z muzyki – kadencja. Oznacza pochód określonych akordów, grany w odpowiedniej kolejności.

Planuj kadencje, a nie cały projekt.

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.

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!

Doskonale zdaję sobie sprawę, że na początku może to być trudne, ale tylko wtedy, stosowanie Scruma w organizacji projektowej może przynieść wam wymierne korzyści.

I teraz, wrócę do Twojego pytania o wycenę kosztów i pracochłonności „całego” projektu – całego, w rozumieniu kilkumiesięcznej kadencji pracy.

Dwa podejścia do zwinnego planowania

Są dwa podejścia do „długoterminowego” planowania pracy w projektach zwinnych.

Pierwsze, to planowanie typu fixed-date. Mamy stałą datę kadencji i chcemy się dowiedzieć, ile do tego czasu zrobimy.

W drugim modelu planowania, określanym jako fixed-scope, jesteśmy już trochę bardziej elastyczni w kwestii terminów. Bardziej niż na konkretnej dacie, zależy nam na dostarczeniu określonej liczby funkcjonalności, uzgodnionych z klientem.

Które podejście wybrać? Biorąc pod uwagę, że mamy jeden backlog produktu, który jest zbiorem wszystkich projektów w firmie, pierwsze podejście dużo bardziej nadaje się do tego typu pracy. Sam też najczęściej go stosuję w organizacjach, z którymi pracuję.

Oba podejścia szczegółowo opisałem w oddzielnym artykule, w całości poświęconym zwinnemu planowaniu.

Jak obejść się bez specyfikacji, która do tej pory stanowiła załącznik naszej umowy z klientem?

W projektach zwinnych, dokument specyfikacji funkcjonalnej, która zazwyczaj stanowi załącznik do umowy z klientem ma trochę inną postać, niż w tradycyjnych projektach.

Na dobrą sprawę jest to zbiór epików i historyjek użytkownika, które tworzą backlog konkretnego projektu klienta. Dokument specyfikacji w tradycyjnej formie (opasły Word, z opisem wszystkich możliwych szczegółów, dotyczących realizowanych funkcjonalności) jest więc zupełnie niepotrzebny.

Ja, u swoich klientów, stosuję najczęściej dwa rozwiązania:

• Całkowita rezygnacja ze specyfikacji, dokumentowanej w tradycyjny sposób (Word). Zamiast tego, załącznikiem do umowy jest konkretna lista epików, ze szczegółami uzgodnionymi podczas sesji pielęgnacyjnych (ang. refinement) z klientem.
• Odchudzenie (!) dokumentacji specyfikacji funkcjonalnej. Wtedy dalej mamy Worda, ale składa się on tylko ze zbioru epików i historyjek użytkownika, które wyznaczają zakres naszego projektu. To rozwiązanie jest jednak redundantne, bo w praktyce polega na przepisaniu epików i historyjek użytkownika i wtłoczenie ich do odpowiedniego szablonu. Ale niektórzy klienci chcą go stosować. Bo na przykład dostawca zewnętrzny nie ma dostępu do narzędzia, w którym trzymane są wszystkie epiki i historyjki użytkownika (np. JIRA).

Dodatkowo, oprócz samej specyfikacji funkcjonalnej warto pomyśleć o liście wszystkich artefaktów, które są dostarczane w ramach całego procesu projektowego i wytwórczego. Sama specyfikacja funkcjonalna nie jest przecież jedynym dokumentem, który dostarczamy w tradycyjnych projektach. Są jeszcze inne artefakty, takie jak chociażby: analiza korzyści projektu, opis architektury, opis rozwiązań informatycznych, dokumentacja użytkownika, plany testów, scenariusze testowe, raporty z testów. Wbrew pozorom, jest tego całkiem sporo.

I jeszcze jedna rzecz, o którą nie zapytałeś, ale o niej wspomnę 😉

Kontrakty agile

Oprócz samej specyfikacji funkcjonalnej i wymaganych dokumentów, warto jeszcze pomyśleć o odpowiedniej adaptacji samego kontraktu z klientem.

W takim podejściu, tradycyjne kontrakty projektowe, nie mają większego sensu i trzeba je odpowiednio przepracować i dostosować do specyfiki pracy w projektach zwinnych.

Można to oczywiście zrobić samemu. Ja jednak, gorąco polecam skorzystanie z porad doświadczonego prawnika, który na co dzień ma do czynienia z umowami IT w projektach agile. Zaoszczędzicie sobie w ten sposób sporo cennego czasu i pieniędzy.

Większość działów prawnych w firmach IT, wciąż nie ma wystarczającej wiedzy, żeby takie umowy przygotowywać. Powoli zaczyna się to zmieniać, ale to jeszcze długi proces.