1

Mariusz Chrapko

Scrumowo-pytajnikowo

2015

MARIUSZ CHRAPKO

2

SCRUMOWO-PYTAJNIKOWO

3

WSTĘP

W listopadzie 2014 r. nastąpiła premiera II wydania mojej książki „Scrum.O zwinnym zarządzaniu projektami”. Z tej okazji wspólnie z wydawnictwemHelion zorganizowaliśmy facebookowy konkurs, w ramach którego czytelnicyzadawali mi różne pytania związane ze stosowaniem Scruma w firmie. Spo-śród nadesłanych wątpliwości wybraliśmy te, które naszym zdaniem są najcie-kawsze. W ten sposób powstała ta elektroniczna książka.

„Scrumowo-pytajnikowo” składa się z siedmiu niezależnych od siebie czę-ści. Każda z nich dotyka nieco innego tematu w Scrumie. Pytanie, które naj-bardziej nam się podobało i wygrało konkurs, umieściliśmy jako pierwsze.Dotyczy tego, jak nieszablonowo można myśleć o Scrumie.

Bardzo dziękuję wszystkim osobom za nadesłane pytania. Mam nadzieję,że lektura tego e-booka pomoże Wam zwinnie zarządzać projektami w firmiei będzie miała pozytywny wpływ na role, które w nich odgrywacie.

Mariusz ChrapkoBlog: MariuszChrapko.com

MARIUSZ CHRAPKO

4

Oceniaj ludzi po pytaniach, a nie po odpowiedziach.

Wolter, filozof

SCRUMOWO-PYTAJNIKOWO

5

1. JAKA METAFORA NAJLEPIEJ OPISUJE SCRUMA?

To będzie nietypowe pytanie, ale dla mnie wielce istotne.Bardzo często gdy przedstawiam laikom jakieś zagadnienia związane

zarządzaniem, posługuję się metaforami lub polecam książki,które w nieszablonowy, ale zarazem bardzo przystępny sposób pokazują trudnezagadnienia (np. „Kto zjadł mój ser” czy „Szkoła managerów Kubusia Puchatka”)

stąd moje pytanie: jaka metafora idealnie opisuje, czym jest Scrum?

Filip Olender

Faktycznie, pytanie jest nietypowe, ale fajnie, że je zadałeś. Metafory to jedenz najbardziej twórczych elementów naszego języka, także w zarządzaniu. Tako metaforach pisał Arystoteles:

„Metafora jest to przeniesienie nazwy jednej rzeczy na in-ną: z rodzaju na gatunek, z gatunku na rodzaj, z jednegogatunku na inny, lub też przeniesienie nazwy z jakiejś rze-czy na inną na zasadzie analogii”.

Odpowiadając na Twoje pytanie, chyba nie mam jednej metafory, która ideal-nie oddaje pracę w Scrumie. Z pewnością jest ich kilka. Każda pokazuje trochęinny aspekt pracy tą metodą. Poniżej lista tych, które najbardziej lubię.

Gra w piłkęTo jedna z metafor, którą posługuję się najczęściej. Scrum nie jest metodyką za-rządzania projektami, taką jak np. PRINCE2 czy PMI. Scrum nie opisuje stan-dardów czy konkretnych rozwiązań, z których moglibyśmy skorzystać pod-czas realizacji prowadzonych przedsięwzięć. Jest raczej modelem działania.Dostarcza zespołom projektowym jedynie pewnej struktury (ang. framework)

MARIUSZ CHRAPKO

6

— konkretnych praktyk i zasad, które wyznaczają ramy dalszych aktywności.Jest to zupełnie wyjątkowy układ, który ze swej natury pozostaje bardzootwarty. Stąd praca zespołów w Scrumie przypomina trochę grę w piłką noż-ną. Zasady gry, opracowane przez International Football Association Board (IFAB),są proste i jasno określone. Ale jak grać, żeby wygrać? O tym zasady już nic niemówią. Bo sukces meczu zawsze zależy od zespołu. Przepisy gry w piłkę wy-znaczają tylko ramy działania — warunki brzegowe, w obrębie których zespółmoże się poruszać. Cały czas mam świeżo w pamięci niezapomniany meczw półfinale Ligi Mistrzów, w którym Borussia Dortmund wygrała z RealemMadryt 4:1. Jak może pamiętasz, cztery bramki dla niemieckiego zespołu zdo-był wtedy Robert Lewandowski. Po meczu jeden z piłkarzy Borussii, NevenSubotić, biorąc na siebie winę za stratę jedynej w tym pojedynku bramki, po-wiedział:

Nie wygrałem mojego pojedynku z Luką Modriciem, więcjestem współodpowiedzialny za straconą bramkę. Zasadajest taka, że jeśli ktoś popełnił błąd, to jest to błąd zespołu,a nie jednego zawodnika. Tak samo z czterema bramkami,które strzeliliśmy. Lewandowski ich nie zdobył, tylkozespół.

W sportach zespołowych to zespół wygrywa mecz, a nie jeden zawodnik. In-dywidualne umiejętności zawodników i osobowość też są istotne. Jednakostatecznie to zespół, jako całość, stwarza konkretne sytuacje, które „torują”drogę do strzelania bramek. Taktyka, formacja, umiejętność wykorzystania sła-bości przeciwnika („tak się gra, jak przeciwnik pozwala”), reagowanie nazmieniające się otoczenie — wszystko to stanowi zbiór tych szczególnych oko-liczności, które decydują o wygranej w meczu. Podobnie jest w Scrumie.

LustroInna metafora, którą również bardzo lubię, to porównanie do lustra. Obrazujeona, co się dzieje, gdy organizacja zdecyduje się na wdrożenie Scruma. Wy-starczy, że staniesz przed lustrem i wszystko wiesz o swoim wyglądzie. Lustranie da się oszukać. Patrzysz i widzisz, że jesteś za gruby albo że źle dobrałeśkrawat lub masz za krótkie spodnie. Lustro nie kłamie. Podobnie jest, gdy de-cydujesz się na wdrożenie Scruma w firmie. Nie spodziewaj się, że nagle,

SCRUMOWO-PYTAJNIKOWO

7

niczym za dotknięciem czarodziejskiej różdżki, Twoja firma się zmieni, nastąpicudowne uzdrowienie. Scrum przypomina wielkie lustro, które boleśnie obna-ża wszystkie niedociągnięcia w Twojej organizacji: słabe procesy, „wąskie gar-dła”, niewydajne procesy decyzyjne, skostniałą strukturę. Lustro jest bardzoważne, żeby coś zmienić. Jeśli nie masz lustra, wielu rzeczy nie jesteś świado-my. Nie potrafisz ocenić swojej bieżącej sytuacji.

TeściowaInna metafora, która może Ci się spodobać, to porównanie do teściowej. Po razpierwszy użył jej jeden ze współtwórców Scruma Ken Schwaber. Znaczeniowojest bardzo podobna do metafory lustra. Wdrożenie Scruma w organizacjiprzypomina wizytę teściowej. Wyobraź sobie, że jest weekend. O dziesiątej ra-no musisz pojechać na dworzec, żeby odebrać teściową, która przyjeżdża nakilka dni. Ty i żona długo przekładaliście tę wizytę, ale w końcu jest. Kochanamamusia! Ale oto mija kilka godzin i cały czar tej wizyty pryska jak bańka my-dlana.

— A tych naczyń nie można było umyć od razu po obiedzie, po co z tymczekać do kolacji?! — pyta mamusia z ogromną troską w głosie.

— A te skarpetki? Tak o skarpetki pytam… zawsze tak leżą koło łóżka?— Zupełnie nie rozumiem, jak można nie prasować pościeli.— Jola, moja biedna kochana córeczka… Ach, Jolu… że też ci się taki mąż

musiał trafić…

I tak dalej, bez końca. Powoli zaczynasz się czuć jak mała laleczka wudu,w którą ktoś wbija kolejną szpilę. Ale możesz coś z tym zrobić. Jest jedno albodwa wyjścia. Pierwsza opcja jest bardzo prosta. Najmilej jak możesz dziękujeszmamusi za te wszystkie dobre rady i proponujesz, że odwieziesz ją na dwo-rzec. Ale tej nie polecam — jest mocno inwazyjna. Druga opcja zakłada pewnąrefleksję. Bo może ta „zła” mamusia, która na każdym kroku ze skutecznościąwyborowego strzelca wytyka nam nasze błędy, ma jednak rację? Skoro tak, tomożesz się z nią zgodzić, rozejrzeć się po pokojach i tak dobrze jak potrafiszposprzątać cały ten bajzel. Czemu nie? Ja bym tak zrobił.

MARIUSZ CHRAPKO

8

Lekcje pływaniaKolejna metafora wyjaśnia Scrum za pomocą pływania. To moja bardzo osobi-sta metafora, bo bardzo późno nauczyłem się pływać i przechodziłem sporemęczarnie, żeby mi się w końcu udało. Mój instruktor godzinami opowiadałmi, jak mam ustawić ręce, jak poruszać nogami. Ale to nie za sprawą teorii na-uczyłem się pływać, tylko dzięki długiej mozolnej praktyce. Ze Scrumem jestbardzo podobnie. Mogę Ci godzinami opowiadać o tej metodzie, ale dopókinie wskoczysz do wody swoich projektów i nie spróbujesz, na marne pójdzieTwój trud. Bo Scruma najlepiej się uczyć w praktyce. Można na jego temat teo-retyzować długie godziny, podobnie jak mój instruktor, który mi precyzyjnietłumaczył, co mam robić, żeby się utrzymać na wodzie. Co z tego? Kiedy tylkowchodziłem do wody, na nic się zdała jego nauka. Musiałem sam przełamaćstrach, uprzedzenia. Trzeba było na nowo nauczyć się oddychać i poruszaćw wodzie. Od czasu, kiedy nauczyłem się pływać, nie musiałem już brać żad-nych dodatkowych lekcji. Nie potrzebowałem ekstrakursów, certyfikatów,pomocy trenera. Po prostu pływałem. W momencie, kiedy zwinne praktykiwejdą Ci w krew i z sukcesem zaczniesz je stosować w swoich codziennychprojektach, sam na własnej skórze przekonasz się, czym tak naprawdę jestScrum. Komuś, kto nie potrafi pływać, trudno będzie zrozumieć, co czuje pły-wak, kiedy skąpany w popołudniowym chorwackim słońcu, gdzieś w okoli-cach Rovinji, wypływa w jasnoniebieskie morze. Tam, gdzie jest tylko on i ci-sza, i… wolność, którą smakuje.

