To był całkiem fajny zespół. Już jakiś czas temu zdecydowali się na wykorzystanie Scruma do swojej pracy. Podobała im się idea Sprintów, posiadanie celu i wiele innych aspektów związanych z tym podejściem. Niestety musieli walczyć z jednym problemem – stale ktoś im psuł Sprinty przez dorzucanie pilnych zadań.
Znasz to? Argumentacja zawsze była taka sama – “na stole są duże pieniądze i musimy to mieć na wczoraj”. Nikt nie stopował interesariuszy. Wrzutki (niezapowiedziane, niezaplanowane zadania) stały się normą i generowały dużo chaosu, spowalniały zespół. W końcu się poddali, zrezygnowali ze Scruma i wybrali inne zwinne podejście – Kanban. Argumentowali, rozczarowani, “i tak nie dajemy rady nic zaplanować na dwa tygodnie, więc po prostu przejdźmy na Kanban” .
Kanban jest OK, ale są też inne drogi
Jakie zespół miał inne wyjścia? Nie musiał od razu rezygnować ze Scruma na rzecz Kanbana. Zespół mógłby wybrać spośród innych rozwiązań:
- Naprawdę „bronić się”, z wykorzystaniem sił Scrum Mastera i Product Ownera.
- Planować nieco inaczej – z zachowanym miejscem na wrzutki.
- Skrócić Sprinty do jednotygodniowych.
Odbijanie wrzutek
W pierwszej opcji zostajemy przy Scrumie i jego zasadach. Trzeba nauczyć organizację, że “wrzutki = ble”, pomóc Product Ownerowi w odbijaniu ich, wzmocnić asertywność całego zespołu. Dobre zadanie dla Scrum Mastera. Metody jego działania i rozwiązania będą zależały od kontekstu – można np. nauczyć interesariuszy jak mogą rozmawiać z Product Ownerem o istotności ich potrzeb. Ponadto można pokazać negatywne skutki wrzutek oraz pozytywne stabilnego tempa pracy.
Sam Product Owner powinien w ogóle spróbować mówić „nie” ☜ mówienie „nie” działa cuda, a często czujemy opór, aby w ogóle zacząć odmawiać 😎
Odbijanie wrzutek jest trudne, bo trzeba być asertywnym, a nie każdy to potrafi i lubi. Przeniesienie wszelkich dyskusji o pilności projektów i zadań na grunt wartości biznesowych, jakie miałyby dostarczać, zadawanie pytań o fakty i argumenty to jedno z lepszych rozwiązań – często się okaże, że biznesowo coś jeszcze nie jest gotowe i może zaczekać. Może też okazać się zupełnie odwrotnie, ale jeśli kierują nami racjonalne argumenty to przynajmniej każdy rozumie czemu dany projekt jest rzeczywiście istotny. Same wrzutki nie są niczym katastrofalnym i często nie da się ich uniknąć – to ich rozmiar, waga i liczba robią problem.
Przewidywanie niezapowiedzianego – przestrzeń na wrzutki na planowaniu
Opcja nr 2 mówi, że podczas planowania, można zostawić nieco przestrzeni na niezapowiedziane. Nie ma tu magicznych kalkulatorów, które podpowiedzą ile tej przestrzeni winno być, ale na podstawie danych historycznych można to spróbować oszacować (np. zespół przeciętnie dostaje wrzutki o łącznym rozmiarze 15 story pointów). Kolejne Planowanie zatem można zrobić „na 15 story pointów mniej” niż prognozujemy, że możemy zrealizować (velocity). Takie Planowanie pozwala zachować kręgosłup scrumowy z celem sprintu, koncentracją i jednocześnie odpowiadać na wrzutki.
Pewnym dodatkiem czy rozszerzeniem tego jest stworzenie funkcji dyżurnego w zespole, który reaguje na wszelkie wrzutki, podczas gdy reszta osób może spokojnie realizować plan. Jest to możliwe oczywiście wówczas, gdy wrzutki są odpowiednio małe, aby jedna osoba je ogarnęła w krótkim czasie.
Opcja ta jest pewnym nagięciem idei sprintów i planowania. Z reguły zaleca się, aby zmiany trzymać poza sprintem. Nie zmienia to faktu, że w praktyce dla niektórych zespołów to najlepsze z rozwiązań, które pozwoli im nadal pracować w ramach, które lubią i jednocześnie zapewniać szybkie reagowanie na zadania nie mogące czekać.
Warto jednak pamiętać, że takie rozwiązanie może dodatkowo spowodować, że interesariusze poczują, że ta przestrzeń jest normą, więc mogą ją próbować poszerzać.
Sprinty jednotygodniowe
Trzecia droga to skrócenie sprintów do jednotygodniowych. W tym rozwiązaniu interesariusze będą czekali krócej na odpowiedź na ich potrzeby, więc ewentualne „odbicie” będzie łatwiejsze. Ponadto w zespołach korzystających z takiej długości sprintów często włącza się duży stopień asertywności – skoro to tylko tydzień, który fajnie zaplanowaliśmy i idzie nam nieźle to obrońmy ten plan, bo zmarnowalibyśmy dotychczasowy wysiłek zmieniając kurs. Samo otoczenie zespołu często uczy się, że warto odpuścić i zaczekać na następny sprint.
Faktem jest jednak, że sprinty jednotygodniowe nie pasują każdemu zespołowi – czasem deweloperzy uznają je za zbyt krótkie i zbyt dynamiczne.
Najwięcej zależy od nas samych
To nie wszystkie możliwe opcje. Opisałem te, które widziałem w swoim życiu, jak zadziałały i jednocześnie wydają się być naturalnymi ścieżkami. Środki warto dobierać do konkretnych problemów i sytuacji 🤔
Scrum czy Kanban nie są sekretnym przepisem na to jak fajnie pracować, bez problemów itd. To tylko (i aż?) pewne ramy do pracy. Same z siebie nie spowodują, że przestaniemy mieć wrzutki. Pomogą nam określić pewne podstawy zasad, ale na koniec dnia to od nas zależy, jak z nich będziemy korzystali i czy wyciągniemy z nich tyle wartości ile możemy. Musimy być zatem zdyscyplinowani, konsekwentni i asertywni.
Zatem następnym razem, gdy spotkasz zespół, który będzie chciał “przejść na Kanban, bo ten Scrum nie działa i nic nie możemy zaplanować”, to zamiast się na to od razu zdecydować, spróbujcie na spokojnie przeanalizować problemy oraz zastanowić się co będzie dla Was najlepsze, jakich wartości potrzebujecie, czego oczekuje od Was organizacja itd. Gdy już wybierzecie Kanban jako sposób pracy to warto pamiętać o tym, że Kanban to więcej niż kolejka zadań i wizualizacja.
Czy to Scrum czy Kanban, czy cokolwiek innego – najważniejsze jest to, aby sposoby działania świadomie dobrać do charakteru zespołu i jego otoczenia, a następnie mądrze i konsekwentnie z nich korzystać.
4 odpowiedzi na “„Przejdźmy na Kanban, bo mamy dużo wrzutek w sprintach” – przypadek z życia pewnego zespołu”
Tak się cieszę, że znalazłam ten blog! Mnóstwo inspiracji, bardzo jasno uchwycony kontent, merytoryka z życia wzięta. Autorze, dziękuję Ci za Twoją pracę :)
Dzięki! Te słowa dla nas wiele znaczą :)
Ja natomiast ostatnio pracowałem w zespole, który miał dużo wrzutek więc… przeszedł z kanbana na scruma;) No i rzeczywiście wrzutek jest mniej, choć chyba raczej dlatego, że Product Owner się „ogarnął”.
Widzisz, jednym z elementów Scruma są zaplanowane sprinty – zespół ma całkiem sensowne narzędzie i argumenty do odbijania wrzutek, w teorii zatem powinny czekać na następny sprint . Zatem zgadzam się, że można z Kanban przejść na Scrum, m.in. ze względu na poziom dynamiki itd. Tylko, że do tego trzeba umieć poradzić sobie z odbijaniem – być asertywnym itd. Jednocześnie są zespoły, do których raczej nie będzie pasował Scrum – takie zespoły, które odpowiadają za reagowanie na nagłe zdarzenia, łatają pilne błędy, muszą reagować bezzwłocznie – ich praca to „100% wrzutek” ;-)