fbpx
Menu Zamknij

Zwinne zarządzanie projektami. Część IV: Scrum czy kanban? A może Scrumban?

Scrumban

Wpis gościnny autorstwa Magdy Nicgorskiej, zdalnej project managerki z 8-letnim doświadczeniem w zarządzaniu projektami i zespołami.

W poprzednich wpisach omawiałam najpopularniejsze zwinne sposoby prowadzenia zespołów i organizacji pracy – Scrum i kanban (tablice kanbanowe). Mając taką wiedzę można się zastanawiać nad wdrożeniem któregoś z nich w swojej pracy. Dziś zastanowimy się jak wybrać właściwe dla nas zwinne podejście: Scrum, kanban czy może Scrumban.

Z tego wpisu dowiesz się:

  1. Jakie są różnice między Scrum i kanban
  2. Czym jest Scrumban
  3. Jak wybrać najlepsze dla nas zwinne podejście
  4. Jak nie wdrażać Agile

Jakie są różnice między Scrum i kanban?

Choć z pozoru podobne, można znaleźć wiele różnic między tymi podejściami. Podejmując decyzję o wyborze należy rozważyć wiele różnych aspektów np.: wielkość zespołu, charakter jego pracy, nasze zasoby (czasowe i osobowe) czy też sposób zarządzania całą organizacją, w której pracujemy.

Uważam też, że równie ważne, jak świadomość czym są różne metodyki, jest wiedza o tym czym one nie są. Dzięki temu można się ustrzec przed niektórymi błędami w organizacji pracy. Można też wiedzieć czego oczekiwać po zespołach prowadzonych w taki właśnie sposób.

Przeznaczenie

Tablice kanbanowe można stosować do organizacji pracy zarówno własnej, jak i zespołu. Scrum nie nadaje się do zarządzania czasem pojedynczej osoby, stworzony został dla zespołów (oryginalnie deweloperskich). Scrum sprawdzi się zatem przy projektach wytwarzających produkty lub usługi. Kanban natomiast bardzo dobrze nadaje się do zespołów, których praca ma charakter ciągły. Na przykład zespoły utrzymania czy obsługi zgłoszeń, zespoły serwisowe (np. obsługa sklepów internetowych lub zarządzanie zadaniami WA). Zadania w kolejce mogą otrzymywać priorytety, dzięki którym zapewniona jest sprawna realizacja tych najważniejszych.

Próg wejścia

Wdrożenie tablic kanbanowych do organizacji pracy zespołu jest stosunkowo proste i nie wymaga zbyt wielu zmian personalnych ani organizacyjnych. To raczej inne spojrzenie na planowanie i pracę w toku. Eksperci mówią, że wdrożenie do zespołu tablic kanbanowych trwa średnio około tygodnia. 

Z drugiej zaś strony należy podkreślić, że Scrum jest dużo bardziej złożony niż Kanban. Zakłada duże zaangażowanie zespołu i jego „samoorganizację”. Próg wejścia w Scrum jest dużo wyższy niż w kanban (szacuje się, że to kilka tygodni, nawet do dwóch miesięcy). Zazwyczaj wymaga szkolenia członków zespołu. Wdrożenie Scrum w zespole czy też organizacji wymaga zmiany spojrzenia na planowanie i proces dostarczania produktów lub usług. Gdy decydujemy się na wdrożenie Scrum najlepiej przyjąć, że zgadzamy się na wszystkie jego reguły. 

Zespół

Twórcy Scrum zalecają zespół składający się z 5 do 9 osób oraz definiują bardzo konkretne role: Scrum Master, Product Owner, Członek zespołu. Dla przypomnienia rola Scrum Mastera nie jest kierownicza, ma on dbać o komfort pracy zespołu i stosowanie zasad metodyki. W Scrumie zakładamy, że zespół jest samoorganizujący się.

W Kanban rozmiar zespołu nie ma aż takiego znaczenia (oczywiście tu również istnieją pewne zalecenia, aby zespół nie przekraczał 10 osób), nie zostały również określone żadne specyficzne role. Stosowanie tablic kanbanowych do zarządzania zespołem nie wyklucza np. tego by zespół miał lidera. 

Scrumban

Sposób zarządzania i planowania pracy

Wdrożenie Scrum to odejście od centralnie sterowanego planowania i „oddanie władzy” w zakresie ustalania możliwości przerobowych w ręce zespołu. W Scrumie zakres pracy określany jest na dany sprint i na ogół nie zaleca się modyfikowania backlogu sprintu w czasie jego trwania. 

Reguły regułami, a życie życiem. W związku z tym, że nie zaleca się zmiany zakresu sprintu w czasie jego trwania, zespół powinien albo uwzględniać w czasie planowania bufor na nieprzewidziane zadania, albo otoczenie powinno przyzwyczaić się, że ich „wrzutki” zostaną rozwiązane dopiero w kolejnych iteracjach. 