AkuszerkaMam też bardzo fajną metaforę, której używam do wyjaśnienia, na czym pole-ga rola Scrum Mastera w zespole. Bardzo lubię tę metaforę, chociaż niektórzydość mocno marszczą brwi, gdy jej używam. Metafora akuszerki przydaje sięzwłaszcza wtedy, gdy wyjaśniam rolę Scrum Mastera jako coacha zespołu.Słowo „coaching” w naszych firmach jest bardzo różnie rozumiane, niestetynajczęściej jako „trener, nauczyciel” lub, gorzej, właściciel kija, którym trzebapopędzać zespół, żeby lepiej pracował. Tymczasem znaczenie tego słowa jestodmienne. Coaching to proces, dzięki któremu człowiek odkrywa i wdrażarozwiązania najbardziej zgodne z jego światopoglądem i wyznawanymi przezniego wartościami. Coach nie podaje tych rozwiązań, nie dostarcza wiedzyi gotowych pomysłów. W tym sensie praca coacha bardziej przypomina

SCRUMOWO-PYTAJNIKOWO

9

zadanie akuszerki, która jest tylko obecna przy porodzie i pomaga odebraćdziecko. Podobnie jest z coachem: stosując rozmaite techniki, pozwala jedynieurodzić rozwiązanie, ale go nie dostarcza. Bo coach nie jest nauczycielem. Pierw-szym propagatorem takiego podejścia był Sokrates, który bardzo umiejętniepotrafił wydobywać wiedzę od swojego rozmówcy. Każdą rozmowę rozpoczy-nał od umiejętnego zadawania pytań, udając, że pragnie się czegoś od roz-mówcy nauczyć. W trakcie pogawędki zmuszał rozmówcę, by ten dostrzegł sła-bości i możliwości w swoim sposobie myślenia. Przyparty do muru rozmówcamusiał wreszcie rozróżnić, co jest prawdziwe lub dobre, a co nie. Sokrates zwykłmawiać: „Nikogo niczego nie nauczę — mogę jedynie sprawić, by myślał”.

Scrum Master, podobnie jak akuszerka, używa różnego rodzaju „technikpołożniczych”. Jego podstawowe narzędzia to: umiejętność słuchania, zada-wania pytań, parafraza, odzwierciedlenie, intuicja, pozwolenie, udzielanie in-formacji zwrotnej. Jak widać, podstawą pracy Scrum Mastera jest rozmowa.Każdy Scrum Master jest częścią zespołu w Scrumie. W ten sposób ma mnó-stwo okazji do tego, żeby rozmawiać, prowadzić coaching tak indywidualny,jak i całego zespołu. Scrum Master dzięki dialogowi pomaga swoim rozmówcomdostrzec nowe perspektywy i lepiej zrozumieć własne myśli, emocje i działania,ale także i zewnętrzne otoczenie (ludzi i sytuacje).

Właściciel Produktu — kierowcaI może jeszcze jedna, już ostatnia, metafora. Dotyczy Właściciela Produktu.Kiedyś, na jednym ze spotkań otwierających projekt poprosiłem uczestników,żeby przygotowali plakat swojego zespołu. To było bardzo fajne ćwiczenie.W efekcie narysowali fantazyjną rakietę. Za jej sterem siedział Właściciel Pro-duktu, a miejsca pasażerskie były obstawione kolejnymi członkami zespołu. —Nic dodać, nic ująć — powiedziałem. Właściciel Produktu to osoba, która trzy-ma kierownicę. Dzieli się swoją wizją, określa kierunek jazdy. Wie, którą drogęwybrać, jak pojechać, żeby uniknąć korków. Członkowie zespołu są tylko pa-sażerami.

***To tyle metafor. Trochę się rozpisałem, ale mam nadzieję, że uda Ci się coś wy-korzystać w swojej pracy. Bardzo dziękuję za to pytanie ;).

MARIUSZ CHRAPKO

10

2. JAK SKUTECZNIE PIELĘGNOWAĆ BACKLOGPRODUKTU W SCRUMIE?

Po co nam sesje pielęgnacyjne? Kto powinien w nich uczestniczyć?Jak często się odbywają? Jak je planować?

Jaki jest najlepszy moment dla Właściciela Produktu i zespołu na spotkaniezwiązane z pielęgnacją sprintu — zaraz po zakończeniu wcześniejszego,

kiedy łatwo spojrzeć w tył i pokazać, co poszło nie tak?

Maciej Malak

Ogólnie przyjęte praktyki w Scrumie (OPPS)Zanim zabiorę się do odpowiedzi na te pytania, zacznę od tego, że Scrum jestmetodą, która ciągle ewoluuje i ma różne odsłony. Pamiętam, kiedy zaczyna-łem swój pierwszy projekt w Scrumie, było to już blisko jedenaście lat temu.Byłem wtedy etatowym pracownikiem dużej amerykańskiej korporacji. I jedy-nym źródłem mojej wiedzy o Scrumie była w zasadzie książka Kena Schwabe-ra „Agile Project Management with Scrum” plus parę zagranicznych blogów.W Polsce nikt nie organizował jeszcze żadnych konferencji, szkoleń; ludzie niepisali na ten temat artykułów, książek. W ogóle nie było jeszcze żadnej „oficjal-nej wersji” Scruma. I minęło dobre parę lat, zanim to wszystko zaczęło sięzmieniać.

Dzisiaj, oprócz samego rdzenia tej metody — „twardych” reguł, które two-rzą jej szkielet — istnieje cała masa dobrych praktyk będących w znakomitejsymbiozie z regułami Scruma. Należą do nich chociażby: historyjki użytkowni-ka, sprint 0, Definition of Ready (DoR), Test-Driven Development, Programo-wanie w Parach, tablica scrumowa, a także sesje pielęgnacyjne. Mike Cohnukuł nawet dla nich dość osobliwą nazwę: Generally Accepted Scrum Practices,

SCRUMOWO-PYTAJNIKOWO

11

w skrócie GASP. Ja używam dla nich polskiego odpowiednika: ogólnie przy-jęte praktyki w Scrumie (OPPS).

Reguły, pomysły i ogólnie przyjęte praktyki w Scrumie

Oficjalne spotkanie czy nie?Co ciekawe, sesje pielęgnacyjne wciąż nie należą do oficjalnych spotkańw Scrumie. Sama metoda mówi tylko, że pielęgnowanie Backlogu Produktupowinno mieć charakter ciągły i to zespół scrumowy decyduje o tym, jak i kie-dy powinno się ono odbywać. Nie wiem, czy wiecie, ale kiedyś, bardzo podob-nie było z retrospektywami w sprincie. Mimo że dzisiaj zabrzmi to jak herezja,ale początkowo retrospektywa wcale nie należała do oficjalnych praktykw Scrumie. Ogólne przeświadczenie było takie, że zespoły scrumowe powinnyciągle doskonalić swoją pracę i na bieżąco szukać sposobów jej ulepszania. Niema potrzeby, żeby tego typu działania „wymuszać” jakimś dodatkowym spo-tkaniem. A jednak. Jak się później okazało, w praktyce nikt nie miał do tegogłowy, żeby myśleć o jakichś usprawnieniach w sprincie. Sytuacja zmieniła siędopiero wtedy, gdy retrospektywa została wprowadzona jako oficjalne spo-tkanie w Scrumie. Trzymam mocno kciuki, żeby kiedyś podobny los spotkałsesje pielęgnacyjne w sprincie.

MARIUSZ CHRAPKO

12

Skąd nazwa?Z nazwą tej praktyki było różnie. Sesje pielęgnacyjne pochodzą od angielskie-go słowa grooming, które można przetłumaczyć jako:

1. czyszczenie i szczotkowanie zwierząt domowych, np.: kota, psa, konia;

2. dbanie o swój własny wygląd (higiena osobista, ubiór itp.) — czasemmówimy, że ktoś jest zadbany (ang. well-groomed);

3. wzajemne mycie się i czyszczenie (futro, skóra) dwóch zwierząt.

Ale nie są to wszystkie możliwe znaczenia. Słówko grooming w niektórych kra-jach (np. Holandii) oznacza również działania związane z uwodzeniem dzieciprzez internet (tzw. childgrooming). Dlatego, od jakiegoś czasu społecznośćscrumowa używa innego, bardzo podobnego znaczeniowo słowa refinement.W jednym i w drugim przypadku chodzi jednak o to samo — pielęgnacjęBacklogu Produktu, jego obróbkę, cyzelowanie.

Po co nam sesje pielęgnacyjne?Powodów jest kilka. Zacznijmy od Właściciela Produktu. Należy pamiętać, żejego myślenie o produkcie sięga dużo dalej niż tylko do tego, co się dziejew tym lub innym sprincie. Właściciel Produktu, zwłaszcza w dużych organiza-cjach, musi myśleć także o kolejnych wydaniach produktu lub kolejnych pro-jektach, które są planowane. Tak więc niezależnie od tego, co się dziejew sprincie, w backlogu ciągle pojawiają się nowe wymagania, które trzebaz zespołem przegadać, doprecyzować, pomyśleć o możliwych rozwiązaniachi oszacować.

Do tego wszystkiego dochodzą również różnego rodzaju zależności (innezespoły, dostawcy zewnętrzni). Może się np. okazać, że wynik naszego sprintubędzie mocno zależał od tego, czy inny zespół dostarczy jakiś element produktu,czy nie.

Pracowałem również z zespołami, które podczas sesji pielęgnacyjnych odczasu do czasu pokazywały, co im się udało zrobić w sprincie — zanim jeszczedoszło do przeglądu na koniec sprintu. Czemu nie? Takie minidema mogą byćczasem bardzo pomocne. Oczywiście nie można przesadzić.

SCRUMOWO-PYTAJNIKOWO

13

Sesje pielęgnacyjne są również bardzo wartościową praktyką z punktu widze-nia samego Zespołu Deweloperskiego. Pamiętam, że kiedy stawiałem pierwszekroki w Scrumie, a było to już blisko jedenaście lat temu, praktyka regularnychsesji pielęgnacyjnych z Właścicielem Produktu pojawiła się w naszym zespolew pewnym sensie naturalnie. Jedną z rzeczy najbardziej nam doskwierającychw Scrumie był długi czas, jaki spędzaliśmy na planowaniu sprintu. Rzadkokiedy udawało nam się zaplanować dwutygodniowy sprint w osiem godzin.Wiele razy nasze planowanie kończyło się dopiero na drugi dzień. Wynikało toz bardzo prostej rzeczy: w trakcie sprintu nie mieliśmy regularnych „nasiadó-wek” z Właścicielem Produktu i gdy przychodziło do planowania sprintu,robiliśmy na nim wszystko: pisaliśmy historyjki, dogadywaliśmy szczegóły, sza-cowaliśmy, definiowaliśmy zadania… — a dzień leciał. Regularne sesje pielęgna-cyjne w sprincie skróciły sam czas planowania sprintu do dwóch – trzechgodzin.

