Piszę książkę o sprawdzonych sposobach na pułapki w Scrumie #labiryntyscruma

Od kilku miesięcy skupiam się niemal wyłącznie na najważniejszym dla mnie projekcie w 2017 roku – książce, w której dzielę się sprawdzonymi sposobami na najczęstsze pułapki w Scrumie. Nazwałem ją “Labirynty Scruma”, właśnie zbieram feedback od recenzentów i planuję ją wydać w modelu self-publishing. Zacznijmy jednak od początku, czyli od pytania “why”.

Dlaczego piszę książkę?

Wspierając pracę w Scrumie w mocno różniących się od siebie organizacjach, dostrzegam bardzo podobne problemy. Często można to skrócić do podsumowania, że “Scrum nie działa”. To znaczy, że uzyskiwane efekty najczęściej rozmijają się z oczekiwaniami osób, które inicjują, wspierają lub sponsorują zmianę.

Dlaczego tak się dzieje? Moje doświadczenie jest takie, że najczęściej brakuje praktycznej wiedzy o tym, jak korzystać ze Scruma – czyli technik, podejść, sposobów oraz metod. Nie oznacza to, że nie dostrzegam problemów związanych z samym procesem przeprowadzania zmiany, kultury organizacyjnej, wartości czy postaw. Po prostu wspomniany wcześniej brak wiedzy oraz doświadczenia rzuca mi się w oczy najbardziej.

Przykłady? Proszę bardzo. Codzienny Scrum to nudne spotkanie statusowe, Scrum Master zachowuje się jak sekretarka, Product Backlog nie jest przygotowany do Planowania Sprintu a na Przeglądzie Sprintu zespół nie pokazuje niczego namacalnego. Kolejne antywzorce, problemy oraz pułapki mogę mnożyć niemal w nieskończoność.

W ciągu ostatnich kilku lat większość tego rodzaju problemów miałem okazję doświadczać oraz rozwiązywać na różne sposoby. Pracowałem jako Scrum Master, Agile Coach oraz manager z kilkudziesięcioma różnymi zespołami scrumowymi w różnych firmach. Nie spotkałem zespołu, który nie borykałby się z mniejszymi lub większymi problemami, niezależnie od poziomu ich zaawansowania.

W pewnym momencie zacząłem dostrzegać pewną powtarzalność – tzn:

  1. Obserwuję problem (hmm, coś nie tak z tym Daily Scrumem)
  2. Identyfikuję go (no tak, wygląda raczej jak raportowanie statusu prac)
  3. Rozumiem jego konsekwencje (przez to nie powstanie plan na najbliższe 24h)
  4. Mam pewien wachlarz sprawdzonych rozwiązań, które mogę zaproponować i zastosować (np. usunąć odbiorcę raportu z pola widzenia i porozmawiać o tym czym i dla kogo jest Daily Scrum)

Kiedy dotarło do mnie, że być może jest to wartościowy materiał, postanowiłem przelać to wszystko na papier, chociaż zupełnie nie myślałem wtedy o książce.

Jak powstaje książka?

Na początku powstała pierwsza mindmapa, która pomogła mi uporządkować najczęstsze problemy w Scrumie z podziałem na Zdarzenia Scrumowe. Na tej podstawie przygotowałem prezentację, którą przedstawiłem podczas jednej z sesji “Agile Lighting Talk” w STX Next. Mając wspomnianą prezentację w ręku, omówiłem pomysł napisania cyklu artykułów na temat najpopularniejszych antywzorców w Scrumie z zespołem agile247.pl. Informacja zwrotna, jaką otrzymałem, brzmiała mniej więcej “Jacek, lecisz z tym tematem” #jestpaliwo

Pierwsza wersja mindmapy z antywzorcami - niebawem podzielę się wersją bardziej czytelną

Pierwsza wersja mindmapy z antywzorcami. Niebawem podzielę się wersją bardziej czytelną, ponieważ ta jest już nieaktualna jeśli chodzi o treść.

Dzisiaj, kiedy patrzę na ten surowy materiał, widzę gotową książkę, którą wystarczy rozbudować, oszlifować i wydać. Co ciekawe, zajęło mi ponad rok, żeby dostrzec ten potencjał. Do podjęcia finalnej decyzji “piszę książkę” zainspirował mnie Kuba, z którym miałem okazję przegadać ten temat podczas wspólnej podróży powrotnej z Warszawy do Poznania.

Wydało mi się całkiem naturalne, żeby do pisania książki wykorzystać narzędzia, które na codzień uważam za wartościowe: persony, story mapping, Product Vision, burndown chart czy tablica obrazująca postęp prac.

Przykładowo, poniższy burndown chart pomaga mi określić, ile pracy pozostało do ukończenia książki. Jest też świetnym narzędziem motywacyjnym. Nie jest to jednak narzędzie idealne. Po pierwsze, poziom 180 stron określiłem nieco na wyczucie, więc jest to wyłącznie pewne przybliżenie. Druga sprawa – wykres pokazuje wypalanie stron, nie pokazuje jednak pracy, która pozostaje do wykonania, czyli poprawek na bazie feedbacku od recenzentów.

Wykres spalania obrazujący tempo pisania książki #upadki #wzloty

Wykres spalania obrazujący tempo pisania książki #upadki #wzloty

Z kolei tablica pokazuje to, czego nie widać na wykresie – status poszczególnych rozdziałów. Tutaj już jasno widzę, który rozdział jest do napisania, który jest u recenzentów, a który muszę poprawić po uzyskaniu feedbacku.

Tablica w Trello obrazująca postęp prac - kliknij, aby powiększyć

Tablica w Trello obrazująca postęp prac – kliknij, aby powiększyć

Co to za książka?

Książka nazywa się “Labirynty Scruma” i opisuje ponad 100 sprawdzonych sposobów na najczęstsze pułapki w Scrumie. Jest skupiona mocno na praktyce – zakładam, że już wiesz co to jest Scrum, znasz Scrum Guide oraz przeczytałeś już jakieś książki o Scrumie.

Na około 180 stronach przedstawiam praktyczne rozwiązania najczęstszych problemów dotyczących:

  • Ról (Scrum Master, Product Owner, Zespół Deweloperski)
  • Zdarzeń scrumowych (Codzienny Scrum, Planowanie Sprintu, Przegląd Sprintu, Retrospektywa Sprintu)
  • Doskonalenia Product Backlogu
  • Artefaktów scruma (Backlog Produktu, Backlog Sprintu, Przyrost)

Całość wzbogacona będzie historiami z mojego doświadczenia oraz doświadczeniami osób, które moim zdaniem mają ciekawe historie do opowiedzenia.

Dla kogo ta książka?

