// artykuł napisany razem z Tomaszem Kurowskim, Scrum Masterem / Analitykiem Biznesowym w firmie Metrosoft
Każdy z nas działa w organizacji, gdzie zmaga się z problemami zarówno ze swoją dzienną pracą jak i działaniem całej grupy projektowej. Niejednokrotnie trudności napotykamy także w kooperacji ze stronami zewnętrznymi jak inne firmy technologiczne czy też wybitnie wymagający interesariusze. Aby móc takie problemy rozwiązywać we wczesnych etapach egzystencji środowisko Agile stworzyło praktykę nazywaną Retrospektywą. Ma ona na celu zatrzymanie się na pewien czas i wspólne zastanowienie się jak usprawnić ich aktywności.
Mapowanie ograniczeń
Niestety pytanie osób bezpośrednio jak poprawić ich sytuację nie zadziała – Dave Snowden mówi o tym w swojej prezentacji na Agile People. Ludzie będą się skupiali na rozwiązaniach, które mają w głowę, a nie na realnych problemach z którymi się zmagają. Na sprawdzonych odpowiedziach, które niestety najprawdopodobniej były remedium na zupełnie inne problemy. Dlatego trzeba zajmować się jedną rzeczą naraz – najpierw mapowanie ograniczeń, a następnie możliwe propozycje usprawnień.
Takie zachowanie pozwala nam zebrać stan, w którym się aktualnie znajdujemy, z całym bagażem doświadczń jakie niesiemy. Wizualizacja daje możliwość zrzucenia tego co mamy w głowie, dzięki czemu pojawi się tam miejsce na kolejne problemy, które wcześniej nie zauważaliśmy. Kolokwialnie mówiąc, lepiej zostawić sobie w głowie miejsce na rozwiązania, a problemy przelać na papier, tablicę, schemat czy też rysunek. Następnie planujemy dokonanie zmian, na relatywnie małym obszarze by, wykonać bezpieczne doświadczenie. Jeśli się ono nie powiedzie, to nic się nie stanie.
Jeśli dana próba się powiedzie to staramy się je krokowo przeistoczyć w naszą codzienną praktykę. Dzięki temu posuwamy się do przodu krok po kroku, analizując nasze wady, działając sprawniej z każdą iteracją. Same usprawnienia też dobrze rozłożyć w czasie, zajmując się na start tymi najbardziej krytycznymi. Pytając retorycznie (retrorycznie?), czy te kilka rys na zderzaku Twojego wymarzonego Passata są większym priorytetem niż martwa turbina? No właśnie…
Event Storming
Tomek Kurowski opisał na LinkiedIn zastosowanie Event Stromingu do rozpoznania i rewizji procesu Scrumowego w obrębie całego zespołu projektowego pracującego w trybie zwinnym. I jak dla mnie to jest świetny pokaz wyżej wspomnianej techniki – mapowania ograniczeń.
Skupiamy się na wizualizacji procesu działania naszej grupy. Mapujemy każde zdarzenie w systemie naszej pracy, a następnie pokazujemy ile czasu trwa każde zdarzenie (łączymy Event Stroming z Value Stream Mapping). Na końcu dodajemy ograniczenia jakie widzimy w zachodzącym procesie.
Koncentracja tylko na jednej warstwie na raz pozwala wejść bardzo głęboko w problemy, nie skupiając się na tym co będzie dalej. Każda informacja jest wartościowa – nawet jeśli Ty nie będziesz wiedział, jak to rozwiązać to możliwe, że twój kolega / koleżanka będzie. Dopiero mając wszystkie nasze ograniczenia jasne dla wszystkich członków zespołu można iść dalej i proponować rozwiązania.
Efekty były zaskakujące. Zespół jest złożony z programistów z wieloletnim doświadczeniem a także z osób po studiach managerskich, gdzie zwinne metodyki rozbijano na czynniki pierwsze. Ale nawet tutaj natrafili na sytuację, gdy te same zdania Scrum Guide były interpretowane w sposób zgoła inny. Czytając ten sam materiał dochodzili do przeciwnych wniosków. Warsztaty pozwoliły im to niezrozumienie zwizualizować, a następnie zaadresować problem.
Pokazanie, ile trwa każde z zdarzeń było bardzo dobrym sposobem na rozpoczęcie dyskusji. Uczestnicy określili kilka ze zdarzeń jako problematyczne – trwające zbyt długo. Na końcu dokonano szybkiego brain-stormu by ustalić jaki jest plan na zmniejszenia trwania i podziału tego zdarzenia na 2 mniejsze.
Event Storming zidentyfikował również problemy ze wspólnym językiem pomiędzy zespołami technicznymi a biznesowymi. Zastanowili się, czy na daily stand-upie informacje techniczne przekazywane przez programistów są możliwe do zrozumienia przez osobę o najniższej wiedzy technicznej w zespole? Z drugiej strony czy przekaz biznesowy deklarowany na cotygodniowych spotkaniach projektowych dostarcza wartości osobom technicznym? Te dwie obserwacje są intrygującym punktem wyjścia do zupełnie nowych zagadanień, jak Ubiquitous Language – wszak język jest jednym z elementów, które ograniczają nas najbardziej.