Co robimy na sesjach pielęgnacyjnych?Poniżej lista rzeczy, które są najczęściej realizowane w trakcie takiego spotkania.

Przygotowanie historyjek użytkownika pod kątem najbliższegolub kolejnych sprintów (dekompozycja historyjek na mniejsze części,definicja kryteriów akceptacyjnych, uszczegóławianie zakresu,dyskusja nad możliwymi rozwiązaniami).

Porządkowanie historyjek w Backlogu Produktu (zmiana priorytetów).

Szacowanie pracochłonności historyjek (osobodni lub story points).

Pisanie nowych historyjek i aktualizacja starych.

MARIUSZ CHRAPKO

14

Częstotliwość spotkań Sesje pielęgnacyjne zajmują mniej więcej od 5 – 10% czasu trwania każdegosprintu i powinny być uwzględnione podczas planowania sprintu, najlepiej ja-ko oddzielne zadania na tablicy scrumowej. Ja zwykle robię to tak, że podczasplanowania sprintu na tablicy pojawia się historyjka, która nie jest funkcjonal-na, a jedynie mieści w sobie wszystkie zadania „ogólnosprintowe” (np. buforyna naprawę błędów). Jednym z takich zadań są właśnie sesje pielęgnacyjne.

Ile sesji w sprincie?To wszystko zależy od Zespołu Scrumowego. Pracowałem z zespołami, którepreferowały krótkie spotkania, dwa lub trzy razy w tygodniu (np. jedna godzi-na na spotkanie). Inne zespoły wolą robić to rzadziej, ale siedzieć dłużej (np.raz w tygodniu po dwie – trzy godziny). Każdy zespół musi sobie wypracowaćwłasne podejście, które mu najbardziej odpowiada.

SCRUMOWO-PYTAJNIKOWO

15

Kto uczestniczy w sesjach?Tu bywa bardzo różnie. Na pewno powinien się pojawić Właściciel Produktuoraz Zespół Deweloperski. Jednak nie zawsze obecność wszystkich członkówzespołu jest konieczna. Są sytuacje, w których Właściciel Produktu spotyka siętylko z kilkoma wybranymi osobami. W innych przypadkach na takie spotka-nia przychodzą wszyscy. Zdarzają się sytuacje, że na sesje pielęgnacyjneprzychodzą również inne osoby z organizacji oprócz członków Zespołu Scru-mowego, np. architekt korporacyjny lub kierownik projektu (jeśli Backlog Pro-duktu jest backlogiem konkretnego projektu lub projektów). Tu znowu nie mareguły i sami musicie ocenić, kto jeszcze mógłby być na takim spotkaniu po-trzebny.

***Uważam, że sesje pielęgnacyjne są jedną z fajniejszych praktyk w Scrumie.I mimo że nie ma obowiązku organizować ich w każdym sprincie, bardzomocno Was do tego zachęcam. Z Backlogiem Produktu jest jak z ogrodem. Jeśligo nie pielęgnujesz, zarasta.

MARIUSZ CHRAPKO

16

3. SPRINT „ZEROWY” — DOBRY CZY ZŁY POMYSŁ?

Czy zalecane jest organizowanie sprintu „zerowego” jako wstępu do zarządzaniawedług zwinnych metod? Jakie korzyści/straty niesie za sobą wprowadzenie sprintu

„zerowego”? Czy w Scrumie zaleca się praktykowanie sprintu „zerowego”?

Damian Janczur

W odpowiedzi na poprzednie pytanie pisałem o tym, że w samym Scrumieoprócz „twardych” reguł, które tworzą jego szkielet (ang. framework), istniejeteż całkiem spora grupa praktyk, które oficjalną częścią Scruma nie są, ale przezwiele zespołów są powszechnie stosowane. Jedną z takich praktyk jest właśnieorganizowanie tzw. sprintu „zerowego”, zanim jeszcze z czymkolwiek się wy-startuje.

Czym jest sprint „zerowy”?Sprint 0 to, najkrócej, poczynienie wszystkich niezbędnych przygotowań, żebymóc w końcu wystartować ze sprintem 1 w firmie. W każdym przypadku listatakich „zerowych” aktywności wygląda inaczej. Poniżej zamieszczam krótkikatalog zadań, które najczęściej pojawiają się w prowadzonych przeze mnieprojektach u klienta.

Lista „produktów”, które powstają w sprincie „zerowym”

Stworzenie zespołu. Czasem zespół jest, a czasem go nie ma.I wtedy musimy wszystko budować od początku. Wówczas najlepiejjest zorganizować oddzielne warsztaty, w ramach których wypracujeciesobie skład takiego zespołu oraz ustalicie, kto i jaką rolę odgrywa.Ja zazwyczaj robię tak, że na początku takiego spotkania wyjaśniamwszystkim podstawowe zasady związane z budowaniem Zespołów

SCRUMOWO-PYTAJNIKOWO

17

Scrumowych, a także dzielę się dobrymi praktykami, które przećwiczyłemw projektach prowadzonych u innych klientów. W trakcie takichwarsztatów, oprócz składu zespołu, wybieramy Scrum Mastera, chociażna początku nie zawsze się to udaje. Są zespoły, które potrzebują na takądecyzję trochę więcej czasu. Czasem też, w niektórych organizacjach,Scrum Mastera wybiera menedżer liniowy zespołu, chociaż zawszewszystkich zachęcam, żeby taką decyzję pozostawić zespołowi. Jeślichodzi o Właściciela Produktu, w przypadku prowadzonych przez mniedotąd projektów na tym etapie jest on już najczęściej znany. Prowadzącwdrożenie Scruma w dużej organizacji, nad zaangażowaniem Biznesutrzeba zacząć pracować wcześniej, najczęściej podczas odrębnychwarsztatów, których jednym z punktów jest obsadzenie ról w tymzakresie.

Czas trwania: 2 – 4 godziny

Spotkanie otwierające. Głównym celem takiego spotkania jest oczywiścieformalne zainicjowanie projektu. Przedstawienie wizji, celówbiznesowych, które chcemy osiągnąć, możliwych korzyści, a takżezaprezentowanie zespołowi, w jaki sposób będzie pracował, jakichnarzędzi będzie używał, jakich metod i praktyk. To właśnie na tymspotkaniu nowo uformowany Zespół Scrumowy powinien usłyszećo planowanej zmianie — wdrożeniu metod agile w organizacji. Dlaczegoto robimy? Jakie są korzyści z takiego podejścia? Jakie są oczekiwaniafirmy w tym zakresie? Doskonale zdaję sobie sprawę, że może Wam sięto wydawać aż nadto oczywiste, jednak jeżeli menedżer zespołu dobrzeprzeprowadzi takie spotkanie, będzie Wam dużo łatwiej „zapanować”nad zmianą w Waszej organizacji. Najgorzej jest wtedy, a ciągle zdarzająmi się takie sytuacje, gdy menedżer zespołu liczy, że w tym zakresiewyręczy go konsultant zewnętrzny.

Czas trwania: 1 – 2 godziny

Przeprowadzenie niezbędnych szkoleń. Tutaj mogą się znaleźć szkoleniadotyczące samego projektu, ktoś np. kupił rozwiązanie lub narzędzieod zewnętrznego dostawcy i zespołowi trzeba przekazać odpowiedniąwiedzę na ten temat. Jeżeli zdecydowaliście, że zamiast tablic fizycznychbędziecie używać narzędzi elektronicznych do zarządzania pracąw Scrumie, również powinniście pokazać ludziom, jak to robić. Oprócztego bardzo ważne jest, żeby zespół poznał podstawowe założeniaScruma, praktyki, artefakty. Jeżeli zespół jest całkiem nowy, podczas

MARIUSZ CHRAPKO

18

takich szkoleń dobrze jest także dołożyć jakieś ćwiczenia, które zintegrująludzi w nowo powstałym zespole i dadzą solidnego kopa do dalszegobudowania zespołu.

Czas trwania: 4 – 7 dni

Przygotowanie „wsadu” do sprintu 1. Zanim wystartujecie z pierwszymsprintem, Właściciel Produktu powinien usiąść z zespołem i przygotowaćsię do pracy w sprincie 1. Przede wszystkim należy ustalić, jakie kryteriapowinny spełniać historyjki użytkownika, zanim trafią na sesjęplanistyczną w sprincie (tzw. definition or ready), a także na jakiejpodstawie będzie odbierana praca w sprincie (tzw. definition of done).Ja zwykle od tego zaczynam. Potem, gdy już mamy zdefiniowanekryteria, możemy się zabrać za przygotowanie „materiału”, nad którymbędziemy pracować w sprincie 1. Podczas wspólnych warsztatówWłaściciel Produktu wspólnie z Zespołem Deweloperskim przygotowują„paczkę” historyjek, od których rozpoczną pracę w najbliższym sprincie.Najczęściej, żeby ruszyć, wystarcza dziesięć – dwanaście historyjek.Historyjki należy później oszacować (punkty, idealne dni).

Czas trwania: 1 – 3 dni

Opracowanie wstępnego planu wydania. W zależności od tego, jakiegotypu wydań używacie w firmie (zorientowane na datę lub określonyzakres), w ramach sprintu „zerowego” może zaistnieć potrzeba ustalenia,ile będziecie w stanie zrobić do określonej daty (planowanie zorientowanena datę) lub na kiedy (planowanie na podstawie określonego zakresu).Niektórzy Właściciele Produktu chcą znać takie informacje, zanim zespółruszy z pracą w pierwszym sprincie.

Czas trwania: 1 – 3 dni

Logistyka. O tym punkcie często się zapomina. Później okazuje się, żezespół startuje ze sprintem i nie ma tablicy, na której mógłby rozwiesićswoje zadania, brakuje karteczek samoprzylepnych, nie ma flipchartado narysowania wykresu, nie ma czym rysować, bo nie ma pisaków.Poniżej lista rzeczy, które najczęściej pojawiają się w moich projektach:

Zakup tablic do wizualizacji pracy w Scrumie, zorganizowaniesamoprzylepnych karteczek, markerów, kartek do flipcharta(wykres spalania).

Przygotowanie wspólnego pokoju do pracy. Czasem ludzie siedząna różnych piętrach lub są rozmieszczeni w różnych lokalizacjach

SCRUMOWO-PYTAJNIKOWO

19

