Jednym z najczęstszych nieporozumień związanych z Kanbanem jest opinia, że brak sprintów pociąga za sobą również brak planowania i nie oferuje żadnego odpowiednika. Rozprawmy się z tym mitem i omówmy proces „Uzupełniania i Zobowiązania” (replenishment & commitment).

Zanim o przebiegu samego spotkania to przyjrzyjmy się temu, co na i poza tablicą Kanban. Nawet jeśli tablica zespołu zaczyna się od lewej kolumną „Do zrobienia” to rzadko jest to pierwszy stan, w którym powstają zadania. Liczba i kolejność tych zadań nie powinna być dziełem przypadku ani efektem pracy biurowego gnoma, który w nocy przykleja post-ity.

Począwszy od całych produktów, przez poszczególne ficzery, aż po historie użytkownika, eksperymenty i pojedyncze zadania rodzą się one zwykle najpierw gdzieś „na lewo”. Zajmuje się nimi „biznes”. Ten pozyskuje lub tworzy pomysły, pozyskuje wiedzę na ich temat, określa wartość, definiuje jak ją zmierzyć i co ogłosić sukcesem. W systemie Kanban zadania dojrzewają przechodząc od określonych zgubnie idei po bardziej precyzyjne elementy pracy. Jeśli przypomina Ci to proces wędrówki elementów backlogu produktu i ich refinementu to jesteś na dobrej ścieżce.

Jest na tablicy jeszcze jeden ważny obszar – granica oddzielająca kolumny „Do Zrobienia” i pierwszą z kolumn sygnalizującą rozpoczętą pracę np. „W toku”. Jest ona nazywana punktem zobowiązania (a point of commitment). Akt przeciągnięcia jakiegokolwiek zadania przez tę granicę oznacza, że:

• Zadanie jest gotowe do pracy. Scrumowiec powie, że wypełnia definicję gotowości. Kanbanista powie, że spełnia warunki określone w polityce pull dla tego stanu.
• Zespół zobowiązuje się je ukończyć i dołoży w tym celu wszelkich starań.

Poważna prawda, hm? Wspomniana granica oddziela dwa mniejsze systemy Kanban. Na lewo od niej mamy tzn. kanban odkrywający (discovery kanban), na prawo – kanban dostarczający (delivery kanban). Idąc tym tokiem myślenia wszystko na lewo jest opcją, zaś co do rzeczy na prawo to powinniśmy skupić się na ich dostarczeniu i unikać sytuacji ich usuwania z systemu, bo oznaczałoby to stratę i burzyło przepływ.

OK, ale gdzie to planowanie? W celu zapewnienia odpowiedniej liczby odpowiednich zadań w kolumnie „Do Zrobienia” zespół powinien odbywać spotkania nazywane Uzupełnianie i Zobowiązanie (Replenishment and Commitment), w czasie których wybierane są kolejne do zrealizowania elementy pracy o największej wartości. Jest to również czas dyskusji o ich zrozumieniu, gotowości, dialogu na temat tego, że zespół zobowiązuje się je dostarczyć, buduje plan jego realizacji, gdy tylko będzie dysponował „mocą przerobową”.

Jak to mocą przerobową? Pamiętajmy, że zespół pracujący zgodnie z prawidłami Kanbanu szanuje swoje limity pracy w toku. Zobowiązanie się do dostarczenia zadania nie jest równoznaczne z jego natychmiastowym „wepchnięciem” do kanbanu dostarczającego.

Świetnie… A jak zdefiniować zadanie o największej wartości?

W tym wpisie nie jestem w stanie i nie chcę udzielać wyczerpującej odpowiedzi na to pytanie. Mogę powiedzieć, że w świecie Kanbanu mówimy często o oczekiwanej wartości, koszcie opóźnienia, profilu ryzyka, czy też o zadaniach z określoną klasą usługi (SLA). W praktyce mogą być to nowe funkcje, zadania z zakresu deficytu technicznego, naprawa błędów, eksperymenty. Wszystko to, co znasz ze zwinnej codzienności tyle tylko, że inne kryteria ustawiania ich w kolejce mogą, podkreślam mogą, być brane pod uwagę.

A co jeśli odkryjemy, że kolejność zadań nie jest już aktualna? Właścicielem kolejki, podobnie jak backlogu produktu jest „biznes”. Tak długo, jak elementy są jedynie opcjami ich kolejność może zostać zmieniona, a zadanie usunięte, cofnięte w skutek nowych danych, czy zmiany sytuacji rynkowej. Nie bez głosu jest zespół, który może poinformować o nowych informacjach, odkrytych zależnościach. Może zasugerować rozbicie zadania, swoją kolejność w oparciu o wybrane rozwiązanie. Na zobowiązanie mogą też wpłynąć czynniki losowe – praca nad zadaniem takim jak naprawa błędu „na produkcji” itp…

Najlepiej, że w spotkaniu takim uczestniczyli:

• ktoś, kto pełni rolę tzw. zamawiającego usługę (Product Owner, pracownik działu obsługi klienta, analityk);
• zespół naturalnie;
• jeśli istnieje osoba odpowiedzialna za jego wspomaganie (Scrum Master, Project Manager, może lider techniczny). Pamiętajmy, że Kanban nie nadaje nowych tytułów a wykorzystuje istniejące role.

Podobnie jak scrumowe planowanie sprintu tak i uzupełnianie i zobowiązanie powinno być miejscem i czasem dyskusji, rozwiązywania problemów, grupowej decyzji co do czego możemy podjąć zobowiązanie. W przeciwnym razie ciężko będzie utrzymać system ciągniony, poczucie odpowiedzialności i zobowiązania ze strony zespołu.

A jak często odbywa się takie spotkanie? Tak często jak musi. Na przykład:

• Jeśli zadania mają krótkie czasy realizacji (lead times), a zmiany środowiska powodujące zmiany w ich kolejce prawdopodobne i częste to może odbywać się codziennie;
• Możemy umówić się, że kiedy liczba zadań w kolumnie „Do zrobienia” spada poniżej pewnego ustalonego minimum – groźba głodu zadań – to organizujemy kolejne spotkanie;
• jeśli ze względu na długi czas realizacji sensowna jest stała, ale dłuższa kadencja, np. co tydzień czy dwa to też będzie ok (przynajmniej przez jakiś czas).

OK, a czy w czasie spotkania poświęconemu uzupełnianiu i zobowiązaniu estymujemy?
Jak na metodę leanową przystało Kanban sugeruje, żeby zamiast estymowania (tylko proszę bez wojen o story pointy!) skłonić się w stronę prognozowania opartego na pomiarze własnych czasów realizacji (lead time) i budować zobowiązanie w oparciu o nie. Na podstawie takich danych możemy oferować klientowi prognozy, unikać przeładowania zespołu, zapewnić czas potrzebny na ulepszenia (slack time, itd.)

To jak to jest z tym planowaniem?

TL, DR: Odpowiednikiem planowania sprintu jest w Kanbanie spotkanie poświęcone Uzupełnianiu i Zobowiązaniu, kiedy to aktualizowana jest kolejka elementów pracy gotowych do zaciągnięcia przez zespół. Decyzje tę podejmujemy na podstawie wartości (biznesowej) i upewniamy się, że zadania są gotowe do pracy. Zamiast estymować, prognozujemy na podstawie własnych danych a zadanie zaciągamy do pracy, gdy zespół dysponuje na to mocą przerobową.