Odcinek 66. Kryteria wyjścia, czyli gdy DoD to za dużo i za późno

Czy da się zapobiec popełnianiu błędów i potrzebie zawracania zadań w jakimś wieloetapowym procesie? Pewnie nie w 100%, ale na pewno można zredukować takie przypadki stosując w całym przebiegu procesu jasne, zrozumiałe i przestrzegane kryteria wyjścia, czyli tzw. Exit Criteria. Co to takiego? Sprawdź!

Kryteria wyjścia – klucz do jasnych zasad w Kanbanie

W bieżącym odcinku podcastu poruszamy temat niezwykle istotny dla każdego, kto dąży do usprawnienia swoich procesów pracy. Mowa o kryteriach wyjścia, znanych również po angielsku jako „exit criteria”. Wpisują się w czwartą praktykę Metody Kanban, czyli czynienie zasad (polityk) naszej pracy jasnymi, jawnymi i zrozumiałymi.

A tego już nie było?

Zanim zagłębimy się w dzisiejszy temat, warto wspomnieć, że w listopadzie 2019 roku po raz pierwszy poruszałem kwestię jasności zasad pracy. Stąd jeśli będzie Wam dziś mało, to zapraszam do odcinka sprzed kilku lat Odcinek 6. – Uczyń zasady jasnymi (make policies explicit). Poniższy tekst to rozwinięcie jednego tylko tematu spośród wielu zawartych w odcinku 6.

Czym są kryteria wyjścia?

Zacznijmy od prostej historii, która może wielu z Was zainspirowała do przemyśleń zarówno w pracy zawodowej, jak i osobistej. Opowieść ta dotyczy odbioru samochodu z serwisu w stanie dalekim od oczekiwanego, co ujawniło brak odpowiednich kryteriów wyjścia dla wykonanej usługi. Historia ta jest dowodem na to, że odpowiednio zdefiniowane i przestrzegane kryteria wyjścia są kluczowe dla zachowania jakości i zadowolenia klienta.

Czy to przyda się w moim procesie lub zespole?

Kryteria wyjścia mają szerokie zastosowanie nie tylko w obszarze zarządzania projektami IT, ale właściwie w każdej dziedzinie pracy intelektualnej, od marketingu, przez design, po sprzedaż. Praktyka ta pozwala na jasne określenie, co musi zostać wykonane, aby praca nad danym elementem mogła zostać uznana za zakończoną na określonym etapie, a tym samym zadanie mogło zostać przekazane dalej (np. do kolumny oczekującej na kolejną aktywność). O czym mowa?

Co znaczy, że pisanie kodu zostało zakończone w taki sposób, że ktoś może go przejrzeć?
Co musi zawierać oferta sprzedażowa, nim wyślemy ją do klienta?
Kto musi dokonać przeglądu czy akceptacji, nim zdecydujemy się przekazać jakąś treść do integracji z resztą treści?

A w Scrumie tego nie mamy? Tak i…

Ciekawostką jest, że w Scrumie istnieje podobne narzędzie – definicja ukończenia (Definition of Done, DoD), które doskonale wpisuje się w koncepcję, nazwijmy to, „ostatecznych” kryteriów wyjścia.

Kanban sugeruje, że kryteria rozpisane na poszczególne kroki procesu zwiększają szanse, że określony etap zostanie zakończony zgodnie z prawidłami profesjonalnej pracy, spełnione będą warunki jakościowe, regulacyjne, bezpieczeństwa itp., a tym samym powoduje to, że zmniejszymy szanse strat powodowanych tym, że praca będzie musiała wrócić, bo np. dany element pracy nie przejdzie testów czy nie spełni oczekiwań klienta. Tym samym możemy mocno usprawnić przepływ pracy i rzadziej stawać przed koniecznością „cofania” zadań czy wstydzenia się za efekty swojej pracy.

Jaka jest więc różnica względem DoD? Może nie ma sensu się jej doszukiwać, bo Scrumowe DoD to zwykle suma „exit criteria” wszystkich poprzednich etapów, może z jakimś dodatkowym warunkiem. Nie twierdzę, że tak jest wszędzie, ale widzę czasem zespoły, które spoglądają na swoje DoD dopiero przed ukończeniem, przekazaniem czy wdrożeniem pracy i wtedy sprawdzane jest wiele „punktów na raz”. Jak napisałem w tytule, to często za dużo (na raz) oraz za późno. Jeśli sprawdzamy wszystkie te rzeczy na końcu, to… możemy dowiedzieć się za późno, że czegoś nie dopatrzyliśmy.

Jak zacząć definiowanie kryteriów wyjścia?

Kluczem do lekkiego i nieodstraszającego biurokratycznością ustalania kryteriów wyjścia jest podejście ewolucyjne, charakterystyczne dla Metody Kanban. Zacznij więc od obecnego stanu rzeczy, angażując zespół w proces definicji tych kryteriów, a więc spisanie tego, co robimy na kolejnych etapach obecnie. Polecam „pobawić się” w zapisanie obecnych zasad przez wszystkie zaangażowane osoby, nie tylko tych którzy pracują „w danej kolumnie”. To często prowadzi do ciekawych dyskusji.

Spisanie zasad nie musi oznaczać generowanie długaśnych dokumentów. Można zrobić to np. przy wykorzystaniu narzędzi takich jak Mural czy Miro, efektem czego może być graficzna wizualizacja pokazująca, co i gdzie powinno się zadziać.

Raz na zawsze czy „doskonalenie przez współpracę”?

Pamiętajmy, że ustalone kryteria wyjścia nie są niezmienne. W duchu ciągłego doskonalenia, ewolucji czy inspekcji i adaptacji, powinny one być regularnie przeglądane i dostosowywane do zmieniającego się kontekstu pracy, technologii, narzędzi, a także oczekiwań klientów i współpracowników.