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

„Scrum Shortcuts without Cutting Corners” – Ilan Goldstein

Okładka książki "Scrum Shortcuts without Cutting Corners" – Ilan Goldstein

Okładka książki „Scrum Shortcuts without Cutting Corners” – Ilan Goldstein

Dosyć długo nie czytałem żadnej książki o Scrumie. Ostatnie pozycje, które przeczytałem lub odsłuchałem od wakacji dotyczyły m.in przywództwa („Turn the Ship Around!”), zarządzania („Jednominutowy menedżer i przywództwo”), motywacji („Drive”) czy zarządzania samym sobą („Jesteś start-upem”, „7 nawyków skutecznego działania”). Po przeczytaniu powyższych pozycji stwierdziłem, że tym razem czas sprawdzić jedną z wielu ostatnio napisanych książek o Scrumie.

Po przeglądnięciu kilku pozycji na Amazonie wybrałem „Scrum Shortcuts without Cutting Corners”, a  zadecydowały o tym dwa fakty – to pierwsze: książka została bardzo wysoko oceniona przez czytelników (średnia 4.9 na podstawie 57 ocen), po drugie: napisał ją człowiek, który zanim stał się trenerem scruma i autorem wspomnianej książki, dobre kilka lat pracował na różnych stanowiskach w IT, więc założyłem, że wie, o czym mówi – w przeciwieństwie do trenerów, którzy po prostu nauczyli się zasad frameworka na potrzeby prowadzenia szkoleń.

Wstęp do książki napisał Mike Cohn (który jak okazuje się na kolejnych stronach książki, jest mistrzem w wyciskaniu sztangi na ławce poziomej z rekordem 254 kg) i chyba nie jest to przypadkowe, ponieważ odniesienia do książek Mike’a pojawiają się podczas lektury wielokrotnie. Reasumując – czuć jego szkołę.

Autor – Ilan Goldstein – podzielił książkę na 10 rozdziałów, z czego każdy opisuje po trzy „skróty” (ang. shortcut), czyli w miarę gotowe rozwiązania, opisujące wybrane zagadnienia scrumowe. Podczas czytania kolejnych rozdziałów dostrzegłem analogię do książki Henrika Kniberga „Scrum & XP from the Trenches” – Ilan, podobnie jak Kniberg opisuje „Scruma w praktyce” – czyli to, co zadziałało w jego zespołach oraz organizacjach w których pracował.

Warto jednak pamiętać, że nie każda technika czy podejście, które zadziałało autorowi książki, zadziała w naszym zespole czy organizacji. Jak powiedział mi kiedyś Alistair Cockburn – „every technique is working and is not working at the same time„.

Przykładowo: autor proponuje, aby za spóźnienia na Daily Scrum pobierać od spóźnialskich opłatę do słoika na cele charytatywne. W czasie, kiedy pracowałem w Allegro, w jednym zespołów w których byłem Scrum Masterem, zdecydowaliśmy na taki krok, aby „zmotywować” osoby spóźniające się do bycia na czas. Rozwiązanie to nie przyniosło spodziewanych rezultatów – osoby, które spóźniały się, robiły to nadal (ciekawostka: gdybym wcześniej przeczytałbym „Drive” Dana Pinka, wiedziałbym, że taki sposób motywacji z reguły nie działa – niektórzy ludzie po prostu „wykupują sobie” możliwość spóźnienia się)

Najciekawsze z mojej pespektywy rozdziały dotyczyły wymagań („Requirement Refinement”), jakości („Questioning Quality”) oraz metryk („Monitoring and Metrics”). Pełne konkretów, trafnych analogii oraz praktycznych wskazówek powodowały podczas czytania chwile zadumy, co uważam za wartościowy i pożądany efekt w trakcie czytania książek.

Jest to książka, którą gdybym mógł cofnąć czas, przeczytałbym zaraz po pierwszej lekturze Scrum Guide – oczywiście nie była wtedy jeszcze dostępna (została wydana w 2013), ale to właśnie ten typ książki. Poleciłbym ją Scrum Masterom zaczynającym przygodę ze Scrumem jako swego rodzaju przewodnik, natomiast osobom z dłużym stażem jako cenne źródło referencji oraz inspiracji.

Plusy:

+ dużo praktycznych wskazówek, pomysłów oraz rozwiązań dotyczących codziennej pracy w Scrumie

+ można z niej  korzystać jak z książki kucharskiej, poszukując odpowiedniego „przepisu”

Minusy:

– odniosłem wrażanie, że książka pisana jest z perspektywy dużej organizacji, rozwijającej wewnętrznie swoje produkty, zabrakło mi perspektywy pracy z klientem zewnętrznym

Moja ocena: 4,5/5

Scrum & agile: zestaw startowy dla początkujących

Agile & scrum: jak zacząć?

Wielokrotnie spotkałem się z pytaniem Scrum Masterów lub Product Ownerów – którzy dopiero rozpoczynają swoją przygodę z agile oraz Scrumem – co robić, aby rozbudować swoją wiedzę. Kiedy kilka dni temu, po przeprowadzeniu rozmowy rekrutacyjnej w poszukiwaniu doświadczonego Scrum Mastera, osoba biorąca w niej udział poprosiła mnie o feedback i sugestie co do dalszego rozwoju, stwierdziłem, że czas na napisanie poniższego wpisu.

Obszary, którymi warto się zainteresować, można podzielić na kilka grup:

1. Lokalne społeczności agile – w kilku dużych miastach w Polsce funkcjonują inicjatywy, które skupiają entuzjastów agile, chętnych do dzielenia się wiedzą oraz doświadczeniami. Najczęściej formuła takich spotkań to prezentacja prelegenta (zazwyczaj ok. 1h), która przeobraża się następnie w dyskusję w mniejszych grupach. Jeżeli szukasz inspirujących dyskusji, zdecydowanie zainteresuj się, czy w pobliżu Ciebie funkcjonuje już taka grupa. Jeśli nie, to może warto założyć takową?

2. Książki

3. Publikacje

  • Scrum Guide – kilkanaście stron o tym, czym jest Scrum, napisane przez Jeffa Sutherlanda oraz Kena Schwabera – twórców Scruma. Warto czytać ten dokument co jakiś czas, bo wraz z upływającym czasem (oraz zdobytym doświadczeniem) zaczyna się coraz więcej z niego wyciągać. Do dzisiaj potrafi mnie coś zaskoczyć czy zainspirować.
  • Product Owners Manual – krótka, lecz treściwa pozycja, zawierająca zbiór podstawowych informacji związanych z rolą Product Ownera

4. Materiały video

Powyższe materiały to tylko przykład punktu, z którego można wystartować. Dalszy rozwój to połączenie własnych doświadczeń, dyskusji z praktykami agile oraz kolejnych lektur – dobieranych według własnego uznania. Powodzenia!

Fotografia użyta na licencji Creative Commons od użytkownika thenext28days.