(np. Poznań i Warszawa). Kiedyś pracowałem z klientem, u któregoprac logistycznych było tak dużo, że musieliśmy uruchomić specjalnyprojekt do tego typu działań. Bo np. trzeba było zorganizowaćprzeprowadzkę kilku działów, kupić nowe meble, przebudowaćniektóre ścianki w budynku firmy. Oj, działo się!

Zorganizowanie niezbędnego sprzętu do pracy (komputery, dostępdo narzędzi, zakup licencji).

Konfiguracja narzędzi do zarządzania pracą w Scrumie. W małychorganizacjach to nie jest żaden problem. Możecie wystartować zesprintem 1 i wszystko powoli sobie dokręcać. Ale gdy w firmie pracujekilka tysięcy osób i każdemu nowo powstałemu zespołowi dacieuprawnienia administratora, np. do takiego narzędzia jak JIRA,i każdy taki nowo powstały zespół sam sobie będzie wszystkokonfigurował (zakładał projekt, określał jego strukturę, definiowałwłasne pola, ekrany, przepływy) — to później będziecie musielipowołać oddzielny projekt, żeby to wszystko odkręcić.Nie wyolbrzymiam teraz, to „najprawdziwszy autentyk”.

Czas trwania: od kilku dni do jednego miesiąca

Jak widzicie, zadań, które są do wykonania w sprincie 0, jest całkiem sporo.Przy każdym elemencie podałem Wam orientacyjnie, jaki jest czas trwania da-nego działania. W każdej organizacji sprint „zerowy” wygląda trochę inaczej.Lista, którą Wam przedstawiłem, zawiera wszystkie najbardziej typowe ak-tywności konieczne do wykonania, jeżeli wdrażacie Scruma w dużej organiza-cji (od kilkuset do kilku tysięcy osób). W mniejszych firmach zarówno czastrwania sprintu „zerowy”, jak i sama lista aktywności może się znacząco skró-cić. Zwykle jednak taki „sprint” trwa od jednego do trzech miesięcy – oczywi-ście w przypadku, kiedy wdrażacie Scruma w całej organizacji. W pozostałychprzypadkach od dwóch do czterech tygodni. Nie dłużej.

Dobry czy zły pomysł?Sprint 0 to bardzo dobry pomysł. Serio! Nie wyobrażam sobie wdrożeniaScruma w jakiejkolwiek firmie bez uprzedniego przygotowania odpowiednichwarunków, które umożliwią jego bezproblemowy przebieg. Oczywiście możeciepominąć sprint 0 i próbować robić wszystko „po drodze” — w sprincie 1, 2… Alenie polecam. Co będzie produktem takich sprintów?

MARIUSZ CHRAPKO

20

Pora na małą krytykę sprintu 0. Rzeczą, która mi się absolutnie nie podobaw tej praktyce, jest jej nazwa. Posługiwanie się terminem sprint 0, zwłaszczakiedy startujecie z wdrożeniem Scruma w firmie, prowadzi do całkiem sporegozamieszania. Ludzie będą pytać: „A co to za sprint, w którym nic nie powstaje?”,„A dlaczego zero?”, „A ile powinien trwać taki sprint?”. Egh… Był to głównympowód, dla którego zrezygnowałem z nazywania tej praktyki „sprintem 0”.

Poza tym musimy pamiętać o tym, że choćbyśmy nie wiem jak bardzo fiku-śnie numerowali sobie sprinty, na koniec każdego z nich powinien powstaćpotencjalnie gotowy do wdrożenia kawałek produktu (inkrement). Takie sąw końcu reguły Scruma, prawda? A w sprincie 0 taki produkt, rzecz jasna, niepowstaje. Zgoda, możemy się spierać, czy aby na pewno nie powstaje. Boprzecież stworzenie zespołu czy opracowanie DoD jakimś tam „produktem”jest, prawda? No tak. Ale nie o taki produkt w Scrumie chodzi.

Skoro nie „sprint 0”, to jak w takim razie ta praktyka powinna się nazywać?I tu jest problem. Próbowałem naprawdę różnych sposobów: „incepcja”,„przed-projektem”, „zaczątek”. Jak na razie najlepiej sprawdzało się „przed-sprincie”. Jedynie w ofertach do klientów tej nazwy nie używam, bo jest zbytkolokwialna. Tam piszę zwyczajnie: „przygotowanie do sprintu 1”. I już.

PodsumowanieSzczerze polecam praktykowanie sprintu 0 w Waszej organizacji,nawet jeżeliinaczej go nazwiecie. Podstawową korzyścią z wprowadzenia „przedsprincia”jest stworzenie niezbędnych warunków do tego, żeby zacząć. Żadnych strat zestosowania tej praktyki nie zauważyłem.

SCRUMOWO-PYTAJNIKOWO

21

4. CO ZNACZY BYĆ DOBRYM SCRUM MASTEREM?

Spośród pytań, które przysłaliście, wybrałem dwa:

Co to znaczy być dobrym Scrum Masterem?

Paulina Seroka

Jaka jest właściwa rola Scrum Mastera?

Michał Płachta

Przede wszystkim bardzo dziękuję za to pytanie. Moim zdaniem w naszychorganizacjach mamy prawdziwy deficyt dobrych Scrum Masterów. Naprawdęna palcach jednej ręki mogę policzyć osoby, które mógłbym nazwać dobrymiScrum Masterami. Nie mówię „idealnymi”, ale właśnie dobrymi. Z tego, co ob-serwuję, rola Scrum Mastera w firmie najczęściej sprowadza się do funkcji stric-te administracyjnej. Ludzie myślą, że Scrum Master to taka „dobra mamuśka”,która organizuje i prowadzi spotkania w Scrumie, dba o porządek na tablicyw sprincie, zlicza „spalone” godziny, uzupełnia wykresy, zamiata, sprząta,przywozi pizzę i Bóg wie co jeszcze.

Pytanie, które zadaliście, również mnie wiele razy chodziło po głowie. Od-kąd zacząłem swoją przygodę ze Scrumem, pracowałem z wieloma zespołami,ich liczba idzie już w setki. W tym czasie miałem do czynienia z różnymi oso-bowościami, kompetencjami. Gdybym jednak miał zwrócić uwagę na najważ-niejsze cechy dobrego Scrum Mastera, wskazałbym tylko trzy role, które moimzdaniem są najważniejsze: arbiter, coach i lider (służebny).

1. ARBITERScrum Master w pierwszej kolejności jest strażnikiem procesu. Dba o to, że-by wszystkie reguły Scruma były stosowane. Dobry Scrum Master jest jak do-bry sędzia piłkarski, taki jak np. mój ulubiony Pierluigi Collina.

MARIUSZ CHRAPKO

22

Sędzia sportowy, arbiter — mówi definicja — to osoba,która czuwa nad prawidłowym przebiegiem konkuren-cji i przestrzeganiem zasad gry, przyznająca i zatwier-dzająca zdobyte punkty. W grach zespołowych sygnalizujefaule oraz inne przewinienia. Decyzje sędziego sportowe-go nie podlegają anulowaniu przez ich przełożonych i sątraktowane jako rozstrzygające u bukmacherów.

Nic dodać, nic ująć. Rola Scrum Mastera właśnie na tym polega – na sędziowa-niu „gry w Scruma”. Dlatego powinien dobrze znać zasady. Jeżeli Zespół, Wła-ściciel Produktu lub ktokolwiek inny w organizacji nie jest pewny, czy to, corobi, jest zgodne z regułami Scruma, Scrum Master powinien bez problemu ta-ką wątpliwość rozwiać. W końcu jest sędzią, prawda?

No dobrze, jakie więc cechy powinien posiadać Scrum Master jako sędzia?Posłuchajmy, co dalej mówi definicja arbitra:

Najważniejszą cechą każdego sędziego musi być bezstron-ność, gdyż bez niej mecz nie może zostać dobrze przepro-wadzony. Składnikiem, który w największym stopniu de-cyduje o poziomie sędziowania, jest znajomość przepisówgry i umiejętność ich stosowania.

Bezstronność, znajomość przepisów gry i umiejętność ich stosowania — otocechy dobrego Scrum Mastera, który z definicji nie angażuje się w „sposób gry”zespołu. Nie ocenia podjętych decyzji, nie wartościuje przyjętych rozwiązań.Także nie nadużywa procesu Scruma do realizowania swoich partykularnychinteresów. Czuwa jedynie nad tym, żeby reguły Scruma były przestrzegane.Bezwzględnie.

Innym ważnym elementem postawy sędziego w sportachdrużynowych takich jak piłka nożna lub piłka ręczna jestkondycja fizyczna. Odporność psychiczna sędziego musibyć ogromna, gdyż cały czas poddawany jest presji zestrony rywalizujących drużyn. Sędzia nie może bać się po-dejmować trudnych decyzji (np. rzut karny przeciwkodrużynie gospodarzy).

SCRUMOWO-PYTAJNIKOWO

23

Mimo że dobry Scrum Master powinien w sposób bezstronny egzekwować re-guły Scruma, w praktyce to wcale nie jest takie proste. Czasami presja ze stronyludzi w zespole jest olbrzymia — np. naciskają, żeby wydłużyć sprint, żeby nierealizować tej lub innej praktyki, żeby pójść drogą na skróty. Dobry Scrum Ma-ster powinien odważnie umieć przypominać o regułach Scruma.

2. COACHBycie coachem, to dla mnie druga ważna rola dobrego Scrum Mastera. Wedługmnie jest to ciągle jedna z najbardziej niewykorzystywanych „mocy” w Scru-mie. Zacznijmy od tego, że słowo coaching jest w naszych firmach bardzo róż-nie rozumiane — niestety najczęściej jako „trener, nauczyciel” lub, gorzej, wła-ściciel kija, którym trzeba popędzać zespół, żeby lepiej pracował. Tymczasemznaczenie tego słowa jest zupełnie inne. Coaching to proces, dzięki któremuczłowiek odkrywa i wdraża rozwiązania najbardziej zgodne z jego światopo-glądem i wyznawanymi przez niego wartościami. Coach nie podaje tych roz-wiązań, nie dostarcza wiedzy ani gotowych pomysłów.

W tym sensie coaching bardzo przypomina metodę filozoficzną, którą sto-sował kiedyś Sokrates. Porównywał ją z zawodem swojej matki: ze sztuką po-łożniczą, czyli majeutyką (z gr. technemaieutike). Majeutyka Sokratesa jest nietyle metodą nauczania, co metodą wspólnego dochodzenia do prawdy.

Nikogo niczego nie nauczę — zwykł mawiać Sokrates —mogę jedynie sprawić, by myślał.

