Agile Delivery Flow: Zawsze dostarczaj na czas w 3 krokach

Jeśli zapytasz większość menedżerów o “bezpieczeństwo psychologiczne” lub “wizję” (więcej na ten temat: Bezpieczeństwo psychologiczne ) ich zespołów zwinnego tworzenia oprogramowania, zgodzą się, że te rzeczy są ważne, ale… Kiedy klient sygnalizuje pilność lub zbliża się termin, wszystkie te “miękkie” zmienne są zazwyczaj odkładane na bok. Menedżerowie są przede wszystkim zainteresowani przewidywalnie działającym zwinnym przepływem dostarczania ich zwinnego zespołu.

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

Moim zdaniem to, co z kolei niedoceniają Scrum Masterzy i Agile Coache, to koncentracja na poprawie przepływu dostarczania - zasadniczo tego, czego chcą menedżerowie. W dzisiejszym wpisie opisuję prostą technikę, która znacznie zwiększa prawdopodobieństwo terminowego i budżetowego dostarczania raz po raz.

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 Kanban Coachów uważa, że dla prawidłowego pomiaru Velocity itp. ważne jest “właściwe dopasowanie rozmiaru” zadań lub elementów pracy, w którym wszystkie elementy pracy mają mniej więcej ten sam rozmiar. Tylko wtedy Story Points (które są potrzebne do pomiaru Velocity) są przydatne do pomiaru Velocity, ponieważ wydają się być 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.

Więc zrób tak, aby stać się przewidywalnym: Monitoruj wskaźnik “nowo rozpoczętych zadań” w porównaniu ze wskaźnikiem “ukończonych zadań”. Te dwa powinny być w równowadze. Innymi słowy, “wskaźnik wejścia” i “wskaźnik wyjścia” zadań powinny być jak najbliżej siebie, idealnie nawet się pokrywać.

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. 

Jeśli zamiast tego upewnisz się, że dla każdego rozpoczętego zadania istnieje również ukończone zadanie, łatwiej będzie odblokować kilka skoncentrowanych zadań w Daily. Twoja wydajność będzie ogólnie bardziej przewidywalna - a zespół będzie bardziej zadowolony, ponieważ twój przełożony i twoi klienci będą bardziej zadowoleni.

Niektóre “pozytywne objawy” zdrowego zwinnego przepływu dostarczania

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

W teorii wiesz, co robić. Jak najlepiej zacząć w praktyce? Poprzez stworzenie świadomości i “gotowości 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 to nasz szablon retrospektywy dla “zwinnego dostarczania” (więcej na ten temat: 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:

Retrospektywa zwinnego dostarczania

Pozycje Health Check

Kiedy nasz sposób pracy doprowadził do nieoptymalnego przepływu pracy? (np. niejasne, niewłaściwe lub nieprzestrzegane wytyczne)

Jak możesz się domyślić, ostatni punkt kontroli stanu (sprawdzenie przyczyny) implikuje już potencjalny środek, coś, co możesz wypróbować przez jeden lub dwa zwinne sprinty, aby sprawdzić, czy może ci to pomóc: Ograniczenie liczby zadań ze statusem “W toku”.

Kładzenie fundamentów: Zawrzyj umowy dotyczące pracy zespołowej

Masz wrażenie, że twój zespół nie jest jeszcze gotowy na tego rodzaju refleksję? W takim przypadku powinieneś najpierw zastanowić się nad “dobrą pracą” w ogóle, a następnie ustalić kilka podstawowych zasad, tak zwanych umów roboczych lub Working Agreements. Poniższy szablon warsztatów może ci w tym pomóc. Możesz go przeprowadzić jako specjalną formę retrospektywy na początku projektu lub jako dodatkowy warsztat.

Najpierw powinieneś zorientować się, jak bardzo zgodny jest twój zespół w sposób dorozumiany - zobacz element kontroli stanu. Następnie powinieneś to praktycznie sprawdzić za pomocą kilku otwartych pytań. Każdy członek zespołu musi dokończyć zdanie (zobacz więcej pytań) z jak największą liczbą odpowiedzi, które przyjdą mu/jej do głowy:

Retrospektywa zobowiązań zespołu

Pozycje Health Check

Radzenie sobie z konfliktami: “Jeśli zauważę, że w naszym zespole pojawia się konflikt, to…”.

Po zebraniu odpowiedzi powinieneś oczywiście spróbować znaleźć wzorce i uzgodnić konkretne umowy dotyczące tego, jak chcesz współpracować w przyszłości - przynajmniej tymczasowo jako eksperyment.

Ciekawa, kreatywna alternatywa

Jeśli te metody retrospektywne wydają się wam zbyt “suche”, istnieje inna metoda retrospektywna, która koncentruje się na odzwierciedleniu jakości wyników waszego zespołu ( Fun 54 Retrospective Methods można znaleźć tutaj ): Retrospektywa “Trzy małe świnki”. Jest to prosta alternatywa dla rozpoczęcia refleksji i poprawy wydajności, oparta na bajce o trzech małych świnkach, które zbudowały domy z różnych materiałów.

Podsumowanie - Agile Delivery Flow

Bez względu na to, jak zaczniesz, najważniejsze jest, aby zacząć od początku. Zespoły, które aktywnie obserwują swój Agile Delivery Flow, są lepszymi zespołami.

Nawiasem mówiąc, wiele z pomysłów, które tutaj znajdziesz, jest również dobrze podsumowanych w podcaście “Agile Bites”, który gorąco polecam (Do podcastu: Agile Bites). 

Baw się dobrze rozwijając swój zespół!