Budując wizję produktu dla książki w pierwszej kolejności pracowałem nad określeniem grupy docelowej. Bardzo generalnie rzecz ujmując, myślałem o osobach, które pracują w Scrumie lub w środowisku, w których Scrum jest stosowany. Wchodzą na większy poziom szczegółów, przygotowałem konkretne grupy odbiorców, w kolejności od największej trafności:

  • Scrum Master – Główna, największa grupa odbiorców. Wierzę, że przy pomocy tej książki jestem w stanie znacząco poszerzyć wiedzę Scrum Mastera, dając mu bardzo konkretną “skrzynkę z narzędziami”. Gdy pracuję ze Scrum Masterami, niemal zawsze jestem w stanie dać od siebie coś (np. trafne pytanie, inną perspektywę, odwzorowanie, poradę, nową technikę, czasem wystarczająco długie milczenie), co powoduje, że słyszę w rewanżu “dzięki”. Nie z każdym mogę jednak podzielić się tą wiedzą osobiście, więc cieszę się, że książka pozwoli mi dotrzeć do Scrum Masterów, z którymi nie mam możliwości pracować f2f #bilokacja
  • Manager : Osoba, która zarządza zespołem, zespołami lub większymi strukturami. Często jest inicjatorem zmian scrumowych i osobą kwestionującą status quo. W sytuacji w której dookoła siebie obserwuje “niedziałającego Scruma”, książka może pomóc mu skutecznie reagować, podsuwając konkretne sposoby na radzenie sobie z popularnymi problemami. Pułapki oraz rozwiązania zawarte w książce mogę też stać się punktem odniesienia w dyskusji “gdzie jesteśmy z naszym Scrumem”.
  • Agile Coach – Zakładam, że osoba w roli Agile Coacha, zna w większości to, co opisuję. Pomimo tego myślę, że książka nadal może zainspirować, odświeżyć spojrzenie lub stać się pewnego rodzaju checklistą, nawet dla doświadczonego Agile Coacha. Przykładowo, może pomóc upewnić się, że pracując z zespołem scrumowym, nie stracił z pola widzenia jakiegoś istotnego aspektu lub perspektywy. Taka książka kucharska, do której sięga się albo po konkretny przepis, albo żeby znaleźć coś, co odpowiada aktualnej potrzebie. A może będzie też – po wcześniejszym przejrzeniu i upewnieniu się, że Wieczorek nie pisze głupot – rekomendować tę książkę swoim podopiecznym? Czas pokaże.
  • Product Owner: podobnie jak w przypadku Scrum Mastera, dla Product Ownera książka może być kolejnym krokiem w pogłębieniu praktycznej wiedzy dotyczącej Scruma. Dużą część porad z książki Product Owner może zastosować samodzielnie (np. te dotyczące pracy z Product Backlogiem oraz samej roli Product Ownera) lub pracować razem ze Scrum Masterem oraz Zespołem Deweloperskim nad usprawnieniem pozostałych obszarów. Co więcej, doświadczałem wielokrotnie sytuacji w której Product Ownerzy chętnie zdobywali wiedzę, która zwykle interesuje bardziej Scrum Mastera – pozwalało im to rozwijać dodatkowe umiejętności (np. podstawy moderacji, techniki pracy z produktem), które pomagały im w codziennej pracy.

A co jeśli jesteś deweloperem, project managerem lub szefem niedużej firmy i interesujesz się Scrumem? Uważam, że nadal znajdziesz w “Labiryntach Scruma” treści, które pomogą Ci lepiej wykorzystać możliwości Scruma, znaleźć inspirację lub podpowiedzieć kolejne kroki do wypróbowania.

Postęp prac

Na dzień dzisiejszy zostały mi do napisania dwa rozdziały, z czego jeden to wstęp do książki. Pozostała praca to wprowadzenie poprawek, które otrzymuję od recenzentów oraz uspójnianie i wygładzanie treści. Gdybym był project managerem, powiedziałbym, że 75% jest zrobione, teraz tylko pytanie, ile mi zajmie zrealizowanie pozostałych 25% ;)

Na dzisiaj, stosując sprawdzoną metodę szklanej kuli, planuję mieć gotowy produkt przed wakacjami tego roku.

Przede mną również wszystkie prace wydawnicze: przygotowanie okładki, wersji do druku oraz wersji elektronicznej. Dodatkowo – jako, że nikt nie zrobi tego za mnie – wszystkie działania promocyjne związane z publikacją książki: artykuły, patronaty, prezentacje, warsztaty itp. Spodziewam się, że przemyślana, targetowana promocja zajmie mi kolejne pół roku. I tym sposobem nawiązuję do początku tego artykułu – jak by na to nie spojrzeć, rok 2017 będzie dla mnie rokiem książki.

Co dalej?

Jeśli chcesz być informowany o postępie prac, zapisz się na newsletter.

Do usłyszenia!

Źródło zdjęcia: https://flic.kr/p/dELbZF

Książka „Jak być dobrym Product Ownerem” za darmo #agile247

"Jak być dobrym Product Ownerem" - darmowa książką od agile247.pl

„Jak być dobrym Product Ownerem” – darmowa książką od agile247.pl

Kilka miesięcy temu, zespół agile247.pl wynajął niedużą salkę na obrzeżach Poznania, aby przeprowadzić spotkanie, które od lat niezmiennie nazywają po prostu „off-site”. Spotykają się od czasu do czasu, aby na żywo omówić najważniejsze tematy związane z funkcjonowaniem portalu. Tego dnia kilka godzin spędzili omawiając pomysły dotyczące dalszego rozwoju brandu i kiedy w pewnym momencie opadli już z sił, usłyszeli z oddali głos: „A może byście tak e-booka wydali?”.