Dzięki krótkim iteracjom Scrum co prawda nadal jest bardziej elastyczny niż klasyczny, kaskadowy model wytwórczy, jednak często problematyczne staje się obsługiwanie nieprzewidzianego. Jeśli więc dynamika pracy naszego zespołu jest mocno zmienna, zadania napływają ciągle i planowanie nawet krótkich iteracji mija się z celem, można wtedy rozważyć kanban. 

Tablice kanbanowe są pod tym względem dużo bardziej elastyczne. Nie ograniczają też pracy zespołu iteracjami, więc pilne zadania mogą zostać obsłużone zgodnie ze swoim priorytetem, jak tylko pojawią się wolne moce przerobowe w zespole. Nadal nie wiesz co będzie lepsze? Nic nie szkodzi, wymyślono jeszcze coś takiego jak Scrumban.

Co to jest Scrumban?

Scrumban jest to stosunkowo świeży termin. Jak byłam na studiach, to w Polsce dopiero zaczynało mówić się o Scrumie. Nikt nie słyszał wtedy o takim tworze jak Scrumban.

Mimo swoich niepodważalnych zalet Scrum nie zawsze się przyjmuje. Czasem okazuje się, że otoczenie jest tak szybko zmienne, że nawet bardzo krótkie sprinty są za długie. Liczba nieprzewidzianych zdarzeń przytłacza zespół i uniemożliwia realne planowanie pracy.

Z drugiej strony korzyści z wielu praktyk scrumowych są dla zespołu bardzo duże – np. codzienne spotkania pozwalające zespołowi na bycie na bieżąco lub retrospektywy, które pozwalają na ciągle jego ulepszanie.

Dlatego, w dużym skrócie, pomyślano, żeby…

… wziąć to, co najlepsze ze Scruma i z kanbana i zrobić z tego mix

Zazwyczaj mix ten polega na tym, że zmniejszamy rygor Scruma, pozostajemy przy niektórych ceremoniach, jednak pracą zarządzamy za pomocą tablic kanbanowych kontrolując pracę w toku. Nie jest to jakoś mocno sformalizowane, różne zespoły bardzo różnie do tego podchodzą.

Scrumban sprawdza się dobrze w zespołach z dużą ilością nieprzewidzianych zadań, np. w projektach skomplikowanych, gdzie często występują błędy lub wymagania użytkowników zmieniają się w locie. Nie zawsze mamy też możliwość rozdzielenia zespołu wytwórczego od zespołu utrzymania i wtedy wprowadzenie Scrumban pozwoli lepiej zarządzać zadaniami pochodzącymi z różnych źródeł.

Jak wybrać najlepsze dla nas zwinne podejście?

Najpierw w ramach podsumowania przytoczę nieco rozbudowaną tabelkę z pierwszej części naszego cyklu

KanbanScrumScrumban
Najważniejsze
cechy
Wizualizacja
procesu, nadzór nad ilością
zadań w toku,
kontrola
przepływu pracy.
Samoorganizujący się zespół,
podział pracy na iteracje,
wydarzenia i artefakty.
Połączenie sposobu wizualizacji
pracy na tablicach kanbanowych z ideą samoorganizującego się
zespołu.
Zarządzanie czasem / sobą w czasie TAKNIENIE
Zarządzanie pracą zespołu TAKTAKTAK
Zalecana wielkość zespołu Do 10 osób5 do 9 osóbDo 10 osób
Łatwość wdrożenia / średni proces akceptacji Około tygodniaNawet kilka tygodniNawet do miesiąca
Sformalizowane role NIETAK, Scrum Master, Product Owner, ZespółNIE, w zależności od potrzeb
Rodzaj pracy zespołu Wytwarzanie produktów / usług, praca o charakterze ciągłymProjekty wytwarzające produkty i usługi.Zespoły o ciągłym charakterze pracy (np. serwisowe, utrzymaniowe) lub łączące te zadania z wytwarzaniem produktu, lub usługi.
Sposób planowania pracy Tablice kanbanowe, zarządzanie pracą w tokuProduct backlog i sprint backlog, planowanie sprintu. Pilnowanie by jego zakres, co do zasady, nie ulegał zmianieTablice kanbanowe, zarządzanie pracą w toku.
Reagowanie na nieprzewidziane zadania Zadania wpadają na listę TODO i są realizowane zgodnie z priorytetem.Co do zasady nie powinno się rozszerzać zakresu sprintu. Należy uwzględnić bufor w planowaniu lub realizować w kolejnych sprintach.Wpadają na listę TODO i są realizowane zgodnie z priorytetem.

Odpowiedź na pytanie, co wybrać, nie jest jednoznaczna. Jak zawsze, należy rozważyć za i przeciw w odniesieniu do własnej sytuacji i dokonać najlepszego dla nas, w danej chwili, wyboru. To, co wybierzemy, i po której stronie parasola Agile znajdziemy odpowiednie narzędzia, zależy od wielu zmiennych.