I na tym właśnie polega istota coachingu. Coach jest jedynie towarzyszem po-dróży.

Dobry Scrum Master jest coachem ludzi i zespołu. Muszę przyznać, że bar-dzo nie lubię określenia agile coach. Moim zdaniem wprowadza sporo niepo-trzebnego zamieszania. W wielu firmach się myśli, że skoro ktoś już jest agilecoachem, to posiadł jakieś supertajne moce, które go predestynują do pracyw projektach agile. Prawda jest taka, że nie ma znaczenia, jakiego przymiotnikado określenia coacha użyjecie — agile coach, life coach, team coach, executivecoach… W każdym przypadku zasady coachingu są te same.

Najważniejszą zasadą coachingu jest „samosterowne uczenie się”. Innymisłowy, dobry Scrum Master uczy innych, jak powinni się uczyć. Używa do tegospecjalnych narzędzi, głównie pytań, które nie są pytaniami zamkniętymi czy

MARIUSZ CHRAPKO

24

sugerującymi. Przeciwnie, stosuje pytania otwarte, które pozwalają osobomcoachowanym sięgnąć w głąb swojego wnętrza. Kiedy prowadzę coaching ze-społu, niezmiennie fascynuje mnie fakt, ile niesamowitych odpowiedzi na na-prawdę złożone problemy powstaje w umysłach ludzi, z którymi pracuję. Onepo prostu tam są, czasem trzeba mieć tylko trochę cierpliwości, umieć zamilk-nąć i zacząć słuchać, co mają do powiedzenia inni.

W coachingu ważne jest to, że osoba coachowana zawsze kontroluje sytu-ację. Dobry Scrum Master nie narzuca swojego zdania, opinii, sądów czy roz-wiązania konkretnego problemu. Jak długo Scrum Master będzie przestrzegałtej zasady, nie jest możliwe, żeby w jakiś sposób zaszkodził coachowanemu.

Czy w takim razie tego wszystkiego można się nauczyć? Oczywiście, że tak.I w żadnym wypadku nie jest to jakaś wiedza tajemna. Wynika to z bardzoprostego faktu, o którym już trochę wcześniej wspominałem. Coaching jestprocesem, a nie konkretną wiedzą, którą przekazujecie coachowanemu. DobryScrum Master w roli coacha nie udziela porad, ale wspiera proces samokształ-cenia się Zespołu Scrumowego, który jest coachowany. Żeby mógł to robić,musi nauczyć się pewnych technik (umiejętność słuchania, zadawania pytań,parafraza, odzwierciedlenie i intuicja, pozwolenie, udzielanie i przyjmowanieinformacji zwrotnej), a także poznać określone metody i narzędzia (np. analizatransakcyjna, metoda gadającego patyka). Oprócz znajomości konkretnychtechnik ważna jest sama osobowość coacha. Moim zdaniem to, co czyni z ko-goś dobrego Scrum Mastera, to w 80% osobowość — umiejętność odczuwaniaempatii, zrozumienie, koncentracja — a tylko w 20% szkolenie.

3. LIDER (służebny)To już trzecia, ostatnia rola, który moim zdaniem konstytuuje dobrego ScrumMastera, dla którego władza jest służbą. Jest taki fajny akronim: SERVE, naktóry natknąłem się w książce Kena Blancharda i Marka Millera pod tytułem:Sekret. Tajemnica wielkich liderów. Jest to książka o tym, że najwięksi przywódcysłużą innym. SERVE to pięć aspektów tego służenia, które każdy dobry ScrumMaster powinien spełniać:

S jak See The Future (z ang. spoglądaj w przyszłość). Dobry scrum masterma wizję, żyje nią — potrafi zabrać ludzi z jednego miejsca na drugie.Dobry scrum master to ktoś, kto wybiega w przyszłość, jaką ma przedsobą jego zespół. Jest kilka pytań, na które każdy dobry scrum masterzna odpowiedzi:

SCRUMOWO-PYTAJNIKOWO

25

Jaki jest cel zespołu, który wspiera?

W jakim miejscu widzi swój zespół za rok lub dwa?

Ile osób w zespole jest w stanie bez problemu odpowiedzieć,co chce osiągnąć lub kim chce zostać za jakiś czas?

Czy zakomunikował swoją wizję zespołowi?

E jak Engage and Develop People (z ang. angażuj i rozwijaj pracowników).Dobry Scrum Master to ktoś, kto przyczynia się do rozwijania zespołu.To ktoś, kto wyzwala zaangażowanie u pracowników, i rozwija ich tak,żeby mogli funkcjonować zgodnie z przedstawioną wizją. Tutaj w sukursprzychodzą mu zdolności coachingowe, o których pisałem wcześniej.W kontekście angażowania i rozwijania pracowników dobry scrummaster umie sobie odpowiedzieć na następujące pytania:

Jakie są główne cechy zespołu, który wspiera?

W jaki sposób włącza się w angażowanie ludzi w zespole?

Co może zrobić, żeby lepiej wyzwalać zaangażowanie w zespole(czy potrafi wymienić pięć – dziesięć konkretnych rzeczy)?

Jak wspiera rozwój pracowników?

R jak Reinvent Continuously (z ang. ciągle się rozwijaj). Dobry scrummaster ciągle się rozwija, udoskonala siebie samego, na płaszczyźnieosobowościowej. Jest zawsze gotowy do tego, żeby pogłębić swojąwiedzę, podnieść swoje umiejętności na wyższy poziom. Muszę Wampowiedzieć, że „chęć do rozwoju” jest ciągle towarem deficytowym sporejliczby Scrum Masterów w firmach. Wielu z nich nie robi nic. Ledwo,ledwo nauczy się reguł Scruma, i na tym cały rozwój się kończy.Tymczasem najlepsi scrum masterzy ciągle się uczą. Dobry scrum masterdużo czyta. Mam tutaj na myśli różne branżowe książki, artykuły, blogi.Dobry scrum master ma swojego mentora – kogoś, z kim się spotyka,rozmawia, wymienia się doświadczeniami. To może być także udziałw jakiejś grupie dyskusyjnej, warsztatach, branżowej konferencji.W kontekście ciągłego doskonalenia dla każdego dobrego Scrum Masterważne jest:

Kim są jego mentorzy?

Jakie książki czyta?

W jakich agile’owych wydarzeniach bierze udział (grupy dyskusyjne,konferencje)?

Czy w ogóle ma czas na rozwój?

MARIUSZ CHRAPKO

26

V jak Value Results and Relationships (z ang. doceniaj wyniki i relacjemiędzyludzkie). To są dwa bardzo ważne aspekty, z którymi każdy ScrumMaster musi się zmierzyć. Dobry Scrum Master potrafi znaleźć balanspomiędzy sferą wyników i relacji międzyludzkich. Wartościuje i jedno,i drugie. Dobry Scrum Master nie dba tylko o dobrą atmosferę pracyi w zespole. Jest również buldożerem, który usuwa wszystkie zawalidrogi,żeby zespół mógł efektywnie pracować. Dobrego Scrum Mastera możnapoznać po tym, że zespół, z którym pracuje, generuje dobre wyniki.W odniesieniu do kwestii wyników i relacji międzyludzkich: każdy dobryScrum Master umie odpowiedzieć sobie na następujące pytania:

Jak bardzo potrafi wpłynąć na osiągane wyniki w zespole?

Ile osób w zespole jest w stanie powiedzieć, że przyczynił się do jakiejśzmiany w ich życiu?

W jaki sposób wyraża uznanie za dobrze wykonaną pracę w sprincie?

E jak Embody the Values (z ang. bądź ucieleśnieniem wartości). DobryScrum Master to ktoś, komu zespół ufa. Zaufanie z kolei buduje sięprzez życie zgodne z wyznawanymi wartościami. Dobry Scrum Masternie ściemnia. Żyje tak jak mówi. Bo życie wartościami to nic innegojak dawanie przykładu swoim zachowaniem. Dobry Scrum Master jestucieleśnieniem wizji. Mówi: „Rób tak, jak ja robię”, a nie: „Rób, jak cipowiem”. Inaczej szybko straciłby swoją wiarygodność w zespole.W kontekście życia wartościami każdy dobry Scrum Master wie:

Jak włączyć wartości Scruma do sposobu funkcjonowania zespołu.

Jak zakomunikować zespołowi swoje wartości w sprincie.

W jaki sposób zmienić swoje postępowanie lub nawyki tak,żeby bardziej utożsamiać się z wartościami, o których mówi.

***Odpowiadając na pytanie o bycie dobrym Scrum Masterem, zwróciłem uwagęjedynie na trzy, wydawałoby się, proste role, z tym związane. Jednak już pokrótkiej analizie od razu widać, że realizacja tych ról wcale nie jest tak prosta,jak się początkowo wydaje. Wymaga dużych nakładów dyscypliny, konse-kwencji i pracy – głównie nad sobą. Mimo całego tego wysiłku jest to droga, naktórą warto wkroczyć.

SCRUMOWO-PYTAJNIKOWO

27

Dodatkowo podrzucam do poczytania następujące artykuły:

Wywiad: Adam Kwiecień o frajdzie bycia scrum masterem

Scrum Master — projektant, nauczyciel, sługa

Scrum master i uważne nakłucie

MARIUSZ CHRAPKO

28

5. CZY MOŻNA MIEĆ SCRUMA BEZ SCRUMA?

W mojej organizacji wielokrotnie były podejmowane próby wprowadzenia Scruma,jednak zawsze kończyły się fiaskiem. O sprint planningu, sprint review

czy retrospektywie nie było mowy. Jedynym elementem, który łączył nasząorganizację ze Scrumem, były Daily Stand-Upy. Czy bez najważniejszych zdarzeń,

takich jak sprint planning lub retrospektywa, istnieje możliwość pomyślnegowprowadzenia Scruma? Czy każdy sprint zawsze musi zawierać najważniejsze

zdarzenia, czy też któreś z nich może zostać pominięte w trakcie realizacji sprintu?

Natalia Misko