TL;DR – pobierz za darmo e-booka „Jak być dobrym Product Ownerem”

Chociaż do dzisiaj nie wiem czyj to był głos, muszę przyznać, że pomysł był dobry. Tylko co mogłoby być treścią takiej książki? Całkiem sprawnie wybraliśmy materiały dotyczące pracy Product Ownera jako sensowny zalążek książki. Wiedzieliśmy, że jest to wartościowa treść i takie też sygnały otrzymywaliśmy od osób czytający portal. „Przecież to nie może być trudne” pomyśleliśmy wtedy, nie wiedząc tak naprawdę, ile pracy nas czeka.

<tutaj zostawiam przestrzeń, która symbolizuje czas, który upłynął od pomysłu do faktycznego wydania książki> #leadtime #prokrastynacja #regułastudenta

I tak docieramy to tygodnia poprzedzającego Wigilię 2016. Dobrze jest spojrzeć na książkę z perspektywy, kiedy jest już skończona i jedyne co musisz zrobić, to wypuścić w social media informację o tym, że udało się i że książka jest gotowa do pobrania.

Dlaczego warto przeczytać tę pozycję? Ponieważ to zwięzłe, mocno praktyczne wprowadzenie dla osób, które są zainteresowane rolą Product Ownera i chcieliby się dowiedzieć, jak robić to dobrze. Co tak naprawdę robi PO, z czym na codzień się mierzy oraz jakich używa narzędzi. Całość uzupełniliśmy wywiadami z doświadczoną, bardzo różnorodną grupą Product Ownerów, którzy podzielili się z nami swoimi przemyśleniami dotyczącymi tego, jak rozwijać się w tej roli oraz gdzie szukać inspiracji. Polecam, tekst aż kipi od smaczków produktowych.

PS. Dokładnie 5 lat temu opublikowałem na blogu pierwszego posta. Nadal lubię krótkie Sprinty, gdyby ktoś w to wątpił.

PS2. W 2017 będzie więcej książek #staytuned

Budowanie wspólnego zrozumienia #storymapping

Przykład Story Mappingu

Przykład Story Mappingu

Kilka godzin temu zakończyłem warsztaty produktowe. Ich głównym celem było przygotowanie użytecznego oraz wykonalnego rozwiązania, realizującego konkretną potrzebę klienta.

To już któryś raz z rzędu, gdy wychodzę z tego rodzaju warsztatów zafascynowany, jak niesamowicie prostym, a zarazem nadzwyczaj skutecznym narzędziem jest Story Mapping.

Posłużę się prawdziwym przykładem, oczywiście na potrzeby tego wpisu w uproszczonej wersji, aby móc podzielić się z Wami wysokopoziomową ideą oraz przebiegiem samego ćwiczenia.

Co to jest Story Mapping? #podstawy

Gdyby miał opisać Story Mapping jednym zdaniem, to powiedziałby, że jest to narzędzie służące do budowania wspólnego zrozumienia produktu.