Przede wszystkim od tego, co właściwie chcemy zrobić. Zastanówmy się więc:

  • Po co to robimy? Jaki cel chcemy osiągnąć?
  • Czy wprowadzamy zupełnie nowy produkt?
  • Projekt to jednorazowa inicjatywa, czy pracujemy w środowisku wielu powiązanych projektów?
  • Czy wprowadzamy Agile tylko w małym zespole, czy w całej organizacji? Jaka jest nasza organizacja, jak duży nacisk kładzie na formalizm.
  • Czy będziemy mogli pozwolić sobie na minimalny poziom dokumentacji na rzecz bliskiej współpracy z biznesem?

Zamiast podsumowania  – jak nie wdrażać Agile!

Na koniec chciałam zostawić kilka przemyśleń na temat tego jak nie zabierać się za wdrażanie Agile. Często oczekiwania rozmijają się z rzeczywistością i spotykam się ze stwierdzeniami, że „po staremu było lepiej” lub np. „po co nam ten Scrum Master”.

  1. Często Agile to tylko marketingowe hasło. Wdrażamy Scruma, czy tam jesteśmy Agile, ale nadal wymagamy sztywnych harmonogramów realizacji i mamy określony termin wdrożenia oraz pełną listę funkcjonalności, jakich oczekujemy w tym terminie.
  2. Duże oczekiwania – małe możliwości. Od pierwszych sprintów oczekuje się od zespołów, że przedstawią działające rozwiązanie nie uwzględniając czasu potrzebnego na uformowanie się zespołu i jego początkowe działania. Na zespoły projektowe wywierana jest presja, wymaga się przerobienia określonej porcji zakresu, mimo że jest to ponad jego moce. Ingeruje się w wyceny zespołu lub jego sposób pracy.
  3. Samoorganizujące się zespoły wszystko zrobią same. Metodyki zwinne zakładają samoorganizację zespołów. Bliską współpracę między ludźmi biorącymi udział w projekcie. Z moich obserwacji wynika, że nie jest to dla każdego. Aby projekt prowadzony taką metodyką się udał wszyscy w niego zaangażowani muszą rozumieć, na czym polega praca zwinna. 
  4. „Biznes” nie jest odpowiednio zaangażowany w projekt. Zapomina się o tym, jak istotna jest współpraca zespołu projektowego z biznesem. Osoby oddelegowane do przygotowywania wymagań mają inne zajęcia i często projektem zajmują się w „międzyczasie”.
  5. Brak decyzyjności. Osobom oddelegowanym do projektu nie przekazuje się wystarczającej decyzyjności. Nie należy stosować metodyk zwinnych, jeśli w organizacji jest problem z decyzyjnością. Jeśli podejmowanie decyzji projektowych trwa wiele dni (np. jest kilkustopniowe, wymaga wielu konsultacji albo zwyczajnie ludzie boją się konsekwencji swoich decyzji, to marne szanse na powodzenie projektu prowadzonego metodyką zwinną.
  6. Agile nie wymaga dokumentacji ani testów. W końcu wszystko można naprawić w następnym sprincie. Często ludzie przyjmują, że Scrum oznacza kompletny brak dokumentacji. Nie przykładają istotnej wagi do historyjek. Historyjki są mierne, niewystarczające do rozpoczęcia implementacji, a presja nie maleje. Spotkałam się z praktyką, że gdy na etapie planowania historyjki wychodziły nieścisłości, zamiast zostawić ją na moment, gdy będzie lepiej dopracowana, PO machał ręką, że naprawi się to najwyżej w następnym sprincie. Nikt tylko nie brał pod uwagę tego, że w następnym sprincie będzie już presja na coś innego i może zabraknąć czasu.
Magda Nicgorska z narudo.pl

Magda z narudo.pl

Cześć, jestem Magda, ta z narudo.pl – entuzjastka technologii, project manager i analityk IT. Wspieram przedsiębiorców i twórców internetowych w organizacji i planowaniu oraz skutecznym wykorzystywaniu narzędzi online i sztucznej inteligencji. Wierzę w optymalizację pracy i efektywne zarządzanie, jestem gotowa podzielić się swoim doświadczeniem i wiedzą, abyśmy mogli pracować mądrzej, nie ciężej.

Na mojej stronie znajdziesz informacje dotyczące organizacji, planowania oraz wykorzystania technologii w biznesie. Zapraszam Cię do odkrywania razem ze mną tajników efektywnego zarządzania projektem, wykorzystywania narzędzi AI i rozwijania swojego biznesu. Jeśli zależy Ci na pracowaniu sprytnie, a jednocześnie skutecznie zapisz się na mój newsletter i odbierz darmowy e-book „Jak wykorzystać potencjał sztucznej inteligencji”.

Podobne wpisy

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *