Agile Delivery Flow: Zawsze dostarczaj na czas w 3 krokach

Zapytaj wiÄ™kszość menedĹźerĂłw o “bezpieczeĹ„stwo psychologiczne” lub “wizjÄ™” (wiÄ™cej na ten temat: Bezpieczeństwo psychologiczne ) ich zwinnych zespoĹ‚Ăłw programistycznych, 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 odsuwane 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Ä™ bardziej 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 poprawnego pomiaru Velocity itp. waĹźne jest “wĹ‚aĹ›ciwe dopasowanie rozmiaru” zadaĹ„ lub elementĂłw pracy, gdzie wszystkie elementy pracy majÄ… mniej wiÄ™cej ten sam rozmiar. Tylko wtedy Story Points (potrzebne do pomiaru Velocity) sÄ… uĹźyteczne do pomiaru Velocity, poniewaĹź wydajÄ… siÄ™ bardziej jak porĂłwnywalna jednostka 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ş zadanie zakończone, na Daily uda się lepiej odblokować kilka skoncentrowanych zadań. 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.

Kilka “pozytywnych symptomĂłw” zdrowego zwinnego Agile Delivery Flow

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? 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 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 Health Check (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 “Work in Progress”.

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ĂłlnoĹ›ci, 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 szczegĂłlnÄ… formÄ™ retrospektywy na poczÄ…tku projektu lub jako dodatkowy warsztat.

Najpierw powinieneś zorientować się, jak bardzo twój zespół czuje się implicite zgodny - zobacz element Health Check. Następnie powinieneś to praktycznie sprawdzić za pomocą kilku otwartych pytań. Kaşdy członek zespół musi zakończyć zdanie (patrz dalsze pytania) 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 ustalenia dotyczące tego, jak chcesz współpracować w przyszłości - przynajmniej tymczasowo jako eksperyment.

Ciekawa, kreatywna alternatywa

Jeśli te metody retrospektyw 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ół!