Jeśli miał do dyspozycji jeszcze kilka kolejnych zdań, powiedziałbym, że skupienie w trakcie ćwiczenia utrzymywane jest na użytkowniku oraz tym, w jaki sposób będzie korzystał z z produktu. Realizowane jest to poprzez opowiadanie historii użytkownika (czyli popularnych User Stories, wystepujące w życiu zespołów także jako historyjki, storysy oraz storyjki #truestory), dekomponowanie ich na mniejsze części oraz układanie ich w kolejności zgodnej z tym, jak użytkownicy używają systemu.

Główną osią naszej mapy szkielet aplikacji, który odzwierciedla opowieść o tym, w jaki sposób użytkownicy będą z niej korzystać. Szkielet ten uzupełniają zdekomponowane historie, które funkcjonują na niższym poziomie szczegółowości i ułożone są według priorytetów lub odzwierciedlają alternatywne scenariuszy korzystania z produktu.

Dla osób, które chcą głębiej zanurzyć się w temacie Story Mappingu, z czystym sercem rekomenduję książkę Jeff’a Patton’a, który jest autorem tej techniki. Książkę czytam i został mi jeszcze kawałek do dokończenia – w niedalekiej przyszłości napiszę o niej kilka słów na blogu.

Kółka, trójkąty, kwadraty… #komunikacja

Scenariusz warsztatów produktowych jest zazwyczaj bardzo podobny. Zespół wchodzi na warsztat mając dosyć mgliste pojęcie, co tak faktycznie jest do zrealizowania. Często nie wiedzą o produkcie więcej, niż kilka zdań wymienionych poprzez e-maile. Domena produktu bywa obca. Bywa, że w zrozumieniu wyrazów oraz skrótów charakterystycznych dla domeny produktowej nie pomaga nietypowy akcent klienta, charakterystyczny np. dla mieszkańców północnej części Wielkiej Brytanii.

Patrząc z boku na przebieg warsztatu jako moderator, często odnoszę wrażenie, że w głowach uczestników rodzą się kompletnie różne obrazy tego, co tak naprawdę jest do stworzenia. Szum informacyjny jest bardzo wysoki – myśl zwerbalizowana przez klienta trafia do osoby po stronie dostawcy, który na swój prywatny sposób interpretuje ten komunikat i buduje swoje wyobrażenie tego, jak mogło by to wyglądać. Może to prowadzić do sytuacji, w której każdy wyobraża sobie coś „nieco” innego (wspomniane w nagłówku kółko, trójką lub kwadrat) chociaż istnieje poczucie, że rozmawiamy o tej figurze geometrycznej.

Story Mapping to proces ciągły

Podczas ostatniego warsztatu działałem jak uruchomiony w tle proces w systemie operacyjnym: pozostając na drugim planie dyskusji, wykonywałem konsekwentną pracę związaną ze stopniowym budowaniem Story Mapy.

W tym konkretnym przypadku było to nieinwazyjne dokumentowanie wszystkiego, co rodziło się podczas dyskusji dotyczącej produktu. Starałem się wyłapywać z rozmowy zarówno duże, rozbudowane aktywności dotyczące głównego flow użytkownika (np. logowanie) jak również ich szczegóły oraz detale (np. zapamiętanie hasła, możliwość odzyskania zapomnianego hasła, dodatkowe informacje na ekranie logowanie) i dokładałem je do Story Mapy. Tym samym, w pewnym sensie mimowolnie, na ścianie stopniowo rodził się obraz produktu, do którego co jakiś czas mogliśmy się odwołać i upewnić, że rozumiemy go w ten sam sposób.

Story Mapping lubi się z UX

Uzupełnieniem Story Mapy były pierwsze szkice interfejsu użytkownika, budowane na różnym poziomie odwzorowania szczegółów: od uproszczonych, szybkich “bazgrołów” na tablicy suchościeralnej do całkiem szczegółowego interfejsu, wyklikanego między pierwszym a drugim dniem w dedykowanej aplikacji.

Te dwie aktywności, tj. budowanie Story Mapy oraz tworzenie szkiców, działy się symultanicznie. W proces od strony narzędziowej zaangażowaliśmy:
– zwykła rozmowę,
– słowo pisane,
– dwu-wymiarową, wizualną reprezentację produktu oraz
– szkice interfejsu o różnym poziomie szczegółowości.

Wszystko to, aby upewnić się, że – jak to mawiają nasi anglojęzyczni koledzy – jesteśmy na tej samej stronie, czyli po prostu tak samo rozumiemy rzeczy, o których właśnie toczy się rozmowa.

Wykrawanie pierwszej wersji produktu

Na koniec drugiego dnia warsztatów poprosiliśmy Product Ownera po stronie klienta, aby przeglądnął stworzoną Story Mapę pod kątem priorytetów oraz zestawu funkcjonalności stanowiących pierwszą wersję produktu. Odkreślił on wyraźną linią to, co stanowi dla niego priorytet i na czym powinniśmy się skupić od tego, co na dzisiaj nie jest dla niego istotne.

Wszystkie elementy powyżej linii skonwertowaliśmy do postaci niedużych User Stories z kryteriami akceptacyjnymi, które ostatecznie zasiliły Product Backlog. W ćwiczenie to zaangażowany był cały zespół: każda osoba otrzymała kawałek Story Mapy to skonwertowania. Moje obserwacje są takie, że pomogło to dodatkowo wzmocnić zaangażowanie produktowe po stronie zespołu oraz wywołało kilka dodatkowych dyskusji rozjaśniających zrozumienie produktu.

Przykład Story Mappingu z opisem

Przykład Story Mappingu z opisem

Nie wyrzucaj Story Mapy do kosza

Czy mając już przygotowany Product Backlog, zdecydowaliśmy się zedrzeć Story Mapę ze ściany i umieścić ją w koszu na śmieci? Oczywiście moglibyśmy tak zrobić, jednak byłaby to wielka strata dla zespołu oraz stakeholderów. Dostrzegam co najmniej trzy użyteczne sposoby zastosowania Story Mapy w dalszym procesie deweloperskim jako:

  • narzędzie wspierające codzienną komunikację zespołu – Story Mapa dostępna na przestrzeni zajmowanej przez zespół jest wygodnym narzędziem wspierającym dyskusje produktowe. Wielokrotnie byłem świadkiem sytuacji, w których członkowie zespołu w trakcie pracy podchodzą do Story Mapy, wskazują palcem konkretne elementy, dyskutują flow procesu, dodają lub usuwają kartki reprezentujące funkcjonalności. Story Mapa bywa tez pomocna, gdy pojawia się potrzeba, aby wytłumaczyć nowo zatrudnionym osobom, jak wysokopoziomowo wygląda produkt oraz jakie są dalsze plany rozwoju.
  • wysokopoziomowy artefakt przydany podczas Przeglądów Sprintu – w jednym z zespołów z którym współpracuję, Story Mapa jest wykorzystywana podczas Sprint Review jako nośnik informacji dotyczący aktualnego stanu rozwoju produktu. Wyświetlana jest zwykle na początku spotkania a przejście po jej elementach jest szkieletem prezentacji zmian w produkcie. Dodatkowo, zespół zastosował kodowanie kolorami, które odzwierciedlają status elementów Story Mapy: zadania zielone są zrealizowane, pomarańczowe to zadania z bieżącego Sprintu, białe reprezentują zadania czekające na realizację (domyślny kolor), natomiast czerwone to zadania zablokowane, czyli oczekujące na reakcję poza zespołem, np. ze strony działu marketingu. W tym konkretnym przypadku zespół wykorzystuje aplikację http://storiesonboard.com/, która pozwala na utrzymywanie elektronicznej wersji mapy oraz jej synchronizację z JIRA.
  • materiał do kolejnych warsztatów i dyskusji produktowych: jak wspomniałem wcześniej, w pewnym momencie Product Owner odkreślił linią pierwszą wersję produktu. Nic nie stoi na przeszkodzie, aby świadomość i zrozumienie kolejnych wersji produktu nadal budować przy użyciu Story Mapy, która “żyje” wraz z trwającym rozwojem produktu.

Podsumowanie

Dobre kilka lat temu pierwszy raz prowadziłem coś, co z perspektywy czasu nazwałbym bardzo uproszczonym i dosyć płytkim warsztatem produktowym. Opisałem to ćwiczenie jakiś czas temu na portalu agile247.pl. Nie korzystałem wtedy ze Story Mapy w zespołach, z którymi pracowałem #wielkaszkoda.

Patrząc z perspektywy czasu, uważam Story Mapping za technikę, która zmienia grę jeśli chodzi o software dewelopment i nie ukrywam, że jestem jej wielkim fanem. Ubogaca oraz wizualizuje dyskusje produktowe. Buduje wspólne zrozumienie produktu pośród zainteresowanych. Pomaga w zrozumieniu, co tak naprawdę jest do zrealizowania na teraz, a co może poczekać. Pomaga skupić się na rozwiązaniach end-to-end oraz dostarczaniu realnej wartości dla użytkownika. Całkiem sporo, jak na jedno narzędzie, prawda?

Co myślisz o Story Mappingu? Jakie są Twoje doświadczenia? Nie zawahaj się podzielić się swoim komentarzem!

Kilka słów o przyszłości

Dzisiaj nieco bardziej osobiście.

Spotykam osoby, które myślą, że nadal pracuję w Grupie Allegro. Są też takie, które identyfikują mnie z STX Next. Inna grupa kojarzy mnie z marką agile247.pl. Mało kto natomiast z 202 Procent (co mnie zupełnie nie dziwi) i właśnie o tym będzie dzisiejszy wpis.

202 procent to zespół doświadczonych praktyków agile’a. Kiedy ponad dwa lata temu brałem udział w tworzeniu tej inicjatywy, wiedziałem, że początkowo będzie to praca po godzinach, w ramach urlopu oraz w weekendy. Wiedziałem też, że nadejdzie dzień na podjęcie decyzji: albo zatrudniam się jako pracownik w kolejnej firmie, albo decyduję się rozwijać własną spółkę.

Po dwóch latach w STX Next zdecydowałem, że to właściwy moment, aby w pełni zaangażować się w rolę niezależnego agile coach’a w ramach 202 Procent.

Przez kilkanaście lat w branży IT nabrałem doświadczenia w różnych rolach (programista, project manager, scrum master, agile coach, C-level), w różnych firmach (startupy, średnie firmy, korporacje), działających w różnym modelu (firmy produktowe oraz usługowe, klient wewnętrzny i zewnętrzny), opartych o różną kulturę (m.in PL, UK, USA).

Ostatnie 5 lat wspierałem dwie duże transformacje agile’owe (Allegro, PayU) oraz prowadziłem transformację w STX Next. To skala kilkudziesięciu zespołów scrumowych w firmach od 150 do 1000+ osób. Widziałem jak funkcjonują te zespoły oraz aktywnie brałem udział w procesie usprawniania sposobu ich pracy.

Więcej o tym co robiłem, znajdziesz na moim profilu LinkedIn. Tematy, które mnie szczególnie interesują wrzucam na swojego twittera.

Jestem przekonany, że poważne zmiany w firmach dokonują się nie na poziomie praktyk, lecz na poziomie kultury organizacji oraz wartości. W codziennej pracy wierzę w otwartość, zaufanie oraz partnerstwo, a przysłowiową „szklankę” widzę zawsze do połowy pełną.

Jeśli czujesz, że jest przestrzeń, w której moglibyśmy współpracować, zachęcam do kontaktu via e-mail.

Fotografia użyta na licencji Creative Commons od użytkownika Bob Owen.

„No Estimates” – Vasco Duarte

Okładka książki "No Estimates" - Vasco Duarte

Okładka książki „No Estimates” – Vasco Duarte

Do przeczytania książki „No Estimates” dojrzewałem od dłuższego czasu. Złożyło się na to kilka okoliczności:

1. Prowokacyjny hashtag #noestimates, przez wiele osób traktowany zbyt dosłownie, wyświetlał się na moim twitterze od dłuższego czasu i rozbudzał moją ciekawość tematu.

2. Słucham od czasu do czasu podcast Scrum Master Toolbox Podcast, którego jednym z autorów jest Vasco Duarte, więc miałem okazję zapoznać się z jego poglądami przy okazji rozmów z gośćmi, których zapraszał do audycji (nie tylko zadaje pytania, ale potrafi celne podsumować wypowiedź lub dodać coś od siebie).

3. Miałem okazję posłuchać prezentacji Vasco na żywo podczas konferencji Agile Prague oraz podczas warszawskiego Agile By Example 2015 i można powiedzieć, że wtedy „mnie kupił”.

4. Dużo czasu poświeciłem w tym roku na przygotowywanie różnorakich prezentacji oraz warsztatów, stąd coraz bardziej czekałem na spokojną jesień, kiedy będę mógł zacząć czytać wybrane książki, które z różnych powodów wrzuciłem na swoją wish list na amazon.com.

Gdybym miał przekazać główną myśl książki jednym zdaniem, to było by to coś takiego: estymowanie samo w sobie nie przynosi wartości, dlatego postaramy się ograniczyć je do minimum.

Co zatem przynosi wartość? Już prędzej działający software. Pomysł jest taki: zaakceptujmy, że dwa z trzech boków klasycznego trójkąta projektu będą stałe, czyli czas oraz koszt. Jednocześnie akceptujem, że zakres jest zmienny i to nim będziemy głównie sterować w trakcie realizacji projektu.

Oczywiście zakresem możemy sterować tylko jeśli podzielimy go na małe, działające kawałki, z których każdy dostarcza wartość dla klienta. Z punktu odpada zatem podejście kaskadowe, dzielące projekt na fazy takie jak analiza, projektowanie, implementacja czy testowanie. Idąc dalej, podział po warstwach systemu (np. frontend, backend) również nie jest wystarczająco dobrym algorytmem dekompozycji wymagań.

Jak zatem skutecznie dzielić wymagania? Otóż dzielić na User Stories, z których każde story spełnia wymagania INVEST. Tego rodzaju granulacja pozwala na w miarę przewidywalne dostarczanie małych, wartościowych funkcjonalności, co z kolei pozwala na szybkie pozyskiwanie informacji zwrotnej od klienta, a w konsekwencji zmniejsza ryzyko niepowodzenia inicjatywy.

Kiedy już mamy nasz produkt podzielony na małe zadania (wg. Vasco – od 0,5 do 1 dnia), w praktyce okazuje się, że są one podobnej wielkości (podobnie małe). To, co pozostaje do zrobienia, jako główna część procesu deweloperskiego, to regularnie układanie zadań wg. wartości biznesowej. Powoduje to, że zamiast skupiać się na estymowaniu, zaczynamy skupiać się na priorytetyzowaniu, czyli de facto na dyskusji nie o koszcie dostarczenia (estymata), tylko na tym, co przyniesie największą wartość dla klienta. Proste i genialne zarazem, prawda?

Gdy z kolei jesteśmy skupieni na wartości, używamy dostępnych danych dotyczących przepustowości zespołu („n” zadań per okres czasu, np. tydzień), aby prognozować jak może układać się w czasie dalszy rozwój produktu. W efekcie klient dostaje realną prognozę przyszłości opartą na danych pochodzących z procesu i może na tej podstawie planować kolejne działania.

Oczywiście wszystko, co opisuję tutaj w dużym skrócie, jest bardzo mocno pogłębione w książce. Interesujących wątków jest więcej i są bardzo dobrze wytłumaczone.

Chociaż pozornie Vasco nie pisze o nowych pojęciach (w sensie: branża zna już pojęcia, o których wspomina w swojej książce), to muszę przyznać, że świetnie udało mu się poskładać w jedną całość istniejące i dostępne klocki, które głęboko rozumie i potrafi stworzyć z nich spójną kompozycję. Wychodzi daleko poza dostępne metody i frameworki, odkrywając nowe sposoby realizacji zadań, co jest punktem wyjścia oraz esencją Manifestu Agile. I to moim zdaniem pokazuje dojrzałość i poziom wiedzy autora.

Absolutnie rekomenduję każdemu, kto zawodowo zajmuje się tworzeniem oprogramowania.

Plusy:

+ cała masa badań oraz faktów związanych z problemem estymacji

+ dużo gotowych rozwiązań, które można użyć od zaraz we własnych projektach

+ jest uniwersalna, nie odnosi się do konkretnej metody pracy czy frameworka

Minusy:

– przez całą książkę przewija się fabularna historia Project Managerki o imieniu Carmen, która uczy się #noestimates na bazie projektu, który dostała do zrealizowania. Osobiście nie przepadam za takim sposobem przekazywania wiedzy i wyobrażam sobie, że niektórzy mogą również mieć na to alergię.

Moja ocena: 5

PS. Zachęcam też do przeczytania mojego artykułu „Rozwijanie produktów bez szacowania ich rozmiaru? #NoEstimates” na portalu agile247.pl