Scrum na co dzień, czyli z notatnika Agile Coachaigormroz21 września 2018
Agile coach to ktoś, kto pomaga organizacjom i zespołom w adaptacji i wdrożeniu zasad agile u siebie. Rola trudna, wymagająca, ale – jak zdążyłem się wielokrotnie przekonać – przynosi wiele satysfakcji. Jako świeżo upieczony (doświadczony z resztą też) agile coach pamiętaj, że:
1.
Idealnym stanem jest taki, gdzie dany zespół czy organizacja nie będą już potrzebowali twojej pomocy. Twój wymarzony daily scrum, albo retrospective to taki, gdzie zespół zakwestionuje twoje sugestie i przedstawi swoje, o wiele, wiele lepsze w danej sytuacji.
2.
Częstotliwość spotkań, inspekcji i rozmów będzie mocno zależała od dojrzałości zespołu. Z osobami, które dopiero raczkują w agile będzie trzeba spotykać się relatywnie często. W przypadku zaawansowanych zespołów nawet raz na dwa tygodnie może okazać się przerostem formy nad treścią.
3.
Nie nauczaj – podawaj (relewantne!) przykłady, opowiadaj historie, mów, od jakiego małego kroku zacząć, a przede wszystkim: lead by example. Jeśli chcesz, aby ludzie więcej komunikowali się ze sobą w dany sposób (np. na Slacku) – rób tak samo. Jeśli chcesz, by byli bardziej zaangażowani i terminowi – bądź taki sam.
4.
Cierpliwość i konsekwencja. Z jednej strony nie wszystko stanie się od razu (szczególnie jeśli wymaga gruntownej przebudowy podejścia zespołów). Z drugiej – jeśli coś idzie jak po grudzie, szanse na to, że się w ogóle stanie dążą do zera. Rolą dobrego agile coacha jest odpowiednie dobranie i wyważenie podejścia tak, aby wprowadzać zmiany tak szybko, jak jest to możliwe. Ale nie szybciej…
5.
… na przykład za pomocą konsekwentnie stosowanego wariantu PDCA, czyli PrOpER: Problem – Options – Experiment – Review.
6.
Wprowadzając nową praktykę, warto zbadać podejście do niej u poszczególnych członków zespołu. Czasami proste za/przeciw może być niewystarczające. Więcej informacji da prośba o wskazanie siebie na skali od: „zdecydowanie zgadzam się”, przez „zgoda z drobnymi zastrzeżeniami”, po „mieszane uczucia”, aż po „nie zgadzam się, ale ustąpię większości” i „nie ma takiej opcji”.
7.
Kiedy ktoś opisuje ci problem albo udziela feedbacku to, nawet jeśli masz 8 najgenialniejszych pomysłów i komentarzy na końcu języka, powstrzymaj się i zanim powiesz cokolwiek, upewnij się, że na pewno wysłuchałeś tej osoby do końca i zrozumiałeś jej problem. Jej, a nie twój własny, który jest podobny, lecz nie taki sam. Zastanów się też, jaki jest ich cel w tej rozmowie, co chcą osiągnąć.
8.
Najprostszym sposobem na najszybsze wprowadzenie zmian jest sprawić, by to poszczególne osoby z zespołu uważały się za właścicieli poszczególnych usprawnień. A, aby uważały się za właścicieli tych usprawnień, muszą czuć, że to ich pomysł, albo przynajmniej, że sposób ich wdrażania jest wymyślony przez nich. Uwaga – to nie jest zaproszenie do manipulacji. Bardzo często działanie w sposób wymyślony wspólnie z zespołem da najlepsze rezultaty – w końcu to oni znają dane środowisko najlepiej.
9.
Nawet jeśli poszczególne osoby nie staną się właścicielami danych zmian czy usprawnieńsensu sitricto (np. jako długoterminowi koordynatorzy), dobrze, aby spotkać się, choć w połowie drogi. Niech sami zbadają ten temat, zaproponują pomysły, przedyskutują je. Agile to współpraca i samoorganizacja, to absolutna podstawa. Reszta to tylko upiększenia i usprawnienia.
10.
Jeśli masz zacząć od jakiejś drobnej zmiany, aby sukcesywnie wprowadzić gdzieś agile – zacznij od retrospektyw.
11.
Zadawaj pytania, używaj 5 WHYs, ale nie przesadź. Agile coach to z definicji także mentor, osoba, która zna temat inside-out. Czasami ewidentnie trzeba doradzić i ludzie tego oczekują. Poza tym coaching ma nie najlepszą markę i łatwo, szczególnie na początku współpracy można wpaść w szufladkę manipulatora.
12.
Idź z nim/nimi czasem na lunch, na piwo, na kręgle.
13.
Stand-up – skup się na nim, bo większość zespołów robi go źle. To nie jest status meeting dla managera. Trzy magiczne pytania nie są obowiązkowe – odpowiedzi na nie mogą być częścią każdego standupu, ale chodzi raczej o to by na ich bazie wypracować własny styl, w którym spotkanie będzie krótkie i wartościowe. A wartością jest to, że osoby z zespołu wzajemnie wiedzą co się dzieje w kontekście wpływu na ich własną pracę w ciągu kolejnych 24-48 godzin. Gryź się w język i nie chwal na daily scrum za zamknięte zadania i rozwiązane problemy. Celem nie jest zadowolenie ciebie/szefa, celem jest wymiana informacji. Nawet jeśli wieści nie są najlepsze.
14.
Stand-up to znakomity obiekt do nauki przeprowadzania eksperymentów. Odbywa się codziennie, więc obserwacje i wyniki swoich eksperymentów będziesz mieć bardzo szybko. Twoim celem jest, by angażował uczestników i przynosił jak największą wartość. Eksperymentuj więc i sprawdzaj rozmaite pomysły i podejścia. Nie bądź zbyt ortodoksyjny – chcą co 2 dni – spróbujcie. Product owner chce uczestniczyć – zobaczcie, co z tego wyjdzie. Po hiszpańsku – jeśli tylko zespół o tym marzy i będzie im łatwiej…
15.
Jeśli ludzie na stand-upie wzajemnie się nie słuchają, oznacza to, że nie interesują ich zadania kolegów. A to oznacza, że interesują ich wyłącznie ich zadania, a to oznacza, że ich commitment nie jest dla całego celu sprintu, a dla ich paru tasków. Czyli bardzo źle. Zamiast „sugerować” by się wzajemnie słuchali, wróć do podstaw – dlaczego brak wspólnego commitmentu?
16.
Dobrym przykłademtransparency będzie notowanie wszystkich spraw „do rozwiązania” z daily na zespołowej tablicy w stałym miejscu, nazwanym np. parking lot, a nie w jakimś własnym, osobnym, osobistym kapowniku.
17.
Uświadom im, że SCRUM nie oznacza, że jedyne spotkania, które mają mieć to planning, daily, review i retro. Spotkania ad-hoc wspierające backlog grooming albo dyskusje nad szczegółami architektury nie tylko nie są „zabronione”, są wskazane.
18.
Jeśli dany zespół estymuje (czas lub story points), poradź by na planningu pogrupowali na koniec zadania po wielkości i zobaczyli, czy na pewno takie, które określili np. na 3, faktycznie wyglądają na coś podobnego rozmiaru. Prawdopodobnie okaże się, że nie wyglądają. Jeśli radzą sobie już nieźle przy użyciu estymat, powiedz im o #noestimates.
19.
Zespół, głupcze! Jego dynamika, komunikacja i interakcje to fundament, bez którego 90% wszystkich usprawnień będzie ledwo skutecznych, albo nie zadziała w ogóle. Nacisk w pierwszej kolejności powinien być kładziony na działania poprawiające integracje, motywację i dynamikę zespołu.
20.
W przypadku IT twoją nirwaną są testy automatyczne oraz continuous integration. W takim środowisku ludzie naprawdę mogą skupić się na robieniu dobrego, wartościowego software’u, a nie tylko być stopniowo coraz bardziej zagrzebanymi w bugfixing. W przypadku środowiska non-IT pomyśl, co mogłoby być w danym biznesie rozwiązaniem analogicznym. Ach i bądź świadom, że jak w przypadku każdej nirwany droga do niej jest długa. I bywa bolesna oraz kosztowna.
21.
Design. Zespół musi być świadomy, że dobrego designu nie da się całkiem przewidzieć, zaplanować i omówić nawet na najlepszym planningu. Powinni być zachęceni, aby omawiać i weryfikować konkretne opcje i decyzje z kolegami w trakcie implementacji. A jeszcze lepiej, dodatkowo omawiać z resztą zespołu całość rozwiązania już po jego zaimplementowaniu. To tańsze i mniej frustrujące od permanentnej palącej potrzeby przepisania 3/4 systemu,
22.
Dobre pytanie na osobne spotkanie (na retro to może być za wiele): co was najbardziej denerwuje w obecnym stanie kodu w projekcie oraz w sposobie, w jaki ten kod jest rozwijany? Jeśli czują się przytłoczeni legacy code, ale uważają, że nie da się tego naprawić – oczywiście zadaj pytanie „a jaką jedną małą rzecz dałoby się poprawić, aby było lepiej”. Dalej już wiesz.
23.
Retrospektywa. Dobra technika do rozpoczęcia dyskusji to Lean Coffee. Najważniejsze jednak to, by retro było konstruktywne. Czyli poza listą problemów był czas na omówienie ich potencjalnych przyczyn (co komu po niwelowaniu symptomów) oraz identyfikację konkretnych akcji do realizacji. Ciekawym sposobem na to ostatnie jest prośba, aby każdy z członków zespołu zanotował na kartce, co wg. niego należałoby uczynić w danym obszarze, następnie te listy konfrontowane są w parach, a następnie grupowo. Na końcu – o ile usprawnienie nie wchodzi bezpośrednio do backlogu – upewnij się, że te akcje kłują w oczy gdzieś w widocznym miejscu.
24.
Prime directive dla retrospektywy: zakładamy, może i nawet czasem dość naiwnie, że każdy wykonywał swoją pracę najlepiej jak umiał. Nie zaczynamy festiwalu obwiniania, skupiamy się na konstruktywnych pozytywnych akcjach. Nawet jeśli ktoś zapomniał (po raz n-ty), to czy naprawdę zrobił to złośliwie? To może wprowadzić prosty system, który mu następnym razem przypomni…?
Autor tekstu: Igor Mróz – doświadczony Project Manager, CEO Zero Bullshit Management.
Poznaj Podstawy zarządzania projektami, bez bullshitu
Autor tekstu:
Poznaj Podstawy zarządzania projektami, bez bullshitu