Moja odpowiedź jest krótka: tak, każdy sprint w Scrumie musi zawieraćwszystkie zdarzenia, które wymieniłaś, i nie tylko te. Oprócz samych zdarzeńmamy jeszcze konkretne role (Scrum Master, Właściciel Produktu, Zespół De-weloperski), artefakty (Backlog Produktu, Backlog Sprintu, Przyrost Produktu)oraz reguły, które „sklejają” wszystkie te elementy w całość. To wszystko ra-zem wzięte wyznacza ramy działania (ang. framework) dla zespołów projekto-wych. Jeżeli te elementy stosowane są wybiórczo, nie powinniśmy tego, co ro-bimy, nazywać Scrumem. To trochę tak jak z grą w piłkę nożną. Podczasmistrzostw Europy nikt nie rozgrywa meczu, mając tylko jedną bramkę na bo-isku, albo gra tylko czterema zawodnikami. Wszyscy wiemy, ze muszą byćdwie bramki, a drużyn musi być dwie — każda z nich musi się składać z jede-nastu zawodników. Bo tak mówią zasady gry, określone przez InternationalFootball Association Board (IFAB). Jeżeli nie będziemy się stosować do tych reguł,nie możemy mówić, że rozgrywamy mecz piłki nożnej, my tylko kopiemyw piłkę lub gramy w „nogę.

Ze Scrumem jest bardzo podobnie. Jeżeli chcecie faktycznie wykorzystaćprofity, które niesie ze sobą stosowanie tej metody, nie ma zmiłuj: szkieletScruma musi być zastosowany. Owszem, możecie ze zdarzeń scrumowychstosować tylko spotkania „na stojaka”, czemu nie. Na pewno ta praktyka przy-niesie Wam sporo korzyści (np.: usprawni komunikację, scementuje ze-spół, zwiększy przejrzystość pracy itp.). Ale znowu, odnosząc to do Scruma,

SCRUMOWO-PYTAJNIKOWO

29

trzeba mieć w tyle głowy, po co zostały wprowadzone codzienne scrumy. Tojest najniższy poziom planowania pracy w sprincie. Na początku wychodzimyod planowania produktu (wizja, cele biznesowe), potem schodzimy na poziomkonkretnego wydania lub projektu, następnie mamy planowanie sprintu i,jakby tego było mało, planujemy codziennie. I to ma głęboki sens. A jeżeli terazz całego naszego planowania zostają nam tylko codzienne scrumy, nagle bra-kuje w tej układance szerszego kontekstu, nie mamy horyzontu.

I tak naprawdę, nie ma znaczenia, jaką metodę wprowadzicie w swojej fir-mie — Scrum, XP, FDD, DSDM czy Holokrację. Bez dyscypliny i konsekwencjiniczego nie osiągniecie. Nie zmienicie swojej organizacji.

Ale Twoje pytanie dotyka jeszcze jednego ważnego tematu. Bardzo częstoprzy różnych okazjach słyszę od ludzi: „Wiesz… u nas w firmie to jest taki pół-Scrum. No wiesz, taka wersja stuningowana”. Wtedy pytam, co to znaczy.Część osób odpowiada, że nie stosuje określonych elementów Scruma. No cóż,wtedy to faktycznie nie jest Scrum. Ale jest też spora grupa, która mówi, że sto-suje wszystkie praktyki, ale nie używa historyjek użytkownika albo szacujew osobodniach zamiast w punktach. I tutaj — powiem stanowczo — to jest jaknajbardziej Scrum, a nie jakaś jego niepełna wersja . Zauważyłem, że wieleosób, nie odróżnia reguł Scruma od ogólnie przyjętych praktyk w Scrumie (OPPS),o których pisałem w jednym z porzednich wpisów. Scrum wcale nie narzucazespołom, w jaki sposób mają zbierać wymagania lub jakich jednostek szaco-wania powinny używać. Tego typu praktyki w żadnym wypadku nie są wy-znacznikiem tego, czy to, co robicie, jest Scrumem, czy nie. Dobrze jest o tympamiętać i czasem, trochę bardziej, się dowartościować.

MARIUSZ CHRAPKO

30

6. CZY PROJECT MANAGER MOŻE BYĆSCRUM MASTEREM?

Czy project manager może być Scrum Masterem w Zespole Scrumowym?

Natalia Misko

Bardzo dobre pytanie, dzięki! Ten temat od zawsze wzbudza sporo kontrower-sji. Całe zamieszanie wzięło się stąd, że w Scrumie nie ma roli project manage-ra. Podobnie jak nie ma roli menedżera liniowego, dyrektora departamentu,CEO czy kogokolwiek innego. Tak samo zresztą jest z pojęciem „projektu”,o którym Scrum bezpośrednio nie wspomina. Co nie znaczy, że w zwinnychmetodach projekty w ogóle nie istnieją.

Jedna z najbardziej typowych definicji projektu, które znam, brzmi nastę-pująco:

Projekt to ograniczone w czasie przedsięwzięcie, zmie-rzające do osiągnięcia określonego celu.

No przecież to właśnie w Scrumie robimy: realizujemy ograniczone w czasieprzedsięwzięcia, które zmierzają do wytworzenia określonego produktu, do-starczenia usługi lub rozwiązania złożonego problemu. Do tego właśnie zostaławymyślona ta metoda. Każdy sprint jest pewnego rodzaju projektem, któryzmierza do osiągnięcia określonego wyniku (cel sprintu) i jest ograniczonyw czasie (maksymalnie 30 dni).

SCRUMOWO-PYTAJNIKOWO

31

I teraz żeby skutecznie realizować takie „projekty”, potrzebujemy trzech ról:właściciela produktu, scrum mastera i zespołu deweloperskiego.

Właściciel Produktu jest odpowiedzialny za wszystkie aspekty biznesowerealizowanych w Scrumie przedsięwzięć. Formułuje i komunikuje wizjęproduktu oraz zapewnia, że produkt jest budowany w odpowiedniejkolejności (maksymalizacja wartości biznesowej). Właściciel produktuaktywnie współpracuje z zespołem deweloperskim i scrum masterem.Jest samodzielny i decyzyjny we wszystkich aspektach związanychz rozwojem produktu.

Scrum Master dba o to, żeby zespół stosował wartości, zasady i praktykiScruma. Jest coachem zespołu. Usuwa przeszkody, które utrudniająefektywną pracę zespołu. Facylituje spotkania scrumowe, jeśli zespóło to poprosi lub zaistnieje taka potrzeba. Wspiera właściciela produktuw efektywnym zarządzaniu rejestrem produktu.

Zespół Deweloperski jest interdyscyplinarny i sam organizuje swojąpracę w sprincie. Członkowie zespołu sami decydują o tym, jak zdefiniujązadania, jak podzielą pracę. To jest całkowicie ich „broszka”.

Co się stało z rolą project managera w Scrumie?Jak łatwo zauważyć, roli project managera (PM) jako takiej w Scrumie nie ma.Czy to jednak oznacza, że obowiązki, które normalnie wykonywał tradycyjniePM, odchodzą do lamusa? Bynajmniej.

Tradycyjnie project manager miał całkiem sporo ważnych obowiązków,które były bardzo potrzebne z punktu widzenia realizacji projektów. Czuwałnad realizacją celów projektu. Zarządzał czasem, budżetem i zakresemprojektu. Identyfikował i minimalizował ryzyko. Monitorował postęp pracw projekcie. Zarządzał interesariuszami projektu. Dbał o dobry przepływinformacji w zespole projektowym. Rozdzielał pracę (tzw. Work BreakdownStructure, w skrócie WBS).

W projektach agile wszystkie dotychczasowe obowiązki PM-a są podzielone,głównie między rolę Właściciela Produktu i Scrum Mastera.

MARIUSZ CHRAPKO

32

Agile PM w dużych organizacjachO ile model podziału obowiązków tradycyjnego PM-a między Właściciela Pro-duktu a Scrum Mastera bardzo dobrze się sprawdza w małych projektach, któ-re liczą do 30 osób, o tyle przy dużych przedsięwzięciach, w których zaanga-żowanych jest nawet do 600 osób, takie podejście nie zdaje egzaminu. Przedewszystkim mamy do czynienia z naprawdę dużym Backlogiem Produktu, któ-ry jest rozwijany przez dziesiątki zespołów scrumowych. Pojawia się dużo za-leżności — i to nie tylko na poziomie zespołów, ale także dostawców i otocze-nia zewnętrznego w postaci innych projektów czy programów. To wszystkowymaga dodatkowych punktów koordynacji. I do tego właśnie potrzebny jestAgile PM, którego zakres obowiązków niewiele różni się od tradycyjnego PM-a, chociaż jest w pewnych aspektach mocno ograniczony. Agile PM nie roz-dziela np. zadań w projekcie, to robi zespół, który sam organizuje swoją pracęw sprincie. Agile PM nie zarządza także zakresem projektu, co robi WłaścicielProduktu. Jego rola polega więc raczej na koordynowaniu projektu — zarzą-dzaniu budżetem, rozliczaniu dostawców, identyfikowaniu i minimalizowaniuryzyk w projekcie (we współpracy z zespołem), śledzeniu przebiegu projektu,komunikowaniu się z interesariuszami projektu.

SCRUMOWO-PYTAJNIKOWO

33

Czy project manager może odgrywać rolę Scrum Mastera?Po tym wstępie mogę się wreszcie zabrać za odpowiadanie na Twoje pytanie,Natalio. Krótka odpowiedź: tak, może. Jednak odradzam to. W większości wy-padków, kiedy stosowałem takie rozwiązanie u klientów, najczęściej słabo sięto sprawdzało. Chociaż oczywiście znam kilka przypadków, kiedy taka tranzy-cja z project managera na Scrum Mastera przebiegła bezboleśnie i PM spraw-dził się znakomicie w roli Scrum Mastera. To i tak, koniec końców, zależy odosoby. Jeżeli tylko jesteś świadoma wyzwań, które wiążą się ze zmianą roliPM-a na Scrum Mastera, powinnaś spróbować. I bardzo możliwe, że Ci się uda.

I może jeszcze jedna rzecz. Z Twojego pytania nie wynika jednoznacznie,na czym takie łączenie roli PM-a i SM-a miałoby polegać. Jeżeli chciałabyś byćScrum Masterem i jednocześnie project managerem, zdecydowanie odradzam.Podstawowa trudność polega na przechodzeniu z roli PM-a w rolę SM-aw konkretnych sytuacjach projektowych. To jest też duże wyzwanie dla ludziz zespołu. Kiedy mówisz jako PM, a kiedy jako SM? Kiedy jesteś coachem,a kiedy koordynatorem? Kiedy używasz sankcji, a kiedy procesu? Jest bardzoprawdopodobne, że w takiej schizofrenii z czegoś będziesz musiała zrezygno-wać — jestem prawie pewny, że z roli SM-a. Jeżeli chcesz w swojej firmieutrzymać rolę Project Managera, bo faktycznie jest potrzebna, to dużo lepszymrozwiązaniem jest połączenie jej z rolą Właściciela Produktu, przy założeniu żeTwoja organizacjach nie jest duża i takie „małżeństwo” jest do pogodzenia.Zanim jednak zdecydujesz się na konkretne rozwiązanie, przemyśl dobrze tesytuacje, o których wspominałem.

