Relacja z Agile By Example Light 2019

ABE Light 2019

30 marca  w Warszawie odbyła się lekka, krótsza wersja konferencji Agile by Example. Motywem przewodnim spotkania, podobnie jak jej starszej, większej siostry, były przykłady z życia zwinnych organizacji albo takich, które są na swojej drodze do zwinności. Pełen program znajdziecie na stronie konferencji W tekście podzieliłam się z Wami najciekawszymi według mnie elementami wystąpienia głównego prelegenta – Jurgena se Smeta oraz strukturą i wrażeniami z jego warsztatów Systems Modelling for Organisational Design.

Jurgen de Smet: Why Should Most Organisations Ditch Scrum!

Podsumowując w kilku zdaniach główną prezentację konferencji, Jurgen powrócił do korzeni Scruma. Omówił, jak interpretuje znaczenie najważniejszych składowych metody, począwszy od ról, przez artefakty, zdarzenia i z humorem, ale też nie budzącą wątpliwości dezaprobatą (stąd przewrotny tytuł wystąpienia) wskazał antywzorce praktyk stosowanych w części  organizacji, które miał okazję zobaczyć od środka.

Warsztaty Labirynty Scruma, 9-10 grudnia we Wrocławiu

Role w Scrumie::

  • Właściciel Produktu – maksymalizuje wartość produktu i jego wpływ na biznes, a jeśli z jakiegoś powodu nie ma na to czasu, trudno, aby liczył na satysfakcjonujące efekty, czy na wysoki poziom motywacji w zespole,
  • Zespół Deweloperski – robi swoją pracę (ang. do stuff) i niekoniecznie potrzebuje do tego Jiry (czasem lepiej wydać pieniądze na butelkę dobrego wina, jak zaznaczył Jurgen, niż na rozwiązanie, które jest toporne dla zespołu)
  • Scrum Master – dba o to, aby Scrum działał na rzecz organizacji; czasem według Jurgena bywa niesłusznie nazywany Agile Coachem.

Przy roli Scrum Mastera Jurgen pokazał wizualizację tego, na jakie obszary jego zdaniem Scrum Master powinien kierować uwagę (na pionowej osi to wysiłek – ang. Effort), biorąc pod uwagę rosnącą z czasem dojrzałość organizacji (pozioma oś czasu – ang. Time). Podczas omawiania obszaru doskonałości technicznej (ang. Technical Excellence) rozumianej m.in. jako praca w trybie ciągłego dostarczania (ang. continuous delivery) wyraził swoją opinię dotyczącą umiejętności technicznych Scrum Masterów. Według Jurgena osoba, która nie potrafi czytać kodu, nie powinna pełnić tej roli. Dlaczego? Ponieważ nie rozumie, jak funkcjonuje tzw. Gemba (pojęcie zaczerpnięte z lean management: “miejsce wykonywania rzeczywistej pracy”), czyli środowisko, w którym tworzona jest realna wartość dla klienta. Dodał, że Gemba może być też rozumiana jako środowisko, w którym funkcjonuje zespół, ale dla niego to po prostu środowisko developerskie. Osobiście nie zgadzam się z tą opinią – zarówno dotyczącą kompetencji Scrum Mastera, jak sposobu rozumienia Gemby.

Artefakty – zapewnienie transparentności:

  • Backlog Produktu – zapewnia transparencję nt tego, co wydarzy się w przyszłości
  • Przyrost  – zapewnia transparencję nt tego, co już zostało zrobione
  • Backlog Sprintu – zapewnia transparencję nt tego, co jest realizowane

Wydarzenia – zastosowanie w praktyce cyklu uczenia się :

Jurgen zachęcał, aby regularnie powracać do lektury podręcznika Scruma – Scrum Guide niezależnie od tego, ile lat praktykujemy zwinne podejście (on sam pracuje Scrumem od 20 lat). Po to, aby przypominać sobie o sednie pracy tą metodą, a zarazem wciąż na nowo redefiniować jej elementy przez pryzmat swoich narastających doświadczeń. Nie staniesz się ekspertem, czytając Scrum Guide tylko raz. Prawda. Zwrócił uwagę na to, że na przestrzeni lat w zwinnym podejściu pojawiają się pewne trendy zachowań – na przykład przez pierwsze lata pracy Scrumem spotykał się z opinią, że tester w Zespole Deweloperskim jest wąskim gardłem, jedyną osobą, która może testować nowe rozwiązania, dziś jako takie wyimaginowane wąskie gardło postrzega specjalistów UX. W dowcipny, dosadny sposób skrytykował antywzorce w korzystaniu ze Scruma. Pierwszy i najważniejszy z nich to używanie tej metody jako sensu samego w sobie, a nie jako narzędzia, które ma wesprzeć w budowaniu zwinnej organizacji. Spójnie z tytułem prezentacji, zachęcał, aby używać Scruma porządnie, albo przestać tak nazywać garść chaotycznie używanych praktyk, zaczerpniętych ze Scrum Guide’a. Używaj Scruma dobrze, porzuć, albo po prostu przestań nazywać tak to, co robisz. Do innych antywzorców należą m.in:

  • traktowanie Przeglądu Sprintu jako momentu na raportowanie pracy, zamiast dyskusję z klientem na bazie realnego przyrostu wartości dla niego, a jeszcze lepiej pierwszych wniosków bazujących na danych,
  • podporządkowanie pracy Zespołu Deweloperskiego nie realnej potrzebie klienta (w tym wnioskom z badań, danym), a kultowi HIPPO (ang. akronim od Highest Paid Person’s Opinion). To konstrukt będący symbolem ważnej osoby w firmie, dla której buduje się zarówno całą narrację o produkcie (ang. story telling), jak i same rozwiązania.

Prezentacja skłoniła mnie do refleksji nt. źródeł Scruma, korzeni agile’a, a w tym kontekście moich doświadczeń i działań. Właśnie ze względu na ten intelektualny wysiłek, do którego zainspirował mnie Jutrgen, warto było posłuchać tego, jak go postrzegam, konserwatywnego i walecznego Scrum Mastera.

Jurgen se Smet: Systems Modelling for Organisational Design

Drugim punktem programu konferencji były warsztaty. Jako uczestnicy mogliśmy wybierać spośród pięciu zróżnicowanych tematycznie propozycji (LeSS roleplay, Responsibilities in Scrum,  Cynefin Lego workshop, Vision, Strategy, and Tactics, Systems Modelling for Organisational Design). Ze względu na moje zainteresowanie myśleniem systemowym, wybrałam ostatnią z opcji – warsztaty prowadzone przez Jurgena. Już na początku spotkania prowadzący zaznaczył, że zazwyczaj warsztaty i szkolenia o podobnej tematyce zajmują mu kilka dni, a kondensacja kluczowej treści w półtorej godziny jest dla niego eksperymentem. Moim zdaniem udanym, dlatego opiszę dla Was krok po kroku jego scenariusz.

W opisie warsztatów Jurgen napisał, że wiele organizacji adoptuje zwinne praktyki, usprawnia się, ale niewiele z nich jest projektowanych ze zrozumieniem. Ślepe kopiowanie jakichkolwiek schematów do skalowania zwinności wywołuje napięcia, wymagające wysiłku i energii, które można by przeznaczyć na dostarczanie wyników. Zapowiedział, że podczas spotkania pokaże serię ćwiczeń, które pomogą zaprojektować idealną organizację oraz ocenić, na ile istniejące schematy do skalowania zwinności wpisują się w jej potrzeby. Niekoniecznie udało się to osiągnąć w zakładanym czasie, niewątpliwie dał nam natomiast narzędzia, które pomagają zbadać,  jak wygląda dynamika kluczowych zmiennych w organizacji oraz jak na siebie wpływają. Pokazał też, jak na podstawie wniosków podjąć decyzje o tym, na których z nich warto się skupić, aby poprawić kondycję organizacji i upewnić się, że jako system zmierza w jednym kierunku (np. jej poszczególne działy nie mają sprzecznych celów).

Krok 1 – wybór kluczowych zmiennych w systemie (czyt. w organizacji)

Jurgen podzielił nas na kilkunastoosobowe grupy. Każda z grup otrzymała białą tablicę (stworzoną z kilku białych folii) oraz kserówki z listą przykładowych zmiennych, które mogą występować w systemie, jakim jest organizacja. Pierwsze zadanie polegało na tym, aby wybrać z listy naszym zdaniem najważniejsze zmienne i wypisać je pojedynczo na post-itach. Podczas tego ćwiczenia nie rozmawialiśmy ze sobą, indywidualnie wypisaliśmy zmienne, a następnie porównaliśmy je ze sobą i usunęliśmy duplikaty. W ten sposób w każdej grupie powstała lista kluczowych zmiennych dla wyimaginowanej organizacji, która była jednocześnie sumą naszych doświadczeń. W mojej grupie większość wybranych zmiennych pokrywała się, co już samo w sobie było ciekawe, bo pomimo różnych organizacji skupiliśmy się na podobnych tematach.

Poniżej przykładowe zmienne w zaproponowanych przez Jurgena obszarach. Mogą służyć do diagnozy organizacji niezależnie od jej stopnia zwinności. Tam, gdzie często używa się angielskich sformułowań albo ciężko było mi oddać sedno znaczenia, dodałam oryginalne zapisy.

HRProduct ManagementProject Management
– rotacja pracowników (ang. retention rate)
– motywacja pracowników
– wzrost ilości pracowników
– użycie premii indywidualnych
– poziom skomplikowania organizacji (role, szczeble (ang. level)
– ilość produktów
– interakcje z interesariuszami
– czas wykonania (ang. delivery cycle time)
– łatwość w podejmowaniu ważnych decyzji (ang. easy of changing and executing large-direction decisions)

– projects
– ilość osób zaangażowanych w koordynowanie prac
– presja na dostarczanie zgodnie z założonym czasem i budżetem
– interakcje z interesariuszami
– duplikacja wymagań, rozwiązań, zadań

R&DOperationsExecutives
– ilość błędów
– % czasu spędzony na poprawkach błędów (ang. bug fixing)
– Prędkość (ang. Velocity)
– Produktywność (ang. Throughput)
– Średni czas rozwiązania zadania
– ilość błędów
– jakość kodu
– średni czas rozwiązania zadania
– wielkość i stopień skompli
kowania infrastruktury i technologii

– nagrody i kary używane w organizacji
– poczucie posiadania kontroli
– presja na dostarczanie (ang. pressure to deliver)
– poziom transparentności w organizacji

Krok 2 – wskazanie relacji pomiędzy zmiennymi

W każdym systemie funkcjonują zmienne, które na siebie oddziałują. W kolejnym kroku mieliśmy za zadanie wskazać zmienne, które są ze sobą w relacji. Podobnie jak podczas pierwszego ćwiczenia, działaliśmy indywidualnie – każdy według swojego uznania sięgał po post-ity z wybranymi zmiennymi i łączył je linią, symbolizującą relację (jeśli jedna zmienna wzrasta lub maleje, oddziałuje na inną zmienną). W ciszy powstawały coraz to większe grafy powiązań, ponieważ dodawaliśmy kolejne post-ity i łączyliśmy w nowe relacje te, które już znalazły się na tablicy.

Krok 3 – wskazanie rodzaju relacji

Sama relacja nic nam jeszcze nie mówi, ważny jest jej kierunek. Kolejny krok to zdefiniowanie rodzaju relacji:

  1. bezpośrednie, jednokierunkowe powiązanie (jeśli X wzrasta to Y również albo jeśli X maleje to Y też – pokazane za pomocą strzałki)
  2. przeciwległe powiązanie (jeśli X wzrasta to Y maleje albo jeśli X maleje to X wzrasta – pokazane za pomocą okręgu)
  3. powiązanie z efektem opóźnienia (pkt 1 lub 2 ale z efektem odroczenia wpływu – pokazane za pomocą równoległych linii i odpowiedniego symbolu – strzałka lub okrąg)

Na tym etapie początkowo działaliśmy indywidualnie, ale szybko wywiązały się dyskusje i praca przyjęła formę zbiorową.

Krok 4 – wybór zmiennych, które mają największy wpływ na organizację

Wizualizacje, które powstału w poprzednich trzech krokach pozwoliły szybko wyłonić zmienne, które mają najwięcej powiązań z innymi zmiennymi w organizacji. Potencjalnie to takie, na których warto skupić się w pierwszej kolejności. Na tym etapie mieliśmy za zadanie wybrać zmienne, na których chcielibyśmy się skupić oraz zdefiniować, co w jej ramach chcemy osiągnąć – podnieść jej wynik, czy go obniżyć.

Krok 5 – sprawdzenie, czy jako organizacja zmierzamy w tym samy kierunku

To jeden z ciekawszych momentów tego ćwiczenia. Kiedy byliśmy w procesie pracy nad naszą organizacją, Jurgen wybił nas z niej, nadając nowy kontekst – okazało się, że jako wszystkie grupy warsztatowe tworzymy jedną organizację i musimy upewnić się, że optymalizując naszą zmienną nie wpłyniemy negatywnie na kluczowe zmienne w innych grupach.

Krok 6 – wybór sposobu mierzenia zmiany i wyłonienie akcji do wykonania

Jeśli wiemy już, co chcemy zmienić, ustalmy, jak będziemy mierzyć zmianę oraz  jakie usprawnienia trzeba wprowadzić w organizacji, aby poprawić wyniki.


Ćwiczenia były wykonywane szybko i w zbyt dużych grupach, by prowadzić konstruktywne dyskusje, które moim zdaniem nie były tutaj kluczowe. Ogromna wartość, jaką czerpię z udziału w warsztatach, to konkretny schemat działania, który pozwala zwizualizować relacje pomiędzy zmiennymi w systemie. To ciekawe ujęcie, bo punktem odniesienia nie jest dla nas organizacja, czy budowa systemu, ale elementy o największym znaczeniu, najbardziej oddziałujące na system.
W sieci są już dostępne nagrania wszystkich wystąpień, zachęcam Was do ich obejrzenia i wysłuchania. Dla tych z Was, którzy nie zdecydują się na ich obejrzenie, a są ciekawi innych prezentacji, przygotuję drugą część relacji.

W tekście wykorzystałam slajdy z prezentacji Jurgena de Smeta oraz wizualizacje z warsztatów – instrukcje prowadzącego oraz zdjęcie tablicy jednej z grup.

Jeden komentarz do wpisu: “Relacja z Agile By Example Light 2019


Dodaj komentarz

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X