Impact Mapping w praktyce

Impact mapping. Co to w ogóle jest? Gojko Adzić? Kto? BDD?ImpactMapping Właśnie taka była nasza reakcja, kiedy pierwszy raz o nim usłyszeliśmy. Z Gojko jest jak z winem… No może nie do końca, bo to trzeba samemu dojrzeć do jego przekazu.

W końcu jako zespół dojrzeliśmy. Mieliśmy kwartalne planowanie celów wraz z wyrażającymi je KPI. Nie chcieliśmy mieć już więcej groomingów (refinmentów), na które Product Owner przychodził  z gotowym zakresem i jedynym naszym twórczym wkładem była estymata. Zastanawialiśmy się, jak przejść na wyższy poziom wtajemniczenia.

Trochę przez przypadek przyszedł nam z pomocą nowy zespół, który dołączył do naszego serwisu w całości, a który używał już impact mappingu.

Skoro była potrzeba, jak i jakieś połowiczne, ale zawsze, doświadczenie, podjęliśmy próbę.

Chcielibyśmy w niniejszym artykule przybliżyć Wam nasze doświadczenia związane z tą techniką. I to od razu z dwóch perspektyw – mojej (DL) jako Scrum Mastera oraz Krystiana (KM) jako specjalisty User Expierence, który gościnnie po raz kolejny zawitał na nasze łamy.

Impact Mapping

Samo narzędzie wydaje się super. Przekaz Gojko o jego stosowaniu, o tym jak zmienia perspektywę, otwiera horyzonty poprzez odkrywanie naszego użytkownika i, w efekcie, pozwala nam, jako firmie, na zarabianie większych pieniędzy, wydaje się “ziemią obiecaną”.

 

A jak to wyglądało w rzeczywistości? Zaczęliśmy od przygotowania warsztatów.

Przygotowanie

DL: ekhmmm. Jakie przygotowanie? Z mojej perspektywy wyglądało to tak, że ujrzałem pewnego dnia w kalendarzu zaproszenie na spotkanie, na którym będziemy robić impact mapę. Zwarłem szyki i przeczytałem naprawdę krótką książkę Ajdzića o technice. Zespół zrobił jeszcze mniej. Osób, które zapoznały się w narzędziem przed jego zastosowaniem, był ułamek, i to dziesiętny. Jak się miało później okazać, był to pierwszy błąd, nie wiem, czy nie najważniejszy z mojej perspektywy.

KM: Decyzja, że nasze nowe cele kwartalne chcemy przeanalizować za pomocą nowej techniki, jaką była dla nas impact mapa, została podjęta nagle – moim zdaniem zbyt pochopnie. Brak jakiegokolwiek przygotowania (w sumie 5 osób przeczytało książkę Gojko Adzića, z czego dwie wieczór przed samym spotkaniem) sprawił, że wejście w technikę było bardzo chaotyczne i obarczone dużym błędem. Każdy medal ma dwie strony i na pewno należy się cieszyć, że próbujemy nowych rozwiązań, jednak nie możemy zapominać o efektywności naszych działań. Zabrakło nam chwili na dokładne poznanie techniki, wypracowanie jednego wspólnego fundamentu merytorycznego dla wszystkich moderatorów tak, by mówili jednym głosem tłumacząc samą technikę. Nie zastanowiliśmy się również, jak impact mapę chcemy wdrożyć w naszym zespole – co musimy zrobić, aby maksymalnie obniżyć próg wejścia do wspólnego wykorzystania nowej techniki.

Stworzenie impact mapy – warsztaty

DL: Podejścia do tworzenia impact mapy mieliśmy dwa (dwa kwartały), w dalszej kolejności skupię się na drugiej próbie.

Spotkania były dedykowane per cel. Czyli mając przykładowo trzy cele, mieliśmy trzy osobne warsztaty. Jeszcze przed spotkaniem zostali wyznaczeni Product Ownerzy danego celu, którzy otrzymali go razem z miarami (KPI) do osiągnięcia. Pomimo że teoretycznie Product Ownerzy pracowali z dedykowanymi zespołami, warsztat był otwarty i mógł do niego dołączyć każdy, kto chciał, tym bardziej że mieliśmy zasadę, że developerzy mogli zmieniać zespół, jeżeli uznali, że lepiej się będą realizować w innym zespole lub przy realizacji innego celu. W związku z powyższym spotkania były duże. Przychodziło na nie ca 15 osób teoretycznie zainteresowanych tematem. Piszę teoretycznie, ponieważ z mojej perspektywy spotkania te były trudne w moderacji. Tym bardziej, że często zaczynały się one od podważania celu (?), który miał zostać na tych warsztatach zdekomponowany. To był drugi problem. Zamiast skupić się na dekompozycji pojawiała się dyskusja nad samym celem i jego miarami. Przy jednym z celów “rozwaliło” nam to całe warsztaty. Pozostałe przebiegały bez większych zakłóceń. Był moderator, który prowadził zespół przez meandry dekompozycji. Zaczynaliśmy od zidentyfikowania głównych person, które mogą nam pomóc lub utrudnić realizację danego celu, a następnie się zastanawialiśmy, jak możemy zmienić ich zachowanie. Kolejnym problemem, który się tutaj ujawnił, była wish lista. Jeżeli developerzy nie mieli gdzie wylać wcześniej z siebie pomysłów na rozwój serwisu, zaczynali to robić, pobudzeni techniką, w trakcie warsztatów. I oczywiście nie mam tutaj na myśli ficzerów związanych z realizowaniem impact mapy, ale wszelkich innych pomysłów. Dobrym pomysłem było zrobienie od razu przez moderatora tzw. “parkingu”, czy zapisywanie tych tematów z boku, jako niezwiązanych bezpośrednio z omawianym celem, ale wartych zapamiętania do dalszej dyskusji. Pewnym niepokojącym dla mnie elementem całych warsztatów było pojawiające się w ich trakcie słowo “zakres”. Później miało się okazać, w czym rzecz.

KM: Od dłuższego czasu pracowaliśmy nad tym, aby zespół, który “opiekuje” się serwisem, nie kojarzył się tylko z zespołami scrumowymi, ale był zgraną multidyscyplinarną maszyną łączącą biznes, IT, marketing oraz wsparcie użytkownika. W wyniku takiej symbiozy okazało się, że na naszych impact mapowych warsztatach, które były otwarte i każdy zainteresowany tematem mógł przyjść, pojawiły się tłumy. Takie zaangażowanie bardzo cieszyło, ale jednocześnie było bardzo dużym wyzwaniem dla moderatorów. Z perspektywy czasu mogę powiedzieć, że nie udało nam się z tego zadania wyjść zwycięsko. Po pierwsze – nie zbudowaliśmy jednej wspólnej dla wszystkich platformy komunikacyjnej. Duża różnorodność i bogactwo perspektyw, które miało być naszym atutem, okazało się naszym przysłowiowym “gwoździem do trumny”.

Tak jak już pisałem wcześniej, zabrakło czasu na wprowadzenie i wyjaśnienie podstawowych zasad tworzenia impact map. Dlatego z czasem nasze spotkania przeobraziły się w rodzaj koncertu życzeń, gdzie każda z grup starała się przeforsować swoje pomysły i wyciągała zakurzone projekty, całkowicie zapominając o głównym celu i miarach do niego przypisanych.

Po drugie stworzone przez nas impact mapy, były dysfunkcyjne, choć na pierwszy rzut oka nie było tego widać i my sami tego jeszcze nie dostrzegaliśmy. Zawierały one wszystkie elementy, czyli: cel z miarami, aktorów, impacty, rozwiązania, jednak nie zadziałały tak jak na początku przypuszczaliśmy. Czas pokazał, że nie pokierowały nas do realizacji celu.

Wizualizacja

