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 ) swoich zespołów zajmujących się zwinnym tworzeniem oprogramowania, zgodzą się oni, że te rzeczy są ważne, ale… Gdy tylko klient zasygnalizuje nagłą potrzebę lub zbliża się termin oddania projektu, wszystkie te “miękkie” zmienne są zazwyczaj odkładane na bok. Menedżerowie są przede wszystkim zainteresowani przewidywalnym, działającym zwinnym przepływem dostarczania efektów 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 Scrum Masterzy i Agile Coache z kolei niedoceniają koncentracji na poprawie przepływu dostarczania – czyli w zasadzie tego, czego chcą menedżerowie. W dzisiejszym wpisie opisuję prostą technikę, która pozwala znacznie zwiększyć prawdopodobieństwo terminowego i mieszczącego się w budżecie dostarczania efektów, raz za razem.

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 https://open.spotify.com/show/7AroSpslWoQXpYKy9r73U3?si=bjjkkw1OT0Cqx0Cf_cy1kg&nd=1

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 do poprawnego pomiaru Velocity itp. konieczne jest “właściwe dopasowanie rozmiaru” zadań lub elementów pracy, tak aby wszystkie elementy pracy miały 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.

Zatem, aby stać się przewidywalnym, zrób tak: Monitoruj wskaźnik “nowo rozpoczętych zadań” w porównaniu ze wskaźnikiem “zakończonych zadań”. Te dwa powinny być w równowadze. Innymi słowy: wskaźnik “wejścia” i “wyjścia” zadań powinien być jak najbardziej zbliżony, idealnie nawet taki sam.

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 zadbasz o to, aby dla każdego rozpoczętego zadania było też zadanie zakończone, na Daily łatwiej będzie odblokować te kilka skoncentrowanych zadań. Wasza wydajność będzie ogólnie bardziej przewidywalna - a zespół będzie bardziej zadowolony, ponieważ wasz przełożony i wasi klienci będą bardziej zadowoleni.

Kilka “pozytywnych symptomów” zdrowego zwinnego przepływu dostarczania projektów

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ć. Jak więc 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ń.

W przypadku poniższych pytań jest 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 Checku (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ó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 Health Check. Następnie powinieneś to praktycznie sprawdzić za pomocą kilku otwartych pytań. Każdy członek zespołu musi dokończyć zdanie (zobacz 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 f3w, kt 3re tu znajdziesz, jest r 3wnież dobrze podsumowanych w podcaście “Agile Bites”, kt 3ry gor 3co polecam (Do podcastu:https://open.spotify.com/show/7AroSpslWoQXpYKy9r73U3?si=bjjkkw1OT0Cqx0Cf_cy1kg&nd=1 

Agile Bites