Dlaczego odradzam łączenie roli project managerai Scrum Mastera?Jest coś takiego, co nazywam „skażeniem menedżerskim”. Nazwa może niejest najlepsza, ale bardzo dobrze oddaje to, co mam na myśli.

Rok temu prowadziłem wdrożenie w dużej zagranicznej korporacji. Trafiłmi się bardzo fajny zespół pilotażowy, łącznie z menedżerem liniowym, któryzarządzał kilkoma zespołami w tej firmie. Pamiętam, że spędziłem z nim cał-kiem sporo czasu, żeby pomóc mu jakoś odnaleźć się w tej nowej zwinnej rze-czywistości. Rozmawialiśmy, odgrywaliśmy różne scenki. Był Niemcem, więcnaprawdę chciał się do tej całej zmiany dobrze przygotować. I mija pierwszysprint, siedzimy na pierwszej retrospektywie, zespół zgłasza listę rzeczy, które

MARIUSZ CHRAPKO

34

nie wyszły w sprincie i… co robi „agile manager”? Bardzo konkretnie, bezogródek, mówi zespołowi, co powinien zrobić, żeby takich sytuacji uniknąćw przyszłości. Używał przy tym bardzo menedżerskich zwrotów: „Oczekuję,że zrobicie to tak i tak…” albo „Musimy to zrobić w ten sposób…”.

„Skażenie menedżerskie” nie jest niczym złym. Każdy menedżer przez lataswojej pracy w organizacji buduje pewne nawyki, które różnią się od tychpromowanych w projektach agile. Składa się na nie konkretny język (nakazo-wy) i zachowania, których wcale nie jest tak łatwo się oduczyć. I czasem musiupłynąć całkiem sporo czasu, żeby taka istotna zmiana mogła się dokonać.

Kącik kujonaNa koniec polecam kilka książek, które pomogą Ci trochę bardziej zgłębić te-mat zarządzania projektami w agile. Wybrałem trzy:

„Extreme Project Management”, Douglas de Carlo. To jest jednaz fajniejszych książek o zarządzaniu projektami, jakie czytałem.Mimo że autor słowem nie wspomina o zarządzaniu projektami w agile,jego książka jest bardzo agile’owa. Często do niej wracam.

„Agile Project Management: Creating Innovative Products”, JohnHigmisth. To jest chyba pierwsza książka o zwinnym zarządzaniuprojektami, którą przeczytałem. Każdy rozdział zaczyna się krótkąrozmową między tradycyjnym PM-em i agile project managerem.I te krótkie dialogi oddają istotę problemów, z którymi w zwinnymzarządzaniu PM-owie muszą się mierzyć. Poza tym jest tutaj sporopraktycznych wskazówek, które przy wchodzeniu na zwinną ścieżkęprojektową mogą się przydać. Jest także polskie wydanie tej książki,jednak tłumaczenie, jak w przypadku wielu podobnych publikacji,pozostawia wiele do życzenia.

„Managing Agile Projects”, Sanjiv Augustine. W tej książce dużo jestmyślenia systemowego, za co ją szczególnie cenię. Poza tym jest w niejpokazane, na czym polega rola agile PM-a, jakie ma obowiązki, takżew kontekście zespołu projektowego. Dodatkowo ciekawie jest opisanysam proces wdrożenia agile w firmie.

Polecam!

SCRUMOWO-PYTAJNIKOWO

35

7. CZY PROJEKTY AGILE DA SIĘ ZAPLANOWAĆ?

Chciałbym zapytać o faktyczną rolę Product Backlogu, jego pielęgnowaniei oszacowywanie zadań.

Co w sytuacji, w której środowisko pracy jest bardzo zmienne i nagle okazuje się,że wstępne szacunki nie przystają do wcześniejszych ustaleń? Szacowanie

i wyznaczanie na podstawie ogólnej wiedzy jakichkolwiek długoterminowychplanów opiera się na założeniach, które mogą się mieć nijak do niepewności

i zmienności jaka towarzyszy produkcji oprogramowania?

Szacunki te mają spory wpływ na planowanie najbliższego sprintu. Czy WłaścicielProduktu powinien zadbać o to, aby Zespół Deweloperski rozumiał w 100%

wymagania biznesowe i wspólnie mogli jak najlepiej oszacować wysiłkidługoterminowe dotyczące Backlogu Produktu? Nawet kosztem kilku godzin pracyw ramach każdego sprintu? Czy może jednak źle o tym myślę i rejestr produktu jest

obietnicą dla innych interesariuszy, ale tylko tymczasową, z natury zmienną?A może w takim środowisku Scrum nie będzie najlepszym wyborem i sugerowałbyś

inne rozwiązania?

Maciej Malak

Maćku! Na początku jedna bardzo ważna uwaga. Agile powstał właśnie poto, żeby sobie radzić ze zmiennym środowiskiem pracy i, w trakcie trwaniaprojektu, może stać się właśnie tak, jak napisałeś: „wstępne szacunki nie przy-stają do wcześniejszych ustaleń”. Tworzenie oprogramowania ze swej naturyjest procesem twórczym i bardziej przypomina powstawanie dzieła sztuki niżhamburgera w McDonaldzie. Na etapie startu projektu mamy tylko konkretnecele, które chcemy zrealizować. Wymagania, podobnie jak szczegóły malowa-nego obrazu, rozwijane są w kolejnych odsłonach (iteracjach), po których do-starczane są kawałki działających części (inkrementy). Wymagania w projek-tach IT przypominają trochę szkice artysty, które stopniowo odsłaniają sięw kolejnych krokach implementacji. Przez cały czas trwania projektu pewne sątylko cele, które chcemy osiągnąć. Reszta jest w ciągłym ruchu i twórczymnapięciu. Taki proces jest zgodny z naturą projektów IT, w ramach których

MARIUSZ CHRAPKO

36

tworzymy (sic!) software. Kolejne części powstającej aplikacji prowokują, po-budzają naszą kreatywność, generują kolejne pomysły, uczą. Taki jest agile!

Jak w takim razie zarządzać takimi projektami? Czy projekty agile możnaw ogóle sensownie zaplanować? Co z szacunkami? Co założeniami długoter-minowymi? W Twoim mailu pojawiło się kilka bardzo zasadnych pytań, które„niepokoją” wielu project managerów.

Biorę się za odpowiedzi :).Tak. Projekty agile’owe da się sensownie zaplanować. Zanim, Maćku, od-

powiem na Twoje pytania, najpierw przedstawię sześć sprawdzonych krokówplanowania projektów agile, które na co dzień stosuję u moich klientów. My-ślę, że po ich przeczytaniu przynajmniej część Twoich wątpliwości zostanierozwiana.

Krok 1: ustal, co jest do zrobieniaZaczynamy trochę jak w projektach kaskadowych — próbujemy zbudować li-stę funkcjonalności, które powinny się pojawić w naszym projekcie. Różnicapolega na tym, że nasza lista nie jest kompletna. Wymagania mogą się zmie-niać w trakcie trwania projektu i to jest zupełnie normalne. Chcemy, żeby takbyło, bo na tym polega proces tworzenia. I tu mamy pierwsze nieporozumie-nie. Skoro wymagania są zmienne, jak w takim razie mamy zaplanować pro-jekt? Co z harmonogramem projektu? Na kiedy to wszystko będzie gotowe?Tych i podobnych pytań możemy się spodziewać od naszych klientów, któ-rych na pewno będzie jeszcze interesowało, ile to wszystko będzie kosztować.I tutaj dochodzimy do bardzo ważnej kwestii. Agile wcale nie oznacza, że pla-nowanie „długoterminowe” w ogóle nie istnieje i wszystko zaczyna się i koń-czy na pojedynczym sprincie, a reszta to wielka niewiadoma. Tak nie jest.

Planowanie w projektach zwinnych odbywa się na kilku poziomachi przypomina trochę obieranie cebuli. Stopniowo, krok po kroku, ściągamy ko-lejne warstwy. Sporo nieporozumień związanych z planowaniem projektówagile bierze się stąd, że skupiamy się głównie na środkowych warstwach cebu-li: planowanie na poziomie sprintów i codziennych stand-upów. Pozostałeelementy się nie liczą. Zostawiamy je organizacji. Tymczasem wszystkie zało-żenia „długoterminowe” dotyczą tego, co się dzieje poza horyzontem danegosprintu — na poziomie konkretnego wydania. Do tego warto jeszcze dodać, że„długoterminowość” nie jest tutaj rozumiana tak jak w projektach kaskado-wych, gdzie oznaczała naprawdę długi horyzont planowania, np. dziewięciu

SCRUMOWO-PYTAJNIKOWO

37

i więcej miesięcy. „Długoterminowość” w projektach zwinnych to perspekty-wa kilku sprintów — w praktyce najczęściej sprowadza się do jednego, dwóchlub trzech miesięcy.

Co robimy na poszczególnych poziomach planowania?

Planowanie wydania. Rozmawiamy o celach biznesowych, które chcemyosiągnąć. Dyskutujemy podstawowe ograniczenia projektu: budżet,harmonogram, zakres. Wybieramy konkretne tematy oraz historyjki, którechcemy zaimplementować. Rozmawiamy o ich priorytetach. Próbujemytakże oszacować wielkość pracy, jaką mamy do wykonania. Ile nam tozajmie? Wreszcie, tworzymy plan wydania, do którego później wracamy— aktualizujemy go, odsłaniając kolejne warstwy.

Planowanie sprintu. Na tym etapie planujemy mniej. Bo mniejszy też jesthoryzont planowania (dwa – cztery tygodnie). Zespół zastanawia się,ile w tym czasie jest w stanie zrobić. Właściciel Produktu opowiadao priorytetach, o tym, jakie historyjki powinny znaleźć się w planiesprintu. Zespół zastanawia się, jak podzielić pracę na konkretne zadania.

Codzienne planowanie. Mimo że jest ono bardzo nieformalne, jednak mabardzo duże znaczenie dla koordynacji pracy. Zespół codziennie zbiera sięna krótkie, piętnastominutowe spotkania, żeby zsynchronizować swojeprace. Wszelkie odchylenia od planu są na bieżąco korygowane.

MARIUSZ CHRAPKO

38

Założenia „długoterminowe” dotykają planowania na poziomie kolejnych wy-dań produktu, a nie sprintów. Kiedy uruchamiamy jakąś inicjatywę w firmie,na początku mamy najczęściej tylko listę określonych pomysłów i wizji, z któ-rych za chwilę wyłoni się Backlog Produktu. Powstanie jego zarys — szkielet,który stopniowo będziemy wypełniać nowymi elementami. Na co dzień zwy-kle dzieje się to w ramach sesji pielęgnacyjnych w sprincie (projekty bieżące)lub w trakcie przygotowywania się do uruchomienia sprintu 1.

