Jak sprawić żeby programiści pilnowali statusów zadań?
Dziś odcinek o wdrożeniu tablicy Kanban do Twojego projektu. Jeżeli chcesz zwiększyć przewidywalność zespołu i odzyskać kontrolę nad projektem polecam Ci przesłuchać ten odcinek.
Z odcinka dowiesz się:
🎯Jak sprawić żeby programiści aktualizowali statusy zadań?
🎯 Jak przekonać ludzi do pracy „w duchu” Kanbana?
🎯 Jak wybrać dobry moment na wdrożenie Kanbana?
🎯 Jak sprawić by reszta firmy współpracowała z Kanbanem?
🎯 Jakie Twój Kanban powinien mieć kolumny?
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Subskrybuj podcast na:
Transkrypt podcastu – jeśli wolisz tekst
Czy w Twoich projektach jest chaos? Pracujecie na wielu zadaniach równolegle? Chcecie planować pracę, ale nie do końca wiecie jak? Ciągle musisz pytać programistów o status zadań bo jest to niejasne? Czujesz niemoc bo nie masz kontroli nad projektem? Nie wiesz ile pracy jest w toku, a ile zaplanowane?
Jeżeli tak to rozwiązaniem Twoich problemów może być tablica Kanban. Tylko nie zrozum mnie źle – samo wdrożenie tablicy jest proste. Jest to po prostu wyklikanie interfejsu np. w Jirze. Najtrudniejszym zadaniem jest przekonanie ludzi, żeby korzystali z tej tablicy.
Kiedy warto wdrożyć Kanbana?
Na początku porozmawiamy o tym, kiedy warto wdrożyć kanbana. Według mnie pierwszym objawem, kiedy powinniśmy się nad tym zastanowić, to gdy w naszych projektach lub naszej firmie pojawia się chaos – kiedy pracujemy na wielu zadaniach równolegle i tak naprawdę nikt nie wie, co jest robione, kto ma co zrobić i jaki jest kolejny krok danego zadania.
Przez to popełniamy zazwyczaj dużo błędów. Robimy zbyt wiele rzeczy na raz i nie jesteśmy w stanie zrobić ich dobrze. Warto też wdrożyć kanbana jeśli chcesz być bardziej przewidywalny.
Tablica Kanban umożliwia pracę w tzw. cyklach. Jest to bardziej przewidywalne i trochę podobne do sprintów w Scrumie, więc jeżeli chcesz zaplanować sobie jakiś harmonogram wdrożeń w Twoim projekcie to właśnie kanban jest do tego przydatnym narzędziem.
Po prostu poznacie jaki jest wasz przerób. (O tym czym jest przerób jeszcze powiem za chwilę). Warto też wdrożyć kanbana jeśli chcecie planować, ale nie jest istotne w jakich konkretnych dniach będą wykonywane zadania.
Zmorą harmonogramowania jest to, że niektóre firmy wymagają planowania wykonania poszczególnych zadań na konkretne dni np. jeżeli projekt ma 200 zadań projektowych to musimy harmonogramować, kiedy wykonamy zadanie pierwsze – powiedzmy, że będzie to wtorek, zadanie drugie – powiedzmy w czwartek itd. Tak naprawdę z punktu widzenia projektu, nie ma to większego znaczenia. Kluczowe jest żeby wykonać wszystkie zadania projektowe przed terminem. I właśnie to jest bardzo duża zmiana, której musi ulec Twoja organizacja, żeby kanban był wdrożony.
Musisz zastanowić się czy w przypadku Twoich projektów takie planowanie jest możliwe. Będzie to oznaczało, że bardziej skupicie się na osiągnięciu celu, na wykonaniu projektu na czas. Rozmawiając ze swoimi czytelnikami, zauważam problem emocjonalny, właściwie powód emocjonalny żeby wdrożyć Kanbana. Dużą zmorą jest to, że programiści nie pilnują statusów zadań. Kierownik projektu zakłada zadanie, przypisuje na programistę i ono gdzieś – w gąszczu pracy – ginie. Jest ustawiony jakiś status zadania, ale my tak na prawdę nie ufamy i wolimy się upewnić dzwoniąc i pytając, czy to zadanie jest faktycznie zrobione lub faktycznie nie zrobione.
Mnie niezwykle frustruje, kiedy zadania nie są aktualne w projekcie. Kanban jest dobrym narzędziem, żeby w sposób nieagresywny wdrożyć pilnowanie zadań przez programistów. Polecam Ci wdrożyć kanbana również, jeśli czujesz brak kontroli nad projektem, kiedy nie wiesz ile pracy jest w toku, ile jest zaplanowane do wykonania, ile jest już zrobione, ile rzeczy jest w testach itd. Jeżeli nie wiesz tego, to nie możesz planować konkretnych projektów. I w zależności jak działa Twoja organizacja, czasami jest to przydatne, a czasami po prostu nie ma takiej potrzeby.
Czym jest Kanban?
Teraz może w krótkich żołnierskich słowach powiem czym jest w ogóle ten kanban. Żebyś graficznie mógł to sobie wyobrazić – możesz porównać go do excela, gdzie w kolumnach są statusy zadań w Twojej organizacji. Poprzez statusy rozumiem, że np.
- zadanie jest planowane do wykonania,
- jest wykonywane,
- jest wykonane,
- jest w testach,
- przeszło testy (lub nie przeszło),
- jest np. zamknięte.
Co firma to obyczaj, każdy ma zapewne inne statusy zadań. Zatem w kolumnach będą te statusy, a w wierszach tzw. swimlanes. Jeden swimlane czy jeden wiersz może odpowiadać jednemu programiście. Najczęstszy podział z jakim się spotykam dotyczy zasobów, czyli w kolumnach mamy statusy zadań, a w wierszach (w przykładzie IT) programistów. I w tych komórkach wydzielonych przez kolumny i wiersze znajdują się zadania.
Jeżeli jakieś zadanie znajduje się w wierszu z danym programistą to wiadomo, że jest do niego przypisane, że on powinien cos wykonać. Natomiast to w jakiej kolumnie się znajduje, określa stan tego zadania, czyli w jakim jest cyklu projektowym (planowane, wykonane czy akurat robione). I tak generalnie wygląda kanban. Jest dużo softwearów, które umożliwiają zrobienie takiej tablicy. Ja korzystam z Jiry, widziałem też pluginy do Redmine. Jest również dużo zewnętrznych narzędzi, których możesz użyć, które są dedykowane do pracy w tablicy kanbanowej.
Wiele osób myli kanban z agile boardem. Pewnie wiesz jak się pracuje w scrumie – są sprinty i często wykorzystuje się do planowania tablicę. Jest to agile board i mimo, że wizualnie wygląda bardzo podobnie, to jednak jest czymś innym. Kanban jest bardziej koncepcją, jest filozofią podejścia do pracy. W kanbanie chodzi głównie, żeby mieć kontrolę nad pracą w toku, nad pracą zaplanowaną i pracą wykonaną. Chodzi też o definicję, między innymi, przerobu w firmie.
Tak jak na początku zapowiedziałem – będziemy rozmawiać o wdrożeniu kanbana. Według mnie samo wyklikanie kanbana w Jirze, Redmine, czy znalezienie narzędzia to jest ok. 10% sukcesu. Skonfigurować narzędzie potrafi każdy, ale największą trudność sprawia nastawienie ludzi i używanie kanbana w praktyce.
Wdrożenie na pewno nie kończy się po tym jak wyklikamy opcje w Jirze i mówimy: „No zespole to teraz pracujcie”. To jest naprawdę bardzo ciężka praca żeby ludzi do tego przekonać. Może nawet nie tyle przekonać (bo ludzie generalnie lubią pracować mądrze), ale do wyrobienia nawyku, żeby się mentalnie nastawili do faktycznego używania kanbana i pracowania w tym duchu.
Jak wybrać moment na wdrożenie Kanbana? – etap 0
Też przeszedłem przez te problemy i dlatego poruszam taki temat. Chciałbym się z Tobą podzielić swoimi wnioskami i ułatwić Ci wdrożenie kanbana w Twojej organizacji, jeżeli robisz to po raz pierwszy. Tutaj kluczowym momentem – etapem 0 – będzie wybranie odpowiedniej chwili, kiedy w ogóle kanbana wdrożyć.
Wybranie właściwego momentu jest naprawdę kluczowe z Twojego punktu widzenia. Według mnie, niestety najlepszym momentem jest sytuacja, gdy macie konsekwencje wywołane chaosem. Ponieważ wtedy ludzie chcą zmian. Jeżeli coś się stało źle, to każdy niestety chce wyciągać konsekwencje. Warto zastanowić się, co możemy zrobić żeby do tego w przyszłości nie dopuścić.
Dobrym pomysłem jest, żeby właśnie wtedy zaproponować tablicę kanbanową. Ważna rzecz: zakładam, że istniejesz w takim środowisku projektowym, kiedy nad Tobą jest jakiś szef czy przełożony – ktokolwiek, kto decyduje i musi zatwierdzić Twoją decyzję. Jeżeli jesteś sam sobie szefem to nie masz problemu i po prostu wdrażasz kanbana kiedy chcesz.
Natomiast musisz też pamiętać, że często kierownicy projektu są wynajmowani na jakąś część godzin aby prowadzić dany projekt. Wtedy tak naprawdę mimo, że masz własną firmę i prowadzisz ją to Twoim szefem jest klient i to jego musisz przekonać do pracy na kanbanie. W tej sytuacji wybranie odpowiedniego momentu będzie na pewno kluczowe. Niestety po porażce jest dużo łatwiej przyjąć tę zmianę. Nie życzę Ci oczywiście fakapów, ale jeżeli się zdarzą to możesz je przekuć w coś korzystnego.
Warto sobie przygotować najpierw jakieś demo ze skonfigurowanym kanbanem, czyli już wcześniej wszystko ustawić, znaleźć narzędzie, zrobić przykładowe zadania i przykładowe kolumny. I w sytuacji, kiedy zdarzy się ten fakap, zrobić prezentację kanbana spontanicznie. Sugerowałbym Ci, żebyś nie robił w ten sposób, że zwołujesz oficjalne zebranie tylko po to, aby przedstawić zmiany i swój nowy pomysł. Wtedy ludzie, którzy przychodzą na spotkanie zawsze patrzą bardziej krytycznie i oczekują super pomysłów (jeżeli już angażujesz ich czasowo). Odpowiedni wybór momentu sprawi, że jest znacznie większa szansa na powodzenie.
Tutaj musisz oczywiście mówić językiem korzyści: co niesie ze sobą kanban, dlaczego jest warty wdrożenia. Warto powiedzieć też o różnych ograniczeniach, żeby później po prostu nie było zaskoczenia. Kluczowe będzie wybranie momentu i odpowiednie przedstawienie swojemu przełożonemu, czym jest kanban i dlaczego warto go wdrożyć. Jeszcze raz – jeżeli sam jesteś sobie szefem i realizujesz jakiś projekt in-house to oczywiście wdrażasz kiedy chcesz.
Konfiguracja Kanban pod Twoje potrzeby
Jeśli masz już zielone światło, żeby kanbana wdrażać w swoich projektach, to takim pierwszym etapem może być już faktyczna konfiguracja tablicy pod Twój projekt. Narzędzia są tak naprawdę bez znaczenia. Kanban jest dość prosty w konfiguracji, ma bardzo małe wymogi, żeby być skonfigurowanym gdziekolwiek – użyj Jiry, Redmine – tego, co Twój zespół po prostu zna. Zastanów się przede wszystkim, jakie statusy zadań musisz ustawić, aby to było wygodne dla Twojego zespołu. Statusy zadań czyli kolumny. Ale nie możesz rozumieć tego tak bardzo dokładnie, że jeden status to jedna kolumna. Jedna kolumna może zawierać dwa statusy. Takie możliwości daje np. Jira.
Przedstawię Ci teraz przykładowe kolumny, jakie możesz zrobić w swoim kanbanie. U mnie się one dobrze sprawdzały do prowadzenia projektów webowych. Wyglądały następująco:
Pierwsza kolumna z lewej strony to kolumna „to do„. Była ona podzielona na dwa statusy, na górze były to zadania, które są wybrane do realizacji (status selected for development). Na dole – kolumny z backloga, które są po prostu przypisane. Podaję ten przykład z backlogiem po to, żeby dodatkowo pokazać Ci, jaka jest różnica pomiędzy kolumną a statusem. Kolumna jest to bardziej procesowa organizacja statusów i dlatego wiele statusów może przynależeć do jednej kolumny. Z lewej strony jest więc „to do”, układane według priorytetów. Na górze u każdego są te zadania, które aktualnie powinien robić, a na dole są mniej ważne. Programista nie zastanawia się jakie są priorytety zadań, po prostu bierze pierwsze z półki i je realizuje. Praca jest wtedy dużo łatwiejsza.
Kolejna kolumna to feedback z testów. Może to być dla Ciebie zaskakujące, ale jeżeli zadanie wróci z testów to jest ono znów do zrobienia dla programisty. Osobiście wolę to rozbijać na osobną kolumnę, łatwiej wtedy śledzić sytuację bo rożnie nadaje się priorytety zadaniom. Czasami ważniejsze jest dokonanie poprawek z testów, a czasami trzeba realizować nowe funkcjonalności. Zależy po prostu jak terminy się układają.
W każdym razie od lewej strony zaczynam z tymi zadaniami, które są do zrobienia tak ogólnie i dzielę je na dwie – często na to do i na feedback z testów.
Trzecia kolumna od lewej to jest tzw. in progress (work in progress). Tutaj ważne jest pilnowanie, aby w tej kolumnie znalazło się tylko jedno zadanie u jednej osoby. Na początku zauważysz, że ludzie mają tendencję do robienia w in progress kilku zadań (bo są proste i zrobię je od razu).
Jeśli masz takie objawy w projekcie to oznacza, że źle dzielisz zadania. Czasem też ludzie potrafią tak robić po prostu z wygody. Ten problem jeszcze będę omawiał później, ale musisz zapamiętać żeby traktować to jako prawo, że w kolumnie in progress może być tylko jedno zadanie. Niektórzy to traktują jako guideline, czyli dobrze jakby tak było, ale ja wychodzę z założenia, że korzystniej to traktować jako prawo. Kanban w Jirze ma możliwość ustawienia ilości zadań w kolumnie in progress. Oczywiście da się przeciągnąć więcej, jeżeli ktoś by chciał złamać to nasze prawo projektowe, ale wtedy taka kolumna będzie podświetlona na czerwono.
Po kolumnie in progress, gdy developer wykonał swoje zadanie, może je przeciągnąć na status, który się nazywa resolved (czyli zadanie jest wykonane ale jest na repozytorium, na komputerze u programisty i nikt tego nie może zobaczyć). Później na podstawie ilości zadań w resolved decydujemy, które zadania powinny być przekazane do testów.
Kolejnym statusem – z prawej strony od resolved – będzie gotowe do testów (ready for test). Tam znajdują się zadania, które są już wdrożone. Zazwyczaj przepisujemy je w tym momencie na testera, żeby wiedział w ogóle co ma testować.
Ze statusu gotowe do testów są dwie możliwe ścieżki: pierwsza to kolejna kolumna z prawej strony czyli test verified (testy są zweryfikowane, funkcjonalność jest wolna od błędów, jest gotowa do wdrożenia) lub zadanie może zawierać błąd i wtedy trafia w drugą kolumnę z lewej strony (o której mówiłem wcześniej), czyli feedback z testów (wtedy programista wie, że coś jest jeszcze do zrobienia z tym zadaniem).
Jeżeli zadanie przeszło testy poprawnie i jest w kolumnie test verified, to kolejnym statusem zadania może być np. gotowe do testów produkcyjnych. Z test verified wybieramy zadania, które musimy wdrożyć na produkcję i po wdrożeniu produkcyjnym wymagają one jeszcze drobnego przeklikania czy na pewno wszystko działa poprawnie. Z kolumny gotowe do testów produkcyjnych też są dwie możliwe ścieżki. Może wrócić do feedback test, żeby znów coś programista poprawił (wtedy z większym priorytetem) lub np. zweryfikowane testy produkcyjne – co świadczy o tym, że już wszystko zostało wykonane.
Kolejna kolumna to taka wisienka na torcie, którą jest done. W Jirze jest możliwość konfiguracji, żeby te zadania znikały po pewnym czasie. Gdybyś sobie wyobraził taką półroczną prace na kanbanie, to miałbyś tam mnóstwo zadań i wszystko by było mało czytelne. Dlatego ja jestem zwolennikiem, żeby te zadania były tam tydzień, ewentualnie dwa, żeby można było też zobaczyć takie małe sukcesy projektowe. Ale tutaj też zaznaczę, że lepiej zawsze patrzeć w przyszłość i skupiać się na tym, jakie jeszcze zadania zostały.
Tak wyglądają statusy zadań z punktu widzenia programisty. Musisz pamiętać, że każda rola projektowa może mieć inne statusy i kolumny. Np. te statusy zadań, które przytoczyłem mogą być dedykowane programiście, testerzy będą mieli inne kolumny. Dla testera kolumną „to do” nie będzie wcale „feedback test” ani „to do” do wykonania przez programistę, tylko „gotowy do testów”.
Z punktu widzenia testera to jest do zrobienia więc możesz nazwać tę kolumnę „to do” w kanbanie testera i ona będzie zawierała status ready for test lub gotowy do testów produkcyjnych. Musisz pomyśleć nad tym, żeby to było wygodne. Jeżeli korzystasz z jakiegoś systemu to jest o tyle fajne, że zadanie na podstawie odpowiedniego statusu który ma, będzie się wyświetlało w każdym kanbanie poprawnie (bo możemy sobie definiować jakie kolumny zawierają jakie statusy).
Jeszcze raz chcę podkreślić, że status a kolumna, na pierwszy rzut oka może się wydawać tym samym ale tak naprawdę są to troszeczkę inne rzeczy.
Najczęstsze błędy w konfiguracji Kanbana
Teraz chciałbym Ci jeszcze powiedzieć o najczęstszych błędach w konfiguracji. Często kierownicy projektów mają tendencję do robienia zbyt detalicznych kolumn lub zbyt detalicznych statusów zadań. Czyli jest nieodkryty prawdziwy cykl organizacji.
Zazwyczaj jeśli organizacja działa na 6 statusach zadań to kierownicy projektów starają się to sobie bardziej utrudnić i dodają tych statusów więcej i one są po prostu niewykorzystywane lub zrobione nielogicznie i zespół nie wie, kiedy użyć danego statusu. Często też spotyka się błąd, kiedy jest status zadania, ale to zadanie ma tak krótki cykl życia, że nie ma sensu go ustawiać bo więcej jest przenoszenia niż faktycznych korzyści ze statusu.
W naszym przypadku często takim statusem było in test. Z tego względu, że sam test danej funkcjonalności trwał bardzo krótko. Przetestowanie jednej funkcjonalności zajmowało ok. 15 minut wiec w tej kolumnie praktycznie nic nie było. Z mojej perspektywy więc nie miało sensu aby ta kolumna była. To się sprawdziło lepiej. Ty też zwróć uwagę czy nie masz takich kolumn, które są zbyt krótkie lub po prostu niewygodne do używania.
Możesz się zastanawiać godzinami jakie kolumny zrobić, ale tak naprawdę życie samo to zweryfikuje. Sugeruję Ci żebyś pomyślał maksymalnie przez 20 minut, ustawił kolumny i uruchomił swojego kanbana. Tak naprawdę to jest ciągłe udoskonalanie i uwierz mi, że od razu dowiesz się, które kolumny były błędem, a które były trafione. Nie dowiesz się tego bez wdrożenia. Zacznij działać z tymi kolumnami, które wydają Ci się słuszne i po prostu zbieraj feedback od zespołu, patrz jak praca w tych kolumnach się rozkłada i dostosowywuj je z każdym cyklem. Z każdym dniem i tygodniem udoskonalaj swojego kanbana.
Jak zakomunikować zespołowi wdrożenie Kanabna?
Powiedzieliśmy sobie o etapie pierwszym – jak skonfigurować kanbana. Teraz powiem Ci o etapie drugim. Przed Tobą wdrożenie kanbana do zespołu. Jak to zrobić? Musisz go sprzedać zespołowi.
Polecam Ci zwołać jakieś zebranie, zrobić telekonferencję lub cokolwiek takiego, żeby mieć wszystkich w jednym miejscu. Powinieneś zacząć od tego, żeby powiedzieć o korzyściach korzystania z kanbana okiem tych osób, które będą go używały czyli – w Twoim przypadku – prawdopodobnie będą to programiści.
Możesz poruszyć takie kwestie, jak łatwiejsze planowanie (ciężko planować w kanbanie zadania na kolejne dni, oczywiście jeśli się bardzo postaracie to jest to możliwe, ale generalnie zasada kanbana jest taka, żeby zadania z kolumny „to do” i zadania z backlogu schodziły jak najszybciej). Możesz też przedstawić taką korzyść ogólną, że będzie większy porządek w zadaniach dla programisty, czyli po prostu będzie wiedział co ma zrobić.
Później z tych korzyści obiektywnych możesz przejść na korzyści emocjonalne np. że będzie uporządkowana lista, nie będzie frustracji, szukania zadań bo bierzemy pierwsze zadanie z góry. Zasada jest bardzo prosta i szybko chwyta. Ty też wtedy wiesz co się dzieje dalej z Twoim zadaniem i to może być taka emocjonalna korzyść dla programisty bo często ktoś odpowiada za jakąś funkcjonalność, ale poszczególne pytania gdzieś się gubią, utykają w testach, ktoś nie zmienił statusu… W tablicy kanban wszystko jest widoczne graficznie i jasne.
Na tym etapie raczej nie będzie oporu przed stosowaniem kanbana bo, wydaje mi się, że to jest jeden z fajniejszych i ciekawszych sposobów pracy. Większy opór może nastąpić ze strony Twojego przełożonego. Jeżeli wcześniej wymagał od Ciebie planowania zadań takich detalicznych na konkretny termin to teraz będzie musiał się trochę z tym pożegnać i musi zrozumieć, że to nie ma znaczenia kiedy wykonacie jakieś małe zadanie, ważne jest kiedy wykonacie poszczególny projekt. W etapie drugim ze strony zespołu nie spodziewałbym się więc problemów.
Gdy zespół zaczyna używać Kanbana
Powiedzieliśmy sobie w etapie 0 kiedy jest właściwy moment na wdrożenie kanbana. W etapie 1 omawiałem jego konfigurację. W etapie 2 prezentowanie tablicy zespołowi i to były te łatwiejsze rzeczy. Teraz przed nami etap 3, czyli kontrola wdrożenia kanbana i usprawnienia, które z niego wynikają.
W idealnym świecie wdrożenie kanbana właśnie się zakończyło, skonfigurowałeś swoją tablicę, powiedziałeś zespołowi jak mają jej używać i każdy naiwny kierownik projektu uznałby proces za skończony. Natomiast dokładnie w tym momencie zaczyna się prawdziwe wdrożenie kanbana, czyli będziesz cały czas pracował nad tym, żeby ludzie się do niego przekonali i faktycznie używali.
Samo powiedzenie ludziom, że wdrożyliśmy kanbana i teraz go będziemy używać to za mało. Wdrożenie z pozycji siły, czyli określenie bardzo restrykcyjnych kar za nieprzestrzeganie zasad też jest bez sensu. Moim zdaniem przynajmniej. Będzie też trochę o karach za kanbana, ale o tym powiem za chwilę.
Na początku po wdrożeniu prawdopodobnie będziecie mieli w nim bardzo dużo zaległych zadań. To na czym powinniście się skupić najpierw to wyczyszczenie tablicy. Te zadania, które są zadaniami widmo – które nigdy nie zostaną zrobione, w których nie wiadomo o co chodzi, które były już dawno wdrożone na produkcję albo już dawno wypadły i klient rozmyślił się z realizacji – po prostu zamknij, wyrzuć lub zarchiwizuj.
W pierwszym kroku chodzi o to, żeby doprowadzić do uporządkowania listy „to do”. Musisz też wyrobić w zespole taki nawyk, żeby nie patrzeć wstecz, nie rozmawiać o tym, co się udało zrobić, tylko co jeszcze zostało do zrobienia. Wiem, że może się to wydawać nieintuicyjne. Wiele osób, które pracują w scrumie omawiają to, co zostało zrobione poprzedniego dnia. Radziłbym jednak tego nie robić (chyba że są jakieś problemy), a bardziej skupić się na zadaniach które zostały do realizacji i kiedy je możemy oddać. Stwórz nawyk patrzenia w to do. Pierwszym krokiem jest pilnowanie i uporządkowanie tej kolumny. O priorytetyzacji też będę jeszcze mówił, to jest temat rzeka.
Jeżeli uporządkujecie wstępnie kolumnę „to do” to trzeba przejść w prawo do kolumny in progress. Sugerowałbym Ci tutaj pracowanie trybem iteracyjnym – kiedy uznajesz za skończoną i uporządkowaną kolumnę „to do” i mimo, że nie jest jeszcze idealnie – przechodzisz dalej. Jeżeli przejdziesz tak wszystkie kolumny to znów uporządkowujesz kolumnę „to do” i znowu przechodzisz dalej. Żeby kanban odniósł sukces potrzebny jest wysiłek Twój i programistów, testerów i wszystkich innych, którzy z niego korzystają.
Zmiany trzeba wdrażać małymi krokami – zacznij od porządkowania kolumny „to do”. Jeżeli to już będzie zrobione, przejdź do kolumny in progress. Tak jak mówiłem w tej kolumnie powinno być tylko jedno zadanie u każdego. Na początku to będzie kolosalny problem. Ja też dałem zespołowi trochę luzu, żeby w tej kolumnie były dwa zadanka, ale za każdym razem zaznaczałem, że przyjdzie taki dzień za parę tygodni kiedy to się zmieni. Zbyt duża restrykcja na początku może zrazić ludzi i trzeba stopniowo pokazywać zalety i nauczyć ich organizować pracę z poziomu kanbana zamiast robić to z poziomu siły. Cały czas warto powtarzać te zasady, że zadanie in progress jest jedno i że będziemy do tego dążyć.
Po tym etapie, kiedy Twój zespół programistów już korzysta z kanbana i zarówno kolumna „to do” jak i kolumna „in progress” jest w miarę ok (z dalszą mogą być jeszcze problemy np. testerzy nie rozumieją koncepcji kanbana i zadania gdzieś umykają) warto zakomunikować jako organizacja, że kanban jest dla was ważny. Taką komunikacją może być jakiś mail firmowy. Chodzi o zaznaczenie nowego początku, że od dziś pracujemy w taki sposób. Taki komunikat powinien wyjść od organizacji. Ty możesz oczywiście wysłać taki komunikat do swojego zespołu, ale też dobrze żeby on wyszedł od osoby, pod którą są inne jednostki np. jeżeli pod Twoją hierarchią nie ma testerów to dobrze żeby to wyszło od osoby, której testerzy się zawierają. Chodzi o osobę, która ma autorytet wśród innych.
Korygowanie kursu
Ważne jest tutaj opracowanie systemu kar i nagród. Wiem, że wielu managerom słowo kara w ogóle nie przechodzi przez gardło, ale tutaj to rozumienie kary jest trochę spaczone względem tego, jakie jest faktyczne znaczenie kary. Ja jestem zwolennikiem żeby bardziej nagradzać za dobre zachowanie, niż żeby karać za złe. Mimo wszystko musisz sobie przed wdrożeniem kanbana opracować taki system kar i system nagród, jak będziesz reagował na to jeśli ktoś np. przez pół roku nie jest w stanie zapamiętać jakie są znaczenia statusu. Kończy się pewna granica kiedy już musimy zacząć stosować kary.
Oczywiście nie mówię tego po to, żeby zacząć stosować je od pierwszego dnia, to może być po kilku miesiącach. Trzeba mówić o tych zasadach i dać ludziom czas na naukę, a nie od razu przychodzić z karami i to jest oczywiste.
Kary mogą być nieformalne, jak i formalne. Np. karą nieformalną może być mniej ciekawe zadanie. Powiedzmy, że jest jakiś typ zadań których nikt nie lubi i w ramach kary nieformalnej osoba, która nie potrafi się dostosować będzie wykonywała te zadania. Taką karą może być też mniejszy priorytet przy planowaniu urlopu czyli rozpatrujemy wniosek tej osoby po innych wnioskach.
Kary bardziej formalne to np. brak premii albo rozmowa prostująca, kiedy prostujemy kogoś, że źle coś robi. Skrajne przypadki to oczywiście zwolnienie, kiedy ktoś totalnie nie jest w stanie się dostosować do naszych zasad. I nie zrozum mnie źle – nie mówię, że każdy kto ma problem z pracą w kanbanie powinien być zwolniony albo podlegać karze. Chodzi mi bardziej o to, żebyś opracował sobie system kar i system nagród, który będziesz stosował. Musisz to wszystko opracować wcześniej, żeby już z gotowym planem przyjść do zespołu.
Oczywiście nie mówię o stopniowaniu kar ale zastosuj jako karę nieformalną np. bardziej oschły stosunek wobec danego programisty. Ludzie to zauważają i też może to być postrzegane jako kara, więc masz tutaj naprawdę dużą paletę barw. Kary to niekoniecznie chłosta albo zwolnienie. Jest naprawdę dużo możliwości stopniowania. Nie bój się ich stosować ale rób to z rozwagą wtedy kiedy masz pewność, że są adekwatne do sytuacji.
Musisz też sobie określić pochwały. W każdym środowisku projektowym są takie osoby, które podchodzą do zmian bardziej optymistycznie. Może się tak zdarzyć, że one będą do tego podchodzić bardziej ideowo, bardziej będą przestrzegać ustalonych zasad. Takie osoby warto nagradzać. Będą to Twoi tzw. liderzy zmian, z których inni powinni brać przykład. Nagrodami może być odwrotność kar czyli ciekawsze zadania, ciekawsze projekty, większe priorytety przy planowaniu urlopu, większa premia, pochwały na callach lub po prostu jakieś awanse. W każdym razie system nagród i kar każdy powinien dobrać pod swoje możliwości.
Na tym etapie usprawnień oczywiście spotkasz się z wieloma trudnościami. Główną trudnością, którą zauważysz nawet w pierwszych minutach od wdrożenia jest to, że programiści nie pilnują statusów zadań. To jest chyba największą zmorą każdego kierownika projektu.
My możemy sobie wszystko idealnie zaplanować, powiedzieć, opisać, przesłać maile ale co z tego jeśli ludzie nie będą chcieli z tego korzystać? Zamiast się na nich złościć i od razu karać trzeba najpierw zrozumieć przyczynę i spróbować im pomóc. Według mnie przyczyną jest fakt, że ludzie nie organizują swojej pracy w oparciu o tablicę kanbanową tylko np. dla kogoś listą to są emaile – wpada zadanie, programista nie odczytuje tego zadania dopóki go zrobi. Innym przykładem mogą być filtry na zadania – dany developer robi filtr, gdzie wyświetlają mu się zadania ze statusem backlog, selected for development itp. i taka listą sobie organizuje zadania.
Musimy jednak pamiętać, że to nie jest kanban. Taka lista zadań na podstawie filtrów nie wymaga pilnowania statusów bo to jest nieistotne z punktu widzenia tej listy. Są tez inne przypadki kiedy ktoś ma listę zadań poza kanbanem czyli np. notuje w notesie lub korzysta z Todoista lub innej aplikacji.
Są też ludzie, którzy się w ogóle nie organizują. Przyczyną, tego że ludzie nie używają kanbana jest to, że ich centrum zarzadzania jest w innym miejscu. To co musisz zrobić, żeby zmienić sytuację, to po prostu stworzyć potrzebę korzystania z tej tablicy. Ludzie muszą czuć, że ona jest im potrzebna do organizowania pracy. Jeżeli zaczną się tak organizować to zaczną aktualizować statusy zadań.
Generalnie ludzie podchodzą do pracy tak, ze chcą wykonać swoje zadanie dobrze. Nie spotyka się ludzi, którzy przychodzą do pracy z zamiarem opóźniania zadań. Niepilnowanie statusów wynika z tego, że jest to nieistotne z ich punktu widzenia. Jeżeli sprawisz, że kanban będzie ich centrum dowodzenia, centrum organizacji nad ich zadaniami i nad ich pracą to wtedy będą to robić.
Możesz stworzyć taką potrzebę np. omawiając jakieś calle statusowe na podstawie kanbana. Czyli ten kto omawia udostępnia swój ekran, omawia swój swimlane i zadania. Takie omawianie spowoduje, że będzie oceniany na tej podstawie. Jeżeli będziesz oceniał kogoś na podstawie tablicy kanbanowej, to on będzie przykładał się do tego, żeby była w idealnym porządku. Tutaj oceniać oczywiście jest w cudzysłowie, chodzi o jakąś weryfikację lub kontrolę zadań. Jeśli ktoś wie, że jedynym wskaźnikiem oceny jest tablica kanban, to będzie o nią dbał – nie o swoje maile czy listę zadań na kartce.
Warto też wdrożyć taką zasadę, którą ja nazywam „zadanie parzy” czyli jak najszybciej przepiąć je na kogoś innego, żeby mieć w swojej kolumnie jak najmniej. Te rzeczy mogą wpłynąć na to, że programiści będą mieli swoje centrum zarządzania w tablicy kanbanowej, że ona będzie żyła. Najgorsze co możesz zrobić to pytać cały czas czy tablica jest aktualna. Kiedyś musi nastąpić moment, że będziesz miał pewność.
Masz do dyspozycji kary, masz do dyspozycji nagrody i wszystko zależy od Ciebie. Ważne jest żeby dać zespołowi czas na naukę i nie wywoływać niepotrzebnie zbyt dużej presji, tylko pomóc im skupić uwagę na kanbanie.
Kolejną trudnością, z którą się spotykałem jest to, że testerzy i biznes nie pilnują statusów. Ty możesz w swoim zespole programistów wdrożyć pilnowanie zadań, możecie to organizować perfekcyjnie, ale co z tego jeżeli biznes nie chce zakładać zadań tylko dzwoni i wszystko załatwia rozmową? Albo testerzy nie aktualizują statusów i to utrudnia pracę programistom? W tej sytuacji masz dwie drogi, w zależności od swojej pozycji. Jeżeli ktoś jest niżej pod Tobą np. testerzy to możesz po prostu stworzyć potrzebę narzędziami analogicznymi, jak robiłeś to dla programistów.
W tym przypadku możesz też stworzyć im osobną tablicę kanban, o czym mówiłem na początku, gdzie np. kolumna „to do” zawiera status ready for test bo z ich punktu widzenia to jest do zrobienia. Tego typu ułatwienia mogą wpłynąć na to, że zaczną tych statusów zadań pilnować. Dodatkowo email komunikacyjny, musi się tyczyć wszystkich, żeby wszyscy mieli poczucie, że dążymy do tego, aby statusy zadań były aktualne.
Trudniej będzie przekonać do korzystania z kanbana i aktualizacji zadań osoby, które są powyżej Ciebie czyli np. kierownicy projektów, którzy są na równi i Twój szef. W wielu firmach jest coś takiego jak cotygodniowe spotkanie, taka jakby odprawa, na której spotykają się wszyscy kierownicy projektu ze swoim przełożonym i raportują jaki jest plan, co się udało zrobić, czego się nie udało zrobić, jakie są trudności itp.
Na tych rozmowach omawiaj swój plan na tablicy kanban, czyli chwaląc się tymi metrykami resolved, done, test verified. Po pewnym czasie to jest na pewno bardziej miarodajne, niż osoby, które po prostu informują ile zadań zostało ukończonych (ale np. są to zadania widmo i nikt ich nie widzi). Jeżeli wejdziesz z takim sposobem prezentacji z kanbana i będziesz pokazywał wizualnie jak to wygląda, możesz określić przerób i pochwalić się różnymi metrykami.
Uwierz mi, że w oczach Twojego przełożonego wyjdzie na to, że warto tego kanbana zrobić. Też jeżeli będziesz omawiał tak postępy to będzie widać osoby, które tego kanbana nie aktualizują. To na pewno zwróci uwagę Twojego przełożonego, że nieaktualizowanie statusów zadań psuje pracę tym, którzy to robią. Możesz spodziewać się wtedy jakiejś reakcji przełożonego, który pomoże Ci swoim autorytetem wymusić pilnowanie zadań. Ale to już jest czysto z pozycji siły, co zostawiamy sobie jako ostateczność.
Jeżeli już udało Ci się programistów i testerów dopilnować, żeby te statusy zadań przepinali na osoby biznesowe to wtedy stworzy realną potrzebę żeby biznes korzystał z tych zadań. Jeżeli będziemy komunikować się za pomocą statusów zadań czyli nie piszemy maila, że coś zostało wdrożone tylko informujemy na podstawie odpowiedniego statusu.
Jeśli przepisaliśmy grupę zadań na osobę, która prowadzi danego klienta i to jest wystarczający komunikat, że coś zostało wdrożone to tworząc taką komunikację osoba, która odpowiada za kontakt z klientem będzie oczekiwała, żeby te zadania na nią wpłynęły (bo chce się jak najszybciej pochwalić przed klientem). Więc przenoszenie tej komunikacji na status zadań będzie istotne z Twojego punktu widzenia.
Podsumowanie
Przeszliśmy przez wszystkie etapy. Myślę też że sam spotkasz jakieś unikalne problemy o których nie powiedziałem bo musisz sobie zdawać sprawę, że każda organizacja jest inna, każdy problem jest inny i nie byłem w stanie opowiedzieć o wszystkich problemach, które mogą wystąpić. Mam nadzieję, że trochę Ci jednak pomogłem i nakreśliłem taki timeline, kiedy te problemy są spodziewane na danym etapie. Jestem bardzo ciekawy jeśli opisałbyś mi swoje skutki wdrożenia kanbana, jak u Ciebie to wyglądało i czym się zakończyło -napisz po prostu na moim blogu w komentarzu do linka do tego odcinka.
Podsumowując najtrudniejsze jest przekonanie ludzi do korzystania z nowych narzędzi. Łatwo jest ułożyć procedurę, jak mamy z czegoś skorzystać. Łatwo jest skonfigurować dane narzędzie. Dość łatwo jest nawet zakomunikować tę zmianę, ale najtrudniejsze jest wprowadzenie zmiany, czyli nakłonienie ludzi żeby chcieli z tego korzystać. Aby ludzie chcieli zmian to muszą one być dla nich korzystne. Muszą z jednej strony czuć że warto, że ich praca będzie łatwiejsza, bardziej zorganizowana i przewidywalna, będzie mniej stresu. Z kolei też w odwrotnej sytuacji muszą wiedzieć, że jeżeli nie będą się stosować do wytycznych, to będą różnego rodzaju kary i konsekwencje. I nie chodzi o jakieś bardzo ostre i dotkliwe, tylko o te kary nieformalne, delikatne o których mówiłem wcześniej.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
🎯 Jeśli podoba Ci się co mówię, sprawdź moje kursy:
- WycenaProjektow.pl – wyceń projekt, aby skończyć go na czas
- Dokumentacja.Pro – twórz zrozumiałe dokumentacje IT
Subskrybuj podcast na:
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
