Jeśli zapytasz większość menedżerów o "bezpieczeństwo psychologiczne" lub "wizję" (czytaj więcej: Bezpieczeństwo psychologiczne) swoich zwinnych zespołów programistycznych, zgadzają się, że te rzeczy są ważne, ale... Kiedy klient sygnalizuje pilną potrzebę lub zbliża się termin, wszystkie te "bardziej miękkie" zmienne są zazwyczaj odkładane na dalszy plan. Menedżerowie są przede wszystkim zainteresowani przewidywalnie funkcjonującym, zwinnym przepływem dostaw z ich zwinnego zespołu.

Jeśli zajrzysz na nasz blog Echometer (na nasz blog), wiesz, że nasze treści koncentrują się na doskonaleniu umiejętności miękkich zespołów i organizacji. Są one często niedoceniane przez decydentów. Ale nie przez Scrum Masterów i Agile Coachów.

To, czego moim zdaniem Scrum Masterzy i Agile Coachowie ponownie nie doceniają, to skupienie się na poprawie przepływu dostaw –, czyli zasadniczo na tym, czego chcą menedżerowie. W dzisiejszym wpisie opiszę prostą technikę, dzięki której znacząco zwiększysz prawdopodobieństwo dostarczenia produktu na czas i zgodnie z budżetem.

Krok 1 w odniesieniu do Twojego zwinnego przepływu dostaw

Mówię o monitorowaniu przepływu realizacji zadań w ramach Agile. Jeśli zrobisz tylko kilka rzeczy dobrze, będziesz w stanie dostarczać znacznie bardziej przewidywalne wyniki. Nawet twoje wykresy rozrzutu czasu cyklu lub symulacja Monte Carlo do obliczania szacunków projektu mogą w końcu wskazywać prawidłowe prognozy, zamiast być całkowicie nietrafione (czytaj więcej: 9 Metryki Agile dla decydentów).

Pierwszym symptomem, z którym należy walczyć, jest to, że istnieją zadania, które zajmują tylko kilka dni od "Zaplanowane" do "Ukończone", a następnie są zadania, które zajmują ponad miesiąc. Aby temu przeciwdziałać, powinieneś upewnić się, że zadanie zawsze zawiera najmniejszą możliwą do dostarczenia wersję pożądanej funkcji. Bez dzwonków i gwizdków, które nie są konieczne dla głównego żądania klienta. Zasadniczo jest to MVT, Minimum Viable Task. Nie oznacza to, że każde zadanie będzie małe. Ale powinno pomóc Ci osiągnąć etap, w którym zadania zajmują najwyżej kilka tygodni, a nie miesięcy.

Drugi krok w odniesieniu do twojego Agile Delivery Flow: WIP zamiast Velocity

Wielu Scrum Masterów lub trenerów Kanban uważa, że prawidłowy pomiar szybkości itp. zależy od "właściwego rozmiaru" zadań lub elementów pracy, gdzie wszystkie elementy pracy mają w przybliżeniu ten sam rozmiar. Tylko wtedy story pointy (które są potrzebne do pomiaru szybkości) są przydatne do pomiaru szybkości, ponieważ wydają się bardziej porównywalną jednostką czasu. 

Ale to błąd: zadania nie muszą być nawet podobnej wielkości. Nie powinieneś tego zakładać, ponieważ zbyt trudno jest kontrolować szacunki Story Point. Jedyną rzeczą, którą możesz kontrolować, jest liczba nowych zadań, które rozpoczynasz.

Wykonaj następujące czynności, aby stać się przewidywalnym: Monitoruj wskaźnik "rozpoczętych nowych zadań" w porównaniu do wskaźnika "ukończonych zadań". Te dwa wskaźniki powinny być w równowadze. Innymi słowy, wskaźniki "wejścia" i "wyjścia" z zadań powinny być jak najbardziej zbliżone, a najlepiej nawet takie same.

Przykład: Typowym zachowaniem w zespołach programistów jest to, że gdy tylko zadanie zostanie zablokowane, uruchamiany jest nowy element pracy. Prowadzi to do tego, że wiele zadań jest otwartych, ale niedokończonych, co znacznie komplikuje ich ponowne odblokowanie. 

Zamiast tego, jeśli upewnisz się, że dla każdego rozpoczętego zadania istnieje również zadanie ukończone, będziesz w stanie lepiej odblokować kilka skoncentrowanych zadań w Daily. Twoja ogólna wydajność będzie bardziej przewidywalna –, a zespół będzie szczęśliwszy, ponieważ twój menedżer i klienci będą bardziej zadowoleni.

Niektóre "pozytywne symptomy" zdrowego przepływu Agile Delivery

W praktyce prowadziłoby to do następujących zachowań:

• • Nie rozpoczynamy nowych zadań, gdy wiele rzeczy jest jeszcze w toku. 

• • Skupiamy się na dokończeniu tego, co zaczęliśmy, zanim zaczniemy nowe rzeczy.

• • Wiek zadań nigdy nie przekracza kilku tygodni.

• • Jeśli nie ma dobrego powodu, zawsze pracujemy nad najstarszym zadaniem.

Pomagają w tym również limity WIP (work-in-progress), choć często nie są one wystarczające. Gdy zespół nauczy się koncentrować na kończeniu zadań, a nie tylko rozpoczynaniu nowych, będziesz lepszy niż większość zespołów.

Jeśli używasz Agile Delivery Flow prawidłowo

Aby stworzyć jasne oczekiwania: W ten sposób nadal nie możesz kontrolować, czy zadanie zajmie dwa czy trzy dni. Ale przynajmniej upewniasz się, że Twój zespół nie pracuje nad tak wieloma zadaniami, że 2-3 dniowe zadania zajmują miesiąc.

O ile lepiej pracowałoby się Twojemu zespołowi, gdybyś wiedział, że zasadniczo wszystkie zobowiązania związane z dostawą zostaną spełnione w ciągu kilku tygodni? Zakłada to oczywiście, że wdrożysz wszystkie rzeczy wymienione powyżej: Ustalanie MVT, ścisły limit WIP i zobowiązanie do nierozpoczynania zadań, dopóki inne zadanie nie zostanie ukończone.

Krok 3: Rozpocznij pracę nad usprawnieniem Agile Delivery Flow

Teoretycznie wiesz, co robić. Jaki jest teraz najlepszy sposób, aby zacząć praktycznie? Tworząc świadomość i "gotowość do zmian" w zespole. W najlepszym przypadku poprzez autorefleksję.

Musisz być przejrzysty w kwestii tych liczb i regularnie je sprawdzać, aby sprawdzić, czy stosunek rozpoczętych i ukończonych zadań jest zrównoważony. Częścią retrospektywy może być zagłębienie się w temat i zastanowienie się, dlaczego liczby nie były zrównoważone w ostatnim cyklu. 

Mogę polecić omówienie zachowań, o których wspomniałem, za pomocą naszego zwinnego narzędzia retrospektywnego Echometer w Twojej retrospektywie (przeczytaj więcej: 7 Porównanie narzędzi retrospektywnych). Możesz nawet uczynić to częścią swoich umów roboczych lub regularnych spotkań Health Check, aby zwiększyć świadomość poprzez regularne zadawanie pytań.

Poniższe pytania stanowią nasz szablon retrospektywy dla "zwinnego dostarczania" (czytaj więcej): 22 zabawne szablony do zwinnych retrospektyw). Zaczynamy od kilku stwierdzeń Health Check i pytamy zespół, czy się z nimi zgadzają, czy nie. Następnie zadajemy kilka pytań otwartych: