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 odkładane na bok. Menedżerom zależy przede wszystkim na przewidywalnie działającym zwinnym przepływie dostarczania (Agile Delivery Flow) ich zwinnego zespołu.

Jeśli kiedykolwiek zaglądałeś na naszego bloga Echometer ( do naszego bloga ), wiesz, że nasze treści koncentrują się raczej na poprawie “miękkich umiejętności” zespołów i organizacji. Są one często niedoceniane przez decydentów. Ale nie przez Scrum Masterów i Agile Coachi.

Moim zdaniem, to co Scrum Masterzy i Agile Coache z kolei niedoceniają, to koncentracja na poprawie przepływu dostarczania (Delivery Flow) - zasadniczo tego, czego chcą menedżerowie. W dzisiejszym wpisie opiszę prostą technikę, która znacznie zwiększy prawdopodobieństwo terminowego i budżetowego dostarczania produktów raz za razem.

1. Pierwszy krok w odniesieniu do waszego Agile Delivery Flow

Mówię o monitorowaniu Agile Delivery Flow waszych zadań (Tasks). Jeśli zrobisz tylko kilka rzeczy dobrze, będziesz w stanie dostarczać znacznie bardziej przewidywalne wyniki. Nawet twoje wykresy rozrzutu Cycle Time lub symulacja Monte Carlo do obliczania szacunków projektów mogą w końcu wskazywać na poprawne prognozy, zamiast całkowicie się mylić (więcej na ten temat: 9 Metryk Agile dla Decydentów ).

Pierwszy symptom, z którym należy walczyć: Są zadania, które zajmują tylko kilka dni od “Zaplanowane” do “Zakończone”, a potem są zadania, które trwają ponad miesiąc. Aby temu przeciwdziałać, powinieneś upewnić się, że zadanie zawsze zawiera najmniejszą możliwą wersję pożądanej funkcji. Bez zbędnych dodatków, które nie są potrzebne do głównego życzenia klienta. Zasadniczo MVT, Minimum Viable Task. To nie znaczy, że każde zadanie jest małe. Ale powinno pomóc wam osiągnąć stadium, w którym zadania trwają raczej kilka tygodni, a nie miesięcy.

2. 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 “right sizing” 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ą przydatne do pomiaru Velocity, ponieważ bardziej przypominają porównywalną jednostkę czasu. 

Ale to nieprawda: Zadania nie muszą mieć nawet podobnej wielkości. Nie powinieneś tego zakładać, ponieważ po prostu zbyt trudno jest kontrolować szacunki Story Point. Jedyne co możesz kontrolować to ile nowych zadań zaczynasz.

Więc zrób to, aby stać się przewidywalnym: Monitoruj wskaźnik “nowo rozpoczętych zadań” w porównaniu do wskaźnika “zakoń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: Typowe zachowanie w zespołach programistycznych polega na tym, że gdy tylko zadanie zostanie zablokowane, rozpoczyna się nowy element pracy. Prowadzi to do tego, że wiele zadań jest otwartych, ale niezakończonych, co sprawia, że odblokowanie ich wszystkich staje się o wiele bardziej skomplikowane. 

Jeśli zamiast tego upewnisz się, że dla każdego rozpoczętego zadania istnieje również zadanie zakończone, łatwiej będzie ci 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.

Kilka “pozytywnych symptomów” zdrowego zwinnego Agile Delivery Flow

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

• • Nie zaczynamy nowych zadań, gdy wiele spraw jest jeszcze w toku. 

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

• • Wiek zadań nigdy nie przekracza kilku tygodni.

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

Limity WIP (Work-in-Progress) również w tym pomagają, nawet jeśli często są niewystarczające. Gdy zespół nauczy się koncentrować na kończeniu zadań, zamiast tylko zaczynać nowe, będziecie lepsi niż większość zespołów.

Jeśli prawidłowo wykorzystuje się Agile Delivery Flow

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 zadania 2-3 dniowe ostatecznie zajmą miesiąc.

O ile lepiej by się pracowało Twojemu zespołowi, gdybyś wiedział, że zasadniczo wszystkie zobowiązania dotyczące dostaw są realizowane w ciągu kilku tygodni? Zakłada to oczywiście, że wdrażacie wszystkie wymienione powyżej elementy: ustalenie MVT, ścisły limit WIP i zobowiązanie do rozpoczynania nowych zadań dopiero po zakończeniu innego zadania.

Krok 3: Zacznij od ulepszania Agile Delivery Flow

Teoretycznie wiesz, co robić. Jak najlepiej zacząć w praktyce? Tworząc świadomość i “gotowość do zmian” w zespole. W najlepszym przypadku poprzez autorefleksję.

Musisz zapewnić przejrzystość tych liczb i regularnie je sprawdzać, aby zobaczyć, czy proporcja między rozpoczętymi a ukończonymi zadaniami jest zrównoważona. Może to być częścią waszej retrospektywy, aby zagłębić się nieco bardziej i zastanowić się, dlaczego liczby w ostatnim cyklu nie były zrównoważone. 

Polecam omówienie wspomnianych przeze mnie zachowań podczas retrospektywy za pomocą naszego narzędzia do retrospektyw agile Echometer (więcej na ten temat: 7 narzędzi do retrospektyw w porównaniu ). Możesz nawet uczynić z tego część waszych porozumień roboczych (lub Working Agreements) lub regularnych kontroli stanu (Health Checks), aby zwiększyć świadomość, regularnie zadając pytania.

Poniższe pytania pochodzą z naszego szablonu retrospektywy dla “agile Delivery” (więcej na ten temat: 22 zabawne szablony do zwinnych retrospektyw ). Zaczynamy od kilku stwierdzeń dotyczących kontroli stanu (Health Check) i pytamy zespół, czy się z nimi zgadza, czy nie. Następnie zadajemy kilka otwartych pytań:

Retrospektywa Agile Delivery

Elementy kontroli stanu (Health Check)

Kiedy nasz sposób pracy doprowadził do gorszego przepływu pracy? (np. niejasne, nieodpowiednie lub nieprzestrzegane wytyczne)

Jak możesz sobie wyobrazić, ostatni punkt kontroli stanu (sprawdzenie przyczyny) implikuje już potencjalne działanie, coś, co możesz wypróbować przez jeden lub dwa zwinne sprinty, aby sprawdzić, czy może ci pomóc: ograniczenie liczby zadań ze statusem “Work in Progress”.

Położenie fundamentów: ustalenie zasad współpracy zespołowej

Czy uważasz, że twój zespół nie jest jeszcze gotowy na tego typu refleksję? W takim przypadku powinieneś najpierw zastanowić się nad „dobrą pracą” w ogóle, a następnie ustalić pewne podstawowe zasady, tak zwane umowy robocze (Working Agreements). Pomocny może być następujący szablon warsztatu. Możesz go przeprowadzić jako szczególną formę retrospektywy na początku projektu lub jako dodatkowy warsztat.

Na początek powinieneś zorientować się, jak bardzo jednomyślne jest twoje zespół – patrz element Health Check. Następnie powinieneś to praktycznie sprawdzić, zadając kilka otwartych pytań. Każdy członek zespołu musi dokończyć zdanie (patrz dalsze pytania), podając jak najwięcej odpowiedzi, które przyjdą mu/jej do głowy:

Retrospektywa zobowiązań zespołu

Elementy Health Check

Radzenie sobie z konfliktami: „Kiedy zauważę, że w naszym zespole narasta konflikt, wtedy…”

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 retrospektywy wydają się zbyt „suche”, istnieje inna metoda retrospektywy, która koncentruje się na refleksji nad jakością wyników twojego zespołu ( Tutaj znajdziesz 54 zabawne metody retrospektywy ): Retrospektywa „Trzy małe świnki”. Jest to prosta alternatywa, aby rozpocząć refleksję i ulepszanie wyników waszej pracy, w oparciu o bajkę o trzech małych świnkach, które budowały domy z różnych materiałów.

Wniosek – Agile Delivery Flow

Niezależnie od tego, jak zaczniesz: najważniejsze to w ogóle zacząć. Zespoły, które aktywnie obserwują swój Agile Delivery Flow, są lepszymi zespołami.

Nawiasem mówiąc, wiele 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). 

Życzymy udanego rozwoju twojego zespołu!