Efektem tych prac jest pierwsza wersja planu naszego projektu, która wy-znacza kierunek dalszych działań. Jak pokazuje rysunek poniżej, na samejgórze tej układanki są jakieś tematy strategiczne, którymi chcemy się zająćw naszym projekcie. Tematy z kolei grupują epiki — a więc duże historyjkiużytkownika, które wymagają dalszej dekompozycji na mniejsze fragmentypracy. Sam zakres release’u składa się z historyjek użytkownika, które są reali-zowane w kolejnych sprintach. Może to wyglądać np. tak jak przedstawia ry-sunek poniżej.

Przy konstruowaniu planu wydania nie ma sensu planować wszystkich sprin-tów od A do Z, bo czy to kolejność, czy same wymagania w backlogu mogą sięzmienić. Tak zwane planowanie do przodu (np. dwóch – trzech sprintów)ma jednak sens, gdy mamy do czynienia z zależnościami między zespołami lubzewnętrznymi dostawcami, co w dużych organizacjach jest na porządkudziennym.

Podsumowując ten krok: mamy więc listę tematów strategicznych, któretworzą coś na wzór kręgosłupa produktu. Potem powstaje jego szkielet (epiki)oraz historyjki, które go „wypełniają”.

SCRUMOWO-PYTAJNIKOWO

39

Krok 2: oszacuj wielkość historyjekMamy wstępną listę funkcjonalności w projekcie, którą teraz trzeba oszacować.Pamiętajmy, że cały czas mówimy o planowaniu wydania, a nie konkretnegosprintu. Do szacowania używamy punktów (ang. story points) lub osobodni.Nie polecam idealnych godzin, które z kolei bardzo dobrze sprawdzają siępodczas planowania sprintu.

Krok 3: określ długość sprintuNa początku kiedy zaczynamy swoją przygodę ze zwinnością, długość sprintumoże się zmieniać. Zespół eksperymentuje, uczy się, jakie podejście jest opty-malne do jego pracy. Potem, żeby lepiej planować pracę na poziomie projektu,dobrze jest, gdy długość sprintu jest stała. To też wpływa na podtrzymaniestałego rytmu pracy w projekcie.

Krok 4: ustal priorytetyWłaściciel Produktu porządkuje elementy w backlogu produktu. Często wspie-ra się przy tym radą i pomocą zespołu, którego doświadczenie może się bardzoprzydać. Poza tym jest jeszcze otoczenie projektu (inne projekty, programy,dostawcy), które również mają znaczenie przy ustalaniu priorytetów backlogu,szczególnie w dużych organizacjach.

Krok 5: jaka jest prędkość zespołu?Żeby dobrze zaplanować projekt, musimy wiedzieć, ile jednostek pracy (punktylub osobodni) zespół średnio „spala” w sprincie. Prędkość zespołu oraz długośćsprintu będą nam potrzebne do kolejnego punktu, w którym wreszcie po-wstanie wstępny plan naszego projektu i harmonogram.

Krok 6: wybierz historyjki i ustal datęI tutaj dochodzimy do najważniejszego momentu. Musimy wiedzieć, jakiego ty-pu jest nasz projekt. Czy bardziej zorientowany na datę, czy może na konkretne

MARIUSZ CHRAPKO

40

funkcjonalności. W każdym przypadku podejście do planowania będzie trochęinne.

Projekty typu „fixed-date”To jest sytuacja, w której data wydania jest stała. Ale możemy „manipulować”liczbą dostarczanych funkcjonalności. Może się np. okazać, że po dwóch mie-siącach pojawi się jakaś superważna historyjka, która na bank musi wejść dowydania. Nie ma problemu! Dodajemy nową, zabieramy starą. To oczywiściewpływa na ustalony zakres prac w projekcie.

Planowanie projektów typu „fixed-date” składa się z trzech kroków:

1. Ustal liczbę sprintów. Znamy datę wydania. Przyjmijmy, że jest to30 czerwca. Załóżmy też, że długość naszych sprintów to jeden miesiąc.Bierzemy teraz do ręki kalendarz (oczywiście aktualny) i liczymy.Do zakończenia wydania mamy sześć sprintów.

2. Oszacuj prędkość zespołu i wyraź ją za pomocą skali. Nie interesuje naswartość punktowa. Chcemy wiedzieć, ile punktów zespół „wypali”w najlepszym i najgorszym wypadku. Powiedzmy, że prędkośćpesymistyczna to 15 punktów, a optymistyczna 20.

3. Oszacuj możliwą liczbę punktów dostarczonych w wydaniu.Pamiętajcie, że cały czas musimy brać pod uwagę ten dobry i złyscenariusz. Zakładając, że zespołowi nie będzie sprzyjał dobry los,mnożymy liczbę sprintów (6) przez prędkość pesymistyczną

SCRUMOWO-PYTAJNIKOWO

41

(15 punktów). W ten sposób dowiemy się, ile punktów łącznie zespółbędzie mógł dostarczyć w planowanym wydaniu. Oczywiście są towartości szacunkowe. Niemniej na ich podstawie możemy bezpiecznieprzyjąć, że historyjki, których łączna wielkość odpowiada wyliczonympunktom, raczej na pewno zostaną dostarczone w wydaniu XY. Podobnąkalkulację stosujemy dla prędkości optymistycznej. W ten sposób wiemy,ile dodatkowych funkcjonalności zespół będzie mógł zrealizować,zakładając, że będą mu sprzyjać bóstwa.

Planowanie wydania w projektach typu "fixed-date"

Projekty typu „fixed-scope”Tutaj z kolei jesteśmy trochę bardziej elastyczni, jeśli chodzi o datę. Ustalamyz klientem listę najważniejszych funkcjonalności, które muszą zostać dostar-czone. Jednocześnie akceptujemy pewne ryzyko związane z datą wydania.

MARIUSZ CHRAPKO

42

W tym podejściu strategia postępowania jest odrobinę inna niż w projektachzorientowanych na datę. Tym razem musimy wykonać trochę inny zestawkroków:

1. Ustal, co jest do zrobienia. Wspólnie z Właścicielem Produktu próbujemyzbudować listę wszystkich funkcjonalności, które chciałby zobaczyćw najbliższym wydaniu.

2. Oszacuj wielkość wybranych funkcjonalności. Mamy już listętematów/epików, które bezwzględnie muszą się znaleźć w planowanymwydaniu. Dekomponujemy je na historyjki użytkownika i szacujemy.

3. Oszacuj prędkość zespołu i wyraź ją za pomocą skali. Do tej porystrategia postępowania jest identyczna jak przy planowaniu dowolnegowydania. Szacujemy więc, ile jesteśmy w stanie przyjąć w sprincie.Załóżmy, podobnie jak w poprzednim przykładzie, że prędkośćoptymistyczna wynosi 15 punktów, a pesymistyczna 20.

4. Oszacuj datę wydania. Żeby to zrobić, musimy obliczyć wielkośćwszystkich planowanych funkcjonalności. Załóżmy, że wyszłonam 120 punktów. Teraz, tę liczbę dzielimy przez optymistycznąi pesymistyczną wartość prędkości zespołu. W ten sposób dowiadujemysię, kiedy najwcześniej i najpóźniej skończymy projekt.

Planowanie wydań w projektach typu „fixed-scope”

Po tym wstępie raz jeszcze wracam do Twojego pytania, Maćku:Co w sytuacji, w której środowisko pracy jest bardzo zmienne i nagle

okazuje się, że wstępne szacunki nie przystają do wcześniejszych ustaleń? Sza-cowanie i wyznaczanie na podstawie ogólnej wiedzy jakichkolwiek długoter-minowych planów opiera się na założeniach, które mogą się mieć nijak do nie-pewności i zmienności, jaka towarzyszy produkcji oprogramowania?

SCRUMOWO-PYTAJNIKOWO

43

Jak widzisz, zmiana założeń długoterminowych nie jest czymś złym i,w pewnym sensie, na to się godzimy, gdy idziemy zwinną ścieżką. Z drugiejstrony nie jest też tak, że agile niesie ze sobą totalne rozpasanie, jeśli chodzio prowadzenie projektu. Istnieją bardzo konkretne reguły planowania pracyi każda decyzja związana ze zmianą założeń „długoterminowych” ma swojekonsekwencje, z którymi trzeba się liczyć. Zmiana zakresu w projektach typu„fixed-date” może skutkować np. tym, że nie zrealizujemy pierwotnego planu.W zamian za to zrealizujemy jednak plan, który bardziej odpowiada bieżącympotrzebom biznesowym. Podobnie jest w projektach typu „fixed-scope”,w przypadku których zmiana wymagań może skutkować, np. zmianą daty„wypuszczenia” produktu na rynek. W zamian za to zbudujemy jednak pro-dukt, który będzie się składał z najbardziej wartościowych funkcjonalności. Ta-kie podejście zawsze bardzo się opłaca.

I jeszcze druga część Twojego pytania:Szacunki te mają spory wpływ na planowanie najbliższego sprintu. Czy

Właściciel Produktu powinien zadbać o to, aby Zespół Deweloperski rozumiałw 100% wymagania biznesowe i wspólnie mogli jak najlepiej oszacować wysił-ki długoterminowe dotyczące Backlogu Produktu? Nawet kosztem kilku go-dzin pracy w ramach każdego sprintu?

Tak. Właściciel Produktu powinien zadbać o to, żeby Zespół Deweloperskidobrze rozumiał jego wizję i cele biznesowe, które chce osiągnąć w projekcie.Taka jest m.in. jego rola: czytelne artykułowanie elementów backlogu oraz za-dbanie o to, żeby zespół wiedział, co ma robić. Co do zaangażowania zespołuw formułowanie założeń długoterminowych, zespół również powinien w tymuczestniczyć, np. poprzez:

wspólne (z Właścicielem Produktu) pisanie epików i historyjek(warsztaty);

szacowanie pracy (sesje estymacyjne); dyskutowanie o rozwiązaniach technicznych; analizę możliwych zależności i kolejności elementów Backlogu Produktu.

Nie wyobrażam sobie, żeby prace planistyczne na poziomie projektu odbywałysię „za plecami” zespołu.

***Dziękuję za bardzo dobre pytanie. Gdybyś miał jeszcze jakieś wątpliwości, piszśmiało na adres: me@mariuszchrapko.com. Będę odpowiadał ;)