DL: Razem z Krystianem oraz Product Ownerami stwierdziliśmy, że musimy stworzoną impact mapę zwizualizować. Miał to być dodatkowy czynnik wzbudzający we wszystkich przywiązanie do tematu, angażujący ich jeszcze bardziej. Połączenie wizualizacji impact mapy wraz z wizualizacją celów kwartalnych, poza powyższym, miało nam także dostarczać bieżącej informacji, gdzie jesteśmy w osiąganiu danego celu. Każdy Product Owner i jego zespół zrobili to po swojemu, a efekty ich pracy możecie podziwiać poniżej.

KM: Osobiście byłem pozytywnie zaskoczony, jak kreatywnie niektórzy Product Ownerzy podeszli do tematu wizualizacji impact map. Czas pokazał, że im więcej pracy włożono w zaprezentowanie impact mapy, tym dłużej żyła ona w świadomości zespołu.

Realizacja impact map

DL: W zespole był zauważalny bardzo pozytywny wzrost zaangażowania. Ludzie byli podekscytowani, że w końcu mają miejsce na kreatywność, samoorganizację, mogą robić coś, co chcą robić. Oceniając sytuację jako Scrum Master, zszedł mi z głowy, przynajmniej na 2-3 sprinty, temat związany z wzbudzaniem motywacji i zaangażowania. Developerzy chcieli realizować zakres, który sami wymyślili. No właśnie – zakres. Na początku artykułu wspomniałem o braku znajomości narzędzia, a w części opisującej same warsztaty o niepokojącym się pojawianiu się słowa “zakres”. Powiem to szczerze – rozminęliśmy się z techniką. Zamiast myśleć o impact mapie jak o drogach do osiągnięcia postawionego celu (sam Gojko to przedstawia na swoich prezentacjach jako plan miasta – możesz przejść z punktu A do B wieloma, zupełnie różnymi drogami), zespoły w większości myślały o impact mapie jak o zakresie do wykonania. To powodowało mniejszy niż powinien być nacisk na mierzenie KPI celu (uratowała nas tutaj osobna tablica, gdzie wizualizowaliśmy konkretne wartości miar) oraz skupianie się na dowiezieniu zakresu, nazwijmy go w opisywanym przypadku Product Backlogiem.

KM: Finał naszej przygody z impact mapami jest niestety dość smutny. Okazały się one kolejnym artefaktem, który zawisł na ścianach naszego biura. Nawet najciekawsze wizualizacje z czasem stały się “niewidzialne” dla zespołów. Nie były dla nas drogowskazem i nie pomagały w realizacji celu. Bardzo szybko odsunęliśmy się od impact map, zapomnieliśmy o aktorach oraz ich zachowaniach, które chcieliśmy zmienić, aby zrealizować wyznaczone cele. Mapy nie były aktualizowane, nie mierzyliśmy na bieżąco, jak nasza praca wpływa na poszczególne KPI. Dodatkowo zaczęły pojawiać się zadania, które nie miały nic wspólnego z celami, i wszystko zaczynało się rozmywać.

Mimo wszystko nadal uważam, że jest to świetne narzędzie, które pozwala stworzyć wspólną przestrzeń do dyskusji i wypracowywania wspólnej i spójnej strategi. Umożliwia spojrzenie na cel z różnych perspektyw przez pryzmat aktorów i ich zachowania. Jednocześnie wymuszając na nas ciągłe mierzenie naszej skuteczności i wpływy na realizację głównego celu.

Wnioski

1. Nauczenie (się) techniki

Zespół potrzebuje albo samoorganizacji i samodyscypliny, aby przygotować się do użycia tej metody, albo / i mentora, który tego nauczy. Nam tego zabrakło. Ważne jest tutaj także zrozumienie, co robimy na poziomie Product Ownera, jak i szeroko rozumianego managementu. Pracujemy w duchu agile jako samoorganizujące się zespoły w sposób opisywany jako mission command i musi istnieć na to pozwolenie i zrozumienie. Jeżeli popełnimy gdzieś błąd, przejdziemy na inną drogę i spróbujemy inaczej osiągnąć zamierzony cel. Powtarzając za Gojko “…try to not deliver whole scope…”.

2. Sprawny moderator

Warsztaty się nie udadzą, jeżeli nie będzie sprawnego moderatora. I niekoniecznie musi nim być Scrum Master (ja nie byłem!)

3. Zaakceptowane cele i ich miary przed spotkaniem (commitment zespołu)

Warsztaty z impact mappingu mają dotyczyć dekompozycji celu i poszukania możliwości wpłynięcia na naszych użytkowników tak, abyśmy zrealizowali postawiony cel. Jeżeli postawione cele wywołują dyskusje, są nieprzedyskutowane, a miary źle dobrane, to istnieje duże prawdopodobieństwo, że dyskusja zejdzie z głównego toru i nawet sprawny moderator nie uchroni nas od katastrofy.

4. Zbieranie pomysłów rozwojowych na bieżąco, nieczekanie na tego typu warsztaty. Otwieraj (i to niezależnie od tego, jaką rolę aktualnie przyjąłeś) przed zespołem możliwość wyrażania swoich pomysłów na rozwój produktu na bieżąco. Czy to będzie refinement, dedykowana kolejka na narzędziu do zarządzania backlogiem, którego to aktualnie używasz, czy cokolwiek innego – nieważne. Developerzy, ale i inni interesariusze, mają na pewno pomysły, co zmienić, usprawnić. Daj im możliwość podzielenia się nimi.

5. Impact mapa daje możliwość odejścia od waterscrum, przywoływanego wiele razy przez Gojko w powyższej prezentacji.

6. Nie porywaj się na impact mapę, jeżeli nadal macie problem z mechanicznym scrumem. Niech framework scruma zacznie prawidłowo funkcjonować (ceremonie, iteracje, DOD), a w kolejnym etapie pomyślcie o zaangażowaniu zespołu w tworzenie sposobów na osiągnięcie celów i ich miar.

Komentarze do wpisu: “Impact Mapping w praktyce

  1. Bardzo ciekawy artykuł. Z mojej strony dodałbym jeszcze kilka wniosków:

    7. Ograniczać ilość osób na dekompozycji celu od 5 do 15 (ilość osób na spotkaniu jest odwrotnie proporcjonalna do koncentracji i wartości spotkania);
    8. Oczyszczenie umysłu – jeżeli ktoś idzie na impact mapę z konkretnym rozwiązaniem i szuka tylko miejsca, żeby udowodnić jego zasadność to mija się to z celem – cytując klasyka „Morpheus: I’m trying to free your mind, Neo”;
    9. Impact mapa ma realny wpływ na realizację strategii firmy – powinna być jej odzwierciedleniem – wniosek z tego taki, że należy tak zdefiniować cel oraz przygotować impact mapę, aby ona żyła, a nie była zmieniana co miesiąc/kwartał. Częste zmiany Impact Mapy nie dają szansy podejmować różnych dróg z impact mapy.

    • Dawid Lewandowicz

      Lucek, zgadzam się z tymi punktami. Zwłaszcza punkt 9, gdzie z jednej strony organizacja musi wspierać używanie tej metody dając PO/ zespołowi konkretny cel do osiągnięcia, natomiast z drugiej strony aby (mityczna) organizacja dała możliwość samoorganizacji zespołowi i zaufanie umożliwiające realizacje celu z wykorzystaniem impact mapy

    • Potwierdzam to co napisał Lucek.
      Zrobiliśmy kilka impact map
      1. Największym krokiem dla ludzi jest przejście z celu strategicznego (np wzrost reve) na poziom celu, który może zrealizować ich jednostka i ten cel dopiero ma wpływ na cel strategiczny.
      2. Drugim krokiem jest to, aby sam poziom impactu pokazywał faktycznie cos sie może zmienić w zachowaniu aktorów
      3. I mega ważnymi było to, że najpierw wytłumaczyliśmy tą technikę Product Ownerowi na przykładzie. Jak PO to złapał to obskoczył z nami wszystkie biznesy. Niektórzy byli zachwyceni. PO był w stanie najlepiej wytłumaczyć biznesowi po co to robimy. Oczywiscie były przypadki, że na spotkanie przychodziła ekipa z gotową receptą na życie 😉


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x