Prędkość Twojego zespołu właśnie spadła o 30% w ciągu dwóch sprintów. Na wykresie wzór jest niewątpliwy. Zainteresowane strony zaczęły pytać. Premier patrzy na ciebie. Masz plany na jutro.
To jeden z najbardziej stresujących momentów w zarządzaniu inżynierią. Jest to również jedno z najczęściej błędnie diagnozowanych schorzeń.
Oto aktualny podręcznik; co sprawdzić najpierw, siedem rzeczywistych przyczyn (w kolejności prawdopodobieństwa) i co nie robić pod presją.
Po pierwsze: nie panikuj i nie obwiniaj zespołu
Przed jakąkolwiek diagnozą warto zinternalizować dwie rzeczy:
Spadek sprintu 1-2 to hałas, a nie sygnał. Prędkość jest naturalnie głośna; choroba, wakacje, jeden paskudny zadanie. Jeśli Twój ostatni sprint miał 32 punkty, a pięć poprzednich to 38–42, jest to wariancja, a nie trend. Nie reaguj.
Sygnałem jest spadek po 3 sprintach. Jeśli trzy kolejne sprinty są o 25-30% poniżej poprzedniego poziomu bazowego, coś się zmienia. Zbadać.
Największą awarią na tym etapie nie jest zła diagnoza; to menadżer, który reaguje na hałas tak, jakby był sygnałem i zaczyna mocniej naciskać. W ten sposób możesz zamienić chwilową kąpiel w prawdziwą.
Co prawie nigdy nie jest
Zanim wymienisz prawdziwe przyczyny, podaj te niewłaściwe. Oto wyjaśnienia, po które menedżerowie sięgają jako pierwsi i prawie zawsze się mylą:
- „Zespół się osłabia”. Nie. Inżynierowie, którzy pływali z prędkością X, nie przestają się nagle tym przejmować. Coś zmieniło się w pracy lub środowisku, a nie w ich motywacji.
- „Potrzebują więcej dyscypliny”. Nie. Jeśli Twój proces działał z prędkością X, nadal działa. Dodanie ceremonii pogarsza sytuację.
- „Potrzebują kopa”. Nie. Zespół może już zobaczyć wykres. Czują tę samą presję co Ty. Dodanie ciśnienia pogłębia problem.
Jeśli po nie sięgniesz, zwolnij. Rzeczywista przyczyna jest prawie zawsze strukturalna.
Siedem prawdziwych przyczyn (w kolejności prawdopodobieństwa)
1. Zmieniono jakość lunety
To jest przyczyna nr 1, której nie widać na wykresie.
Jak to wygląda: zadania są coraz większe, twardsze i bardziej niewyraźne niż kiedyś. Zespół podnosi „5 punktów” pracy, otwiera je i zdaje sobie sprawę, że tak naprawdę jest ich 13. Kończą pracę; ale to nie jest ta sama praca. Wykres pokazuje spadek prędkości. W rzeczywistości kalibracja punktów/pracy dryfowała.
Jak sprawdzić: wyciągnij 5 ostatnich zadań „5-punktowych”. Przeczytaj je. Czy są one mniej więcej porównywalne z zadaniami za 5 punktów sprzed 8 sprintów? Jeśli nowe są bardziej skomplikowane (więcej zależności, więcej niewiadomych, więcej starszego kodu), nie zwalniasz; pracujesz nad trudniejszymi problemami o tej samej skali.
Poprawka: przestań porównywać aktualną prędkość ze starszą prędkością. Zresetuj linię bazową. Lub; lepsza; naprawić zakres. Naciskaj na wyraźniejsze zadania, mniejsze historie i mniej niewiadomych wpływających na planowanie sprintu.
2. Ludzie się zmienili
Ktoś odszedł. Ktoś się dołączył. Ktoś teraz wykonuje 30% pracy PM. Ktoś jest na urlopie rodzicielskim przez 4 sprinty.
Jak sprawdzić: wykorzystaj potencjał zespołu na ostatnie 3 sprinty w porównaniu z poprzednimi 5. Użyj współczynnika skupienia, a nie liczby pracowników; starszy inżynier przeprowadzający 70% rozmów kwalifikacyjnych nie ma zdolności 1,0, ma 0,3.
Poprawka: jeśli jest to tymczasowy spadek wydajności, nazwij to wyraźnie podczas planowania. „W tym sprincie mamy pojemność 0,7, więc celem powinno być 28 punktów, a nie 40”. Przestań udawać, że zespół pracuje na pełnych obrotach, gdy tak nie jest.
3. Dług technologiczny przekroczył próg
Prędkość spada stopniowo wraz ze starzeniem się bazy kodu, a czasami gwałtownie spada, gdy krytyczny element infrastruktury zaczyna się wyginać. Zestaw testów, który trwał 8 minut, teraz trwa 45 minut. Wdrożenie, które trwało 5 minut, wynosi teraz 30. CI jest niestabilne. Konstrukcja psuje się dwa razy dziennie.
Jak sprawdzić: czas cyklu dla „trywialnego” zadania (zmiana kopii w jednym wierszu, zmiana wersji itp.). Jeśli wysyłka zadania za 1 punkt zajmuje teraz 2 dni, wąskie gardło nie jest rozwiązaniem; to otaczający go system.
Poprawka: poświęć 20% następnego sprintu na konkretne wąskie gardło (szybkość testowania, niezawodność wdrażania, niestabilność kompilacji). Jest to dostępna interwencja o największej dźwigni, a zarazem najrzadziej stosowana. Zespół, który nie może wysłać zadania za 1 punkt w czasie krótszym niż 4 godziny, ma problem, który się komplikuje.
4. Zależności/zewnętrzne blokery
Praca zespołu zależy teraz od pracy innego zespołu. Czekają na dostęp do API, specyfikacje projektowe, przegląd bezpieczeństwa i ocenę prawną. zadania wchodzą w stan „w toku” i pozostają tam.
Jak sprawdzić: zliczyć zadania „w toku” / „w przeglądzie” bez ruchu przez ponad 3 dni. Przeczytaj dlaczego. Jeśli komunikat „Zablokowany przez inny zespół” pojawi się więcej niż raz, jest to przyczyna.
Poprawka: zależności nazw wcześniej planowanie sprintu, a nie w trakcie sprintu. Jeśli zadanie wymaga projektu, który nie będzie istniał przez tydzień, nie planuj go w tym sprincie. Przesuń to. Planuj tylko taką pracę, którą zespół może faktycznie ukończyć.
5. Odwrócona inflacja punktów fabularnych
Jeśli Twój zespół hojnie dobierał zadania (zaokrąglając od 3 do 5, od 5 do 8) przez kilka sprintów, wykres prędkości jest sztucznie zawyżony. Kiedy szacunki wracają do rzeczywistości; zwykle po wprowadzeniu udoskonaleń lub dołączeniu nowego lidera technologicznego; prędkość „spada” i nikt nie pracuje mniej.
Jak to sprawdzić: zapytaj zespół, czy szacowanie stało się ostatnio bardziej uczciwe lub czy dołączyła nowa osoba, która wycofuje się z zawyżonych szacunków. Jeśli tak, spadek jest kalibracją, a nie regresją.
Poprawka: wyjaśnij to zainteresowanym stronom. Zresetuj linię bazową. Porównuj następny sprint z następnym sprintem, a nie z zawyżoną przeszłością.
6. Prace przesunęły się z funkcji na refaktoryzację/infrastrukturę/odkrywanie
Zespół dostarczający funkcje wchodzi w fazę, w której przeprowadza poważne przepisanie, migrację infrastruktury lub wstępne odkrywanie funkcji. Ta praca jest realna i konieczna, ale nie pasuje do „punktów historii na sprint”.
Jak sprawdzić: spójrz na rodzaje zadań. Jeśli 60% ostatniego sprintu stanowiła infrastruktura/refaktoryzacja/skoki, liczba prędkości jest myląca. Zespół pracuje równie ciężko, tylko nad trudniejszymi zadaniami.
Poprawka: śledź pracę infrastruktury niezależnie od prędkości działania. Dwie metryki: punkty charakterystyczne i godziny „inwestycji”. Nie utożsamiaj ich.
7. Dryf procesowy / nowe ceremonie
Ktoś dodał nowe spotkanie. Ktoś dodał krok przeglądu bezpieczeństwa. Ktoś wprowadził dłuższą umowę SLA dotyczącą przeglądu kodu. Każda indywidualna zmiana jest niewielka. Skumulowany efekt jest realny.
Jak sprawdzić: wypisz każdą nową zmianę procesu w ostatnim kwartale. Zsumuj godziny przypadające na osobę. Jeśli zespół ma o 3 godziny mniej czasu na kodowanie tygodniowo na osobę, zauważyłeś spadek szybkości o 12%.
Poprawka: kwestionuj każdy ostatni dodatek do procesu. Co tak naprawdę łapie, czego wcześniej nie łapano? Czy połów jest wart swojej ceny?
Co zrobić jutro w planowaniu
Planujesz rano. Wykres wygląda źle. Oto scenariusz jednego spotkania:
- Otwórz się szczerze. "Prędkość spadła w ciągu ostatnich 3 sprintów. Chcę, żebyśmy planowali w oparciu o rzeczywistą pojemność, a nie stare liczby. Prawidłowo zdiagnozujemy retro; na razie planujmy uczciwie."
- Aby ustawić pojemność, użyj ostatnich 3 sprintów, a nie bieżących 5. Jeśli ostatnio prędkość wynosiła 30, zaplanuj 30. Oprzyj się pokusie „rozciągania”.
- Ogranicz zakres, nie poddawaj szacunków. Jeśli masz 40 punktów „must-have”, ale pojemność wynosi 30, odetnij 10 punktów „must-have”. Nie próbuj tego oceniać.
- Zidentyfikuj jedną blokadę strukturalną, którą zespół ma się zająć. Szybkość testu, podatek uzależniający, przejrzystość zadania; wybierz jeden. Zarezerwuj dla niego 20% pojemności. To jest dźwignia, a nie surowy wysiłek.
To pojedyncze spotkanie; trzymany uczciwie; przywraca więcej pewności niż jakakolwiek obietnica „nadrobimy zaległości w następnym sprincie”. Interesariusze wolą liczbę rzeczywistą od aspiracyjnej.
Czego NIE robić
W przybliżeniu kolejność spowodowanych uszkodzeń:
- Nie dodawaj ceremonii, aby „zwiększyć widoczność”. Więcej stand-upów, więcej raportów o statusie, więcej synchronizacji; wszystko to skraca czas dostępny na pracę, która i tak jest krótka.
- Nie proś zespołu, aby „bardziej się zaangażował”. Szybkość nie jest funkcją zaangażowania, jest funkcją rzeczywistej wydajności i przejrzystości pracy. „Zaangażuj się mocniej” brzmi jak przywództwo; ląduje jak wina.
- Nie resetuj punktów historii, aby „sprawić, że wykres będzie wyglądał lepiej”. Zawyżanie szacunków do tempa historycznego jest oszustwem. Uniemożliwia także planowanie przyszłości.
- Nie mierz jednostek. „Spadek prędkości Alicji” to najgorsza możliwa diagnoza. Punkty fabularne są miarą zespołu.
- Nie zakładaj, że jest to trwałe. Większość spadków prędkości ma konkretną przyczynę, która po znalezieniu ma konkretną naprawę. Potraktuj to jako zagadkę, a nie werdykt.
Retro po kąpieli
Kiedy już uczciwie zaplanujesz następny sprint, przeprowadź skoncentrowany retrospekcję na dipie. Format:
- Co się zmieniło. Zrób harmonogram ostatnich 12 tygodni. Odejścia, nowi pracownicy, zmiany w procesach, rozpoczęcie projektów, incydenty infrastrukturalne. Nazwij wszystko.
- Co zauważyliśmy. Niech każda osoba napisze jedną rzecz, która była najbardziej bolesna w ciągu ostatniego miesiąca. Najpierw przeczytaj po cichu, potem dyskutuj.
- Co zmienimy. Wybierz jedną poprawkę strukturalną. Nie trzy. Jeden. Uruchom go przez 3 sprinty, a następnie oceń ponownie.
Zespół, który właśnie stracił prędkość, jest kruchy. Nie nakładaj zmian na wierzch. Wybierz jedno rozwiązanie, które najbardziej poruszy igłą, wyślij je i zobacz, co się zmieni.
Szczere podsumowanie
Spadki prędkości zdarzają się każdemu zespołowi. Rzadko dotyczą wysiłku, prawie zawsze dotyczą zakresu, wydajności lub kondycji systemu. Diagnozuj spokojnie, planuj uczciwie, napraw jedną rzecz strukturalnie i powstrzymaj się od chęci dodawania presji.
Zespoły, które szybko się regenerują, nie są tymi, które pracowały najciężej po spadku; to oni jasno określili przyczynę i zajęli się nią bez zbędnych ceremonii. Na tym polega w tej chwili rzeczywista praca przywództwa.
Prędkość jest sygnałem zwrotnym. Kiedy sygnał się porusza, coś ci mówi. Posłuchaj go, zamiast próbować go uciszyć.
Narzędzia, które pomogą:
- Kalkulator prędkości sprintu: śledź prędkość z ostatnich 5 sprintów, bezpłatnie i bez rejestracji.
- Kalkulator wydajności sprintu: ustaw realistyczną pojemność za pomocą współczynnika skupienia.
- Ocena dojrzałości sprintu: szybka diagnostyka dotycząca współczynnika trafień, pełzania zakresu, blokerów, śledzenia działań retro.
- Samoocena dojrzałości sprintu: 10 pytań w 6 wymiarach, z trzema konkretnymi działaniami w ramach następnego sprintu na każdym poziomie.
Powiązana lektura:
- Porównanie zwinnych technik estymacji: jeśli spadek prędkości ukrywa szacunkowy dryft kalibracji, jest to porównanie pięciu rzeczywistych technik i sposobu przełączania bez spalania sprintu.
SprintFlint automatycznie wyświetla prędkość, czas cyklu i trend współczynnika trafień. Kiedy wykres się poruszy, zobaczysz dlaczego, zanim zrobią to interesariusze. 50 bezpłatnych zadań miesięcznie: brak karty.