Czym jest „Squad Health Check Model" Spotify?
Wiele firm eksperymentuje z najróżniejszymi sposobami oceny i wizualizacji tego, gdzie stoją ich zespoły. Zwykle odbywa się to za pomocą tak zwanych Maturity Models (modeli dojrzałości), które przedstawiają rozwój przez różne poziomy.
Intencje stojące za takimi modelami są zazwyczaj pozytywne – na przykład gdy menedżerowie, osoby odpowiedzialne za przywództwo lub coachowie w większych organizacjach chcą lepiej wyczuć, gdzie powinien być skoncentrowany ich wysiłek w zakresie usprawnień i problemów, lub gdy chcą pomóc swoim zespołom stać się bardziej refleksyjnymi, aby one same mogły lepiej koncentrować się na własnych usprawnieniach.
Wolę jednak nazywać to „Health Check Model" (modelem kontroli stanu zdrowia) niż „Maturity Model", gdyż ten drugi brzmi… cóż… trochę protekcjonalnie. Ponadto większość naszych modeli nie obejmuje rozwoju przez różne poziomy. Główną grupą docelową jest sam zespół, a nie kierownictwo.
Ulepszanie organizacji często przypomina zgadywankę (skąd wiadomo, co wymaga poprawy? I skąd wiadomo, czy coś się poprawiło?). Systemowe podejście z wyraźną wizualizacją może zredukować tę zgadywankę do minimum.
Ok, ale czy takie modele rzeczywiście działają?
To zależy. W niektórych przypadkach te modele mogą być naprawdę pomocne. Czasem jest to raczej „meh" – ludzie wypełniają swój obowiązek i uczestniczą w warsztatach, ankietach itp., ale wynikające z tego dane są ignorowane.
Ale bądź ostrożny. Widzieliśmy, jak takie modele stawały się w niektórych firmach prawdziwymi potworami; systemowym narzędziem ucisku, które powoduje suboptymalizację i strach. Menedżerowie używają modelu dojrzałości do oceniania zespołów i stawiania ich przeciwko sobie, a zespoły ukrywają swoje problemy, żeby wyglądać dobrze. I to jest absolutnie złe!
Chociaż potencjalna szkoda jest prawdopodobnie bardziej realna niż potencjalna korzyść, JEST potencjalna korzyść i istnieją sposoby uniknięcia katastrofy.
W Spotify eksperymentowałem z tym przez kilka lat i znalazłem sposoby, które działają całkiem dobrze (czyli mają więcej zalet niż wad) – w najlepszym przypadku są „pomocne", w najgorszym „meh", a do tej pory nigdy nie były „katastrofą". Ten Health Check Model wdrożyliśmy też w kilku innych firmach i uzyskaliśmy podobne wyniki, więc pomyślałem, że czas napisać o tym artykuł.
Dla kogo jest Health Check Model?
W modelu Health Check Squada (nasze określenie małego, interdyscyplinarnego, samozorganizowanego zespołu developerskiego) istnieją głównie dwaj interesariusze:
1) Sam Squad
Omawiając poszczególne wskaźniki, członkowie Squada mogą lepiej zrozumieć, co dla nich działa, a co nie. Szeroki zakres pytań pomaga im poszerzać horyzonty. Być może są świadomi problemów z jakością kodu, ale nie zastanawiali się naprawdę nad wartością z perspektywy klienta ani nad tym, jak szybko mogą się uczyć. Ponadto uwidaczniane są zarówno dobre rzeczy, jak i negatywne punkty.
2) Osoby wspierające Squad.
Menedżerowie i coachowie pracujący poza zespołem (lub przynajmniej częściowo poza zespołem) otrzymują przegląd wszystkich rzeczy, które działają i które nie działają. Ponadto mogą dostrzegać wzorce między różnymi Squadami. Gdy ma się dziesiątki zespołów i nie można rozmawiać z każdym o wszystkim, taki przegląd może pomóc ustalić, jak najlepiej wykorzystać swój czas i z kim o czym rozmawiać.
Świadomość problemu to pierwszy krok do jego rozwiązania. Ten rodzaj wizualizacji znacznie utrudnia ignorowanie problemu.
Jak to robimy w Spotify
Głównie robimy trzy rzeczy:
Prowadzimy warsztaty, w których członkowie Squada omawiają i oceniają swoją aktualną sytuację pod różnymi kątami (np. jakość, zabawa, wartość itp.)
Tworzymy graficzne podsumowanie wyników
Pomagamy Squadom się poprawiać
Mamy różne warianty. Jeden nazywamy po prostu „Squad Health Check Model", inne noszą nazwy np. „Fluent@Agile Game" lub „Quarterly Reflection". „Health Check Model" jest ulepszoną wersją kwartalnego badania „Autonomous Squads" wspomnianego w 2012 r. w artykule Scaling Agile @ Spotify.
Oto prawdziwy przykład modelu Health Check dla „Tribe":
Tutaj przedstawiono, jak 7 różnych Squadów ocenia swoją własną sytuację. Kolory pokazują, jak jest aktualnie (zielony=dobrze, żółty=kilka problemów, czerwony=bardzo źle). Strzałki wskazują trend (czy się poprawia, czy pogarsza?).
Jeśli dokładnie przyjrzysz się diagramowi przez kilka minut, zauważysz kilka ciekawych rzeczy:
W kolumnach możesz zobaczyć główne różnice między poszczególnymi Squadami. Squad 4 jest zadowolony z prawie wszystkiego. Squad 2 ma wiele problemów, jednak istnieje pozytywny trend w prawie wszystkich punktach.
W wierszach możesz dostrzec systemowe wzorce. Każdy Squad bawi się podczas pracy (a trend jest jeszcze bardziej pozytywny!). Motywacja wydaje się zatem nie być problemem. Jednak proces wydawania sprawia problemy, a baza kodu też nie wygląda zbyt dobrze. Z czasem z pewnością wpłynie to też na frajdę z pracy.
W ogólnym obrazie można zobaczyć, że prawie wszystkie strzałki wskazują w górę, w całym diagramie są tylko 2 strzałki skierowane w dół. Oznacza to, że proces ulepszania (najważniejszy ze wszystkich procesów) wydaje się działać.
To jest oczywiście tylko przybliżone odwzorowanie rzeczywistości („Wszystkie modele są błędne, ale niektóre są użyteczne" – George Box). Dlatego dobrym pomysłem jest ponowne sprawdzenie wszystkiego przed podjęciem konkretnych działań.
Czy w Squadzie 4 naprawdę wszystko idzie tak dobrze, czy po prostu są optymistyczni i nie widzą swoich problemów? Większość Squadów uważa, że dostarcza wartość swoim klientom – ale skąd to wiedzą? Czy ta opinia opiera się na życzeniu, czy na prawdziwej informacji zwrotnej od klientów?
Squad 4 z naszego przykładu został faktycznie stworzony dopiero tydzień przed przeprowadzeniem Health Checku. Byli zatem zdecydowanie jeszcze w fazie orientacyjnej (zwanej też fazą Forming lub fazą miesiąca miodowego). Z tego powodu zarówno Squad 2, jak i Squad 4 potrzebowały dużo wsparcia.
Łatwa dostarczalność była tu dużym problemem. Skupiono się zatem bardziej na rzeczach takich jak Continuous Delivery (ciągłe dostarczanie) i wkrótce można było zauważyć wyraźną poprawę.
Pamiętaj, że jest to model samooceny; oparty na uczciwości i subiektywnej opinii członków Squada. Działa więc tylko w środowisku opartym na zaufaniu, w którym ludzie mogą być pewni, że ich menedżerowie i współpracownicy działają w ich interesie. Zbieranie danych jest dość łatwe – chodzi zatem głównie o to, że nie powinno być konkretnych powodów, by to robić.
Na szczęście w Spotify istnieje takie środowisko zaufania, a menedżerowie i coachowie bardzo dbają o komunikowanie, że jest to narzędzie do wspierania, a nie do oceniania Squadów.
Jak zbieramy dane
Mamy doświadczenie, że ankiety online do takich celów są totalnie do niczego. Wynika to głównie z faktu, że nie umożliwiają konwersacji, a to jest właśnie to, co ma największą wartość. Podczas gdy członkowie Squada rozmawiają, zyskujesz kolejne spostrzeżenia, a coach odkrywa, jak skutecznie pomóc Squadom. Same dane pokazują tylko niewielką część ogólnego obrazu, co może być mylące.
Dlatego organizujemy (zazwyczaj zwinni coachowie) warsztaty ze Squadami i zachęcamy do bezpośredniej konwersacji na temat różnych wskaźników „Health Check Modelu". Jedna do dwóch godzin zazwyczaj wystarczy.
Do moderacji używamy zestawu tak zwanych „Awesome Cards". Każda karta reprezentuje jeden ze wskaźników i zawiera zarówno „Example of Awesome" (przykład czegoś wspaniałego), jak i „Example of Crappy" (przykład czegoś złego).
Zestaw zazwyczaj składa się z około 10 kart. Oto przykład kompletnego zestawu:
Przy każdym pytaniu Squady są pytane, czy bliżej im do „Awesome" czy do „Crappy". Aby ułatwić im uzgodnienie koloru dla wskaźników i odpowiedniego trendu (stabilny, trend wzrostowy/spadkowy), używamy podstawowych metod warsztatowych, takich jak Dot Voting.
Oto karty w formacie PDF do pobrania
Stosujemy trzy poziomy, co jest dość proste (zielony/żółty/czerwony). Dokładna definicja kodowania kolorów może się różnić, ale opiera się na następujących stwierdzeniach:
Zielony niekoniecznie oznacza, że wszystko jest doskonałe. Oznacza tylko, że Squad jest zadowolony i aktualnie nie widzi dużej potrzeby usprawnień.
Żółty oznacza, że istnieją pewne problemy, które powinny być rozwiązane, ale nie są katastrofą.
Czerwony oznacza, że coś naprawdę idzie nie tak i wymaga poprawy.
Tak, są to dane subiektywne. Teoretycznie każdy Squad może uwzględnić obiektywne dane (czas cyklu, liczba defektów, Velocity itp.). Robi to jednak bardzo niewielu. Wynika to z faktu, że Squady muszą też interpretować obiektywne dane i decydować, czy oznaczają one, że mają problem, czy nie. Ostatecznie wszystko jest więc subiektywne. Jeśli coś czuje się jak problem, to jest problemem.
Czasem łączymy to z Retrospektywami, np. wybierając kartę, a następnie wymyślając działania naprawcze.
Jakie pytania należy zadawać?
Jeśli przyjrzysz się powyższym przykładom, zauważysz, że pytania nie zawsze są takie same. To dobry przewodnik:
Pytania powinny obejmować szeroki zakres różnych perspektyw.
Te pytania są jedynie punktem wyjścia, przykładowym wstępnym wyborem. Squady mogą swobodnie decydować, czy chcą usuwać, dodawać lub zmieniać pytania, jeśli uważają, że ma to sens.
Staraj się ograniczyć liczbę pytań do ok. 10 pytań. Przy większej liczbie pytań mogą szybko pojawić się nakładania, które można usunąć.
Należy zadbać o to, aby pytania dotyczyły środowiska, w którym Squad pracuje, a nie twardych danych (takich jak np. Velocity). Dzięki temu całość jest mniej groźna i podkreśla, że chodzi o wsparcie i ulepszanie – a nie o ocenianie.
Nasze założenie (prawdziwe czy nie) jest takie, że Squad ma wewnętrzną motywację do osiągania sukcesów i do dawania z siebie jak najlepszego w danych okolicznościach.
Jak często mierzymy kondycję Squadów?
Jak powiedziano, mamy różne modele, z których korzystamy, dlatego jest to bardzo różne. Nie znaleźliśmy jeszcze żadnego konkretnego „idealnego interwału" dla takich rzeczy (i prawdopodobnie nigdy go nie znajdziemy).
Kwartalnie wydaje się jednak dobrym punktem wyjścia. Miesięcznie jest prawdopodobnie zbyt często (ludzie szybko się tym znudzą, a dane nie zmieniają się wystarczająco szybko). Dwa razy w roku wydaje się zbyt rzadko (w pół roku może się po prostu zbyt wiele wydarzyć). Ale jak wspomniano, jest to zawsze różne.
Wniosek – na co zwrócić uwagę, jeśli chcesz to wypróbować
Taki model MOŻE pomóc w napędzaniu usprawnień. Może jednak też wywrócić całą kulturę firmy do góry nogami, jeśli nie zostanie prawidłowo zastosowany! Dlatego należy zawsze postępować ostrożnie.
Oto kilka wytycznych zwiększających prawdopodobieństwo sukcesu:
Bądź świadomy motywów wprowadzenia modelu. Powinno zawsze chodzić o ulepszanie, a nie o ocenianie.
Dane powinieneś zbierać głównie przez bezpośrednią komunikację, a nie przez ankiety online. Ten proces powinien być interesujący i przyjemny.
Angażuj zespoły w stosowanie modelu i pozwól im na dostosowania według ich potrzeb.
Akceptacja zespołu jest ważniejsza niż spójność danych. Jeśli Zespół A wybierze nieco inny zestaw pytań niż Zespół B, to jest w porządku (nawet jeśli podsumowanie staje się przez to nieco mniej przejrzyste).
Upewnij się, że nie ma motywacji do oszukiwania. Dla zespołu nie powinno być powodów, by chciał się przedstawiać lepiej, niż jest w rzeczywistości.
Znajdź prosty sposób wizualizacji danych. Im bardziej oczywista i intuicyjna wizualizacja, tym większe prawdopodobieństwo, że będzie używana.
Unikaj porównywania zespołów ze sobą. Jeśli Zespół A ocenia punkty głównie na zielono, a Zespół B w dużej mierze na czerwono, nie oznacza to automatycznie, że Zespół A jest „lepszy". Równie dobrze mogłoby to oznaczać, że Zespół A ma łatwiejszy kontekst, jest bardziej optymistyczny lub że Zespół B jest bardziej szczery co do trudności. Niezależnie od powodu, oznacza to po prostu, że Zespół B potrzebuje trochę więcej wsparcia. Postawa menedżera powinna być „Jak mogę pomóc?" a nie „Dlaczego jesteście tak dużo gorsi od innych?".
Rób follow-up. Zadawaj pytania takie jak: „Czy ten model wam pomaga?", „Gdybyśmy nie przeprowadzali już Health Checków, czy brakowałoby wam ich?" lub „Jak moglibyśmy jeszcze bardziej usprawnić ten model?". Model (i sposób jego stosowania) musi być stale ulepszany.
