#083 – Zacznij kończyć, przestań zaczynać

Częsty problem, jaki widzimy w zespołach, to pracowanie nad wieloma zadaniami naraz. Zaczynają kolejne zadania, nie kończąc rozpoczętych, co generuje problemy. Jak zatem można zmierzyć się z problemem niekończenia już rozpoczętych prac? Mamy kilka rad dla zespołów oraz osób zarządzających zespołami.

Zapraszamy Cię do obejrzenia nagrania podcastu i przeczytania artykułu.

Jak często zdarza Ci się rozpoczynać nowe zadania lub projekt, zanim zakończysz wcześniej rozpoczęty? Jest to częsty problem w zespołach, z którymi pracujemy, dlatego dziś przyjrzymy się temu tematowi bliżej i porozmawiamy o kończeniu pracy.

Z doświadczenia wiemy, że takie działanie wpływa na masę innych rzeczy. Po części temat ten poruszaliśmy już w odcinku #067. „Mamy zbyt wiele projektów i co z tym zrobić?”. Tam skupiliśmy się na poziomie wielu projektów w całej organizacji. Ten artykuł natomiast będzie dotyczył pracy zespołu i pracy indywidualnej, która się realizuje jednocześnie w ramach danego zespołu. 

Jak kończyć rozpoczętą pracę – rady dla zespołów

1.  Dziel pracę na mniejsze kawałki. 

O dzieleniu pracy na mniejsze kawałki rozmawialiśmy w odcinku nr 76. Jest to jedno z głównych rozwiązań problemu z rozpoczynaniem nowych tematów jeszcze przed zakończeniem tych, nad którymi aktualnie pracujemy. 

Dlaczego? Praca, której zakres jest zbyt duży, często trwa długo i powoduje zniecierpliwienie np. osób spoza zespołu, którzy naciskają, aby zacząć nowe tematy, które za długo stoją w miejscu i czekają na swoją kolej. Duże kawałki pracy często też utykają z różnych powodów. Przyczyn może być wiele, a najprostszym rozwiązaniem dzielenie pracy na mniejsze kawałki, dzięki czemu jest szansa, że skończymy ją w krótszym czasie i będziemy mogli zająć się kolejnym tematem

2. Planuj jeden konkretny krok. 

W Zespołach Scrumowych najczęściej odbywa się to w ten sposób, że Product Owner określa, czym zajmuje się zespół i planuje konkretne cele. Problem pojawia się wtedy, gdy ten cel nie jest pojedynczym celem, a stanowi tzw. złożony wielocel. Zamiast jednego konkretnego celu, mamy kilka celów, albo zamiast jednej najważniejszej rzeczy, mamy kilka najważniejszych rzeczy. I tu znów, zamiast skupiać się na zrobieniu jednej rzeczy, ale porządnie i do końca, już od samego początku rozdrabniamy się na kilka tematów

Nasza rada brzmi: róbcie wszystko, aby skupiać się na konkretnej jednej rzeczy, konkretnym jednym celu, jednym priorytecie. Przy próbie złapania wielu srok za ogon najczęściej pojawia się właśnie problem z trudnością zamykania zadań. 

3. Zdefiniuj swój proces pracy i zadbaj o płynność jego przepływu. 

Spotykamy się też z sytuacją, w której zespół ma problem z kończeniem pracy, ponieważ nie do końca panuje nad swoim procesem. W tym procesie są jakieś przestoje i niejasności, brak w nim płynności pracy i dążenia do kończenia zadań. 

W praktyce chodzi tu o to, żeby, tak całościowo spojrzeć na to, jak wygląda nasz proces pracy w zespole. Zwróćcie uwagę, czy są w nim jakieś momenty, gdy pojawiają się spowolnienia lub praca całkowicie utyka w jednym punkcie. Co robicie w takich sytuacjach? Czy podejmujecie decyzje, aby zająć się czymś, zamiast spróbować zawalczyć o to, żeby ten proces trochę upłynnić? 

Bardzo pomocne w procesie definiowania procesu pracy i wyłapywania problematycznych momentów są wszelkiego rodzaju formy wizualizacji. Dzięki temu dostajemy dodatkową, taką bonusową warstwę, z której możemy skorzystać i zobaczyć pewne rzeczy, które normalnie pewnie by nam umknęły. 

4. Kończ otwarte zadania. 

W tym punkcie zachęcamy do tego, żeby spojrzeć z lotu ptaka na to, czym się aktualnie zajmujemy i próba oceny co jestem w stanie skończyć najszybciej i zmniejszyć liczbę pootwieranych zadań. 

Warto wypracować sobie, najlepiej w ramach całego zespołu, taki nawyk domykania tematów. Bo sztuką nie jest mieć przez cały Sprint mnóstwo pootwieranych zadań i rozproszenie uwagi pomiędzy nie, a dopiero pod koniec Sprintu dopychanie ich do końca. Sztuką jest taki flow pracy, aby mieć jak najmniej na głowie, nie musieć przełączać się pomiędzy zadaniami i skupienie się na jednym temacie.

Przykładowo, na planowaniu Sprintu możemy zacząć od zaplanowania wykonania tych zadań, które nie zostały ukończone w poprzednim Sprincie czy w poprzedniej iteracji, zanim zaczniemy planować pracę nowych tematów. Zwiększa to szanse, że te rozgrzebane już prace, zostaną dokończone. Możemy też zmienić formę naszych Stand-upy czy Daily z tego najbardziej popularnego, gdzie pojedyncze osoby z zespołu opowiadają, czym się zajmowały wczoraj, co będą robić dzisiaj, na iterowanie się po zadaniach, które są najbliżej końca. Tutaj dobrym pomysłem jest wyświetlenie w sposób graficzny flow pracy, którą mamy. Dzięki temu przechodzimy z takiego myślenia, co robią osoby w zespole, na myślenie, które zadanie jest najbliżej końca i które zadania możemy zakończyć najszybciej.

5. Wspieraj innych w kończeniu zadań. 

W kończeniu otwartych zadań możemy pójść o krok dalej i zamiast rozpoczynać nowe zadanie, sprawdzamy, czy ktoś z zespołu nie potrzebuje pomocy w domknięciu ich tematów. 

Dzięki takiemu podejściu niwelujemy sytuacje, w których jedna osoba w zespole jest absolutnie utopiona w zadaniach, a inne mają wolne przebiegi i zaczynają kombinować, szukać zadań do zrobienia, być może wyprzedzać w ogóle Sprint. 

Bardzo pomocne będzie tu ustalenie w zespole takich zasad. Czyli określenie co się dzieje, jak skończę swoją pracę. No i taką dobrą praktyką do przetestowania jest podejście, że kiedy kończę swoją pracę, to zaczynam od sprawdzenia, czy ktoś nie potrzebuje pomocy, żeby jakieś konkretne zadanie dokończyć. I dopiero kiedy upewniam się, że nie mam komu pomóc się odblokować, to dopiero wtedy patrzę na tę listę zadań, które sobie na konkretne iteracje czy Sprinty wybraliśmy. 

6. Ograniczaj ilość jednocześnie wykonywanej pracy. 

Intencją tej porady jest to, żeby bardzo świadomie podejść do obserwacji tego, ile faktycznie wykonujemy pracy w danym momencie. 

Możemy to zrobić na różne sposoby. Przykładowo ustalamy, że jedna osoba nie zajmuje się więcej niż dwoma tematami na raz. Albo podchodzimy do tego na poziomie zespołu i umawiamy się, że w procesie developmentu nie znajduje się więcej niż X zadań jednocześnie. Takie ustalenia pozwalają na płynne sterowanie tymi limitami i dobieranie ich w zależności od potrzeb

W takim limicie ważne jest, aby zespół rozumiał, po co w ogóle jest to limitowanie i co możemy zrobić, jeśli zacznie nam ono w którymś momencie przeszkadzać. Czyli jak zareagujemy, jeśli na przykład te limity właśnie osiągniemy, czy nawet je przekroczymy. Tu wracamy do poprzednich porad odnośnie di wzajemnego pomagania sobie w pracy w ramach zespołu zamiast otwierania nowych tematów. 

7. Mierz przepustowość procesu. 

Wśród zespołów istnieje przekonanie, że jeśli mają dużo zadań rozpoczętych w jednym czasie, to są wydajne i efektywne. Mają poczucie, że dzięki temu są dobrymi pracownikami, bo nie mają ani chwili przestoju. To jest niestety błędne przekonanie. To jest patrzenie z perspektywy zajętości indywidualnej jednostki, a nie z perspektywy całego procesu.  

Zespół powinien zdefiniować sobie, co jest dla nich efektywnością procesu i jak w toku różnych eksperymentów podsumować efekty poprzez obiektywne miary

Na przykład ile ticketów udało się im zamknąć w danym okresie czasu lub ile feature’ów wdrożono. To będzie obiektywną podstawą do rozmowy o tym, czy to faktycznie dobrze, aby jedna osoba miała jednocześnie otwartych kilka tematów. Subiektywnie ta osoba, która jest bardzo zajęta, może nie widzieć tego, że to wcale nie jest optymalne, stąd dobrze mieć miary, które  pozwolą o tym na spokojnie podyskutować. 

Z doświadczenia wiemy, że im bardziej zawalony robotą zespół, im więcej bierze na iteracje, to okazuje się, że w zasadzie ta przepustowość jest mikroskopijna. Tylko ułamek tego, co zostało wzięte na przykład na Sprint, jest faktycznie kończone. Zespół wziął np. 80 Story Point’ów, z czego tylko dwadzieścia skończonych, a cała reszta ciągle się przewala między Sprintami i zespół nie umie spojrzeć na to obiektywnie. A przecież lepiej byłoby wziąć 20 Story Point’ów i skończyć je. Nie warto oszukiwać się, że jak więcej weźmiemy, to więcej skończymy, zwłaszcza jeśli nie mierzymy tego. Nie możemy wtedy sobie podsumować, że wcale nie jest tak, że kończymy więcej. Kończymy malutką ilość z tego, co na siebie wzięliśmy.

Jak kończyć rozpoczętą pracę – rady dla managerów i liderów

Powyższe 7 porad kierujemy do zespołów. Teraz podzielimy się 3 poradami dla managerów i liderów jak wesprzeć zespół w procesie kończenia pracy, a nie rozpoczynania nowych wątków. 

1. Promuj zespołowe zachowania. 

Gdy wchodzimy w głębszą rozmowę z niektórymi zespołami, to dosyć szybko wychodzi, że branie dużej liczby zadań, i takie indywidualne zachowania, wynikają albo z kultury zarządzania firmą, albo zarządzania przez managera, gdzie premiowane są indywidualne zachowania, zamiast zachowań zespołowych. 

Dlatego zachęcamy managerów do doceniania i nagradzania pracy zespołowej i pomagania sobie, a nie traktowanie tego jako normy. Bo to wcale nie jest norma, a wyróżnienie Tomka, że pomógł Kasi domknąć zadanie, że w rezultacie zadanie jest zakończone i Interesariusze są zadowoleni, zwraca uwagę całemu zespołowi na to, że lepiej czasem pomóc innej osobie niż rozpoczynać kolejny temat. 

2. Optymalizuj system na kończenie pracy. 

Bardzo często spotykaną przez nas optymalizacją pracy zespołu jest optymalizacja na zajętość. Jest to szczególnie wyraźne na wszelkiego rodzaju sesjach planowania, gdzie próbujemy zapewnić, że osoby, które są zaangażowane w konkretną iterację, w konkretny Sprint, są po prostu zajęte i właściwie obłożone. I tu dostępność godzinowa, którą mamy na przykład dwa tygodnie, jest wykorzystana na sto procent. 

Myślenie w ten sposób powoduje, że automatycznie uruchamiają się mechanizmy pod tytułem, muszę bardzo dobrze wykorzystać swój czas pracy. Co często prowadzi do tego, że nie mam w ogóle żadnej wolnej przestrzeni na to, żeby pomóc komuś innemu. Na koniec z  perspektywy optymalizacji pojedynczej osoby, świetnie wykonana robota, ale jako zespół nie zamknęliśmy kilku zadań, bo pojedynczym osobom zabrakło godzin, żeby pewne rzeczy domknąć. 

Na to promowanie zajętości może wpływać np. trochę za duży nacisk na raportowanie czasu pracy albo robienie jakiegoś problemu ludziom, którzy mają jakieś chwilowe przestoje, albo robią coś spoza swojej ścisłej specjalizacji. Wpływ może mieć też jakaś silna presja na wyrobienie się ciągłe gonienie terminów. W ten sposób niestety manager, nawet nie mając tego w intencji, wywoła u ludzi duży multitasking i stworzy też system, w którym nie zwraca się uwagi na to, żeby kończyć, tylko przeć do przodu, niekoniecznie myśląc o tym, czy to jest w ogóle wydajne i co daje efekty.

3. Pomagaj zespołowi w zmianie sposobu myślenia. 

W zwinności zawsze bardzo bazujemy na tym, że zespół jest bardzo samodzielny. Rola lidera z kolei polega na obserwacji i wspieranie zmiany nieefektywnych nawyków. Może to się odbywać przez docenianie, bycie zdrowo rozumianym coachem dla swojego pracownika, czy dla całych swoich zespołów w tym, żeby przechodzili pewną drogę. Ciągle się w niej doskonali i również, no może po drodze też się trochę potykali. 

Brak takiej osoby, która ma przestrzeń na to, żeby się nad tym zastanowić i spojrzeć trochę z lotu ptaka, powoduje, że po prostu nawet pomimo dobrych chęci zespołu, ta taka potocznie nazywana bieżączka zalewa zespół. 

Mamy nadzieję, że nasz porady pomogą Wam pracować bardziej wydajnie i tworzyć zespół, w którym praca zespołowa jest codziennością i pomagacie sobie nawzajem zamiast skupiać się tylko na swoim poletku.

Jeśli masz dodatkowe pomysły i rady jak wdrożyć system kończenia zadań, zamiast rozpoczynania nowych, to podziel się nimi w komentarzu.

Dodatkowe materiały

Zachęcamy Cię do pogłębienia tego tematu i zapoznania się z dodatkowymi materiałami:

Warsztaty „Prawdziwe Przypadki Scrumowe”

Jeżeli interesuje Cię tematyka rozwiązywania problemów związanych konkretnie ze Scrumem, to zapraszamy na kolejną edycję warsztatów Prawdziwe Przypadki Scrumowe, które odbędą się 16 i 17 maja w Warszawie. Na to wydarzenie możesz się zapisać na stronie 202procent.pl/przypadki-scrumowe/. Są to warsztaty Kuby, oparte o case study’ies, konkretnych, prawdziwych, realnych zespołów, gdzie zespół mierzył się z jakąś bardzo życiową sprawą.

Dołącz do dyskusji o tym odcinku na naszych social mediach

Chcesz przeczytać transkrypcję naszej rozmowy w tym odcinku podcastu? Czytaj poniżej!

Jacek: W dzisiejszym odcinku porozmawiamy o kończeniu pracy. Odcinek ma swoją genezę w obserwacjach, które prowadzimy pracując z zespołami, gdzie bardzo częstym problemem, który wpływa na masę innych rzeczy, jest to, że zespół notorycznie rozpoczyna nową pracę, nie kończąc tego, co zaczął wcześniej.

Kuba: Podobny odcinek o zbyt wielkiej ilości pracy realizowanej jednocześnie, to był odcinek #067. „Mamy zbyt wiele projektów i co z tym zrobić?”. Natomiast tamten odcinek był mocno na poziomie wielu projektów w całej organizacji. Ten odcinek, który przed Tobą, będzie o perspektywie zespołu i perspektywie pracy indywidualnej, która się realizuje jednocześnie w ramach danego zespołu. 

Jacek: No dobrze. Kuba, to jaką miałbyś pierwszą radę dla zespołów, które mierzą się z problemem niekończenia rozpoczętej pracy?

Kuba: Pierwsza rzecz, która przychodzi do głowy, to taki etap już przed faktyczną pracą. Czyli jak podzielona jest praca. No i moja rada numer jeden to – Dziel pracę na mniejsze kawałki. Ten temat poruszył całkiem niedawno w odcinku 76. I tutaj on merytorycznie również do problemu zrównoleglenia dużej ilości pracy, różnej od siebie, też pasuje. Bo jedną z przyczyn problemu tego, że zespół czy pojedyncza osoba robi wiele rzeczy równolegle, może być to, że każda z tych rzeczy, która jest realizowana, jest za duża. Czyli ona długo trwa. Ktoś się na przykład niecierpliwi, każe zacząć nową pracę. Albo ta duża praca z jakiegoś powodu utyka. Może być wiele przyczyn, ale tutaj jakby przyczyną bazową jest to, że praca jest za duża i trzeba ją podzielić. Dzięki temu, że możemy podzielić ją na mniejsze kawałki, jest szansa, że będziemy też w krótszym czasie w stanie tę mniejszą porcję skończyć i zacząć pracę nad czymś innym. Nie będzie nam się tutaj tak jakby potęgowało czy multiplikowało. To problematyczne podejście, że duża praca, łatwość utyka, czy łatwo się zatyka, czy zrównolegla. 

Jacek: Problem tutaj też jest taki potencjalnie, że jeżeli rzeczy, które robimy, są duże, no to one potrafią trwać. Często jeśli pracujemy w sposób iteracyjny, nawet kilka iteracji, co uruchamia taki mechanizm. No dobra, to już trwa i trwa, ale nie możemy czekać z innymi rzeczami, więc to, co jest otwarte, no to w końcu zakończcie. Ale już rozpocznijmy prace nad kolejnym projektem, nad kolejną inicjatywą, nad kolejną funkcjonalnością. No i sytuacja, o której mówię, może się wydarzyć dwa, czy cztery razy, na takiej zasadzie, że zanim się zorientujemy, to kończymy z czterema dużymi trwającymi tematami. Wierząc w to, że już prawie skończyliśmy tamte, no a tak naprawdę dodajemy sobie tylko dodatkowej pracy. 

Jacek: Druga porada brzmi – Planuj jeden konkretny krok. Ta porada może przybrać wiele wariantów, w zależności od tego, jak organizujemy swoją pracę. Taki wariant, z którym spotykam się osobiście najczęściej, to jest sytuacja, w której zespół korzysta ze Scruma, czyli ma osobę, która odpowiada za pełnienie roli Product Ownera. No i ta osoba ma wpływ na to, czym się zajmuje zespół. Najczęściej wyraża to na planowaniu w postaci jakiegoś konkretnego celu. Natomiast bardzo często ten cel wcale nie jest pojedynczym celem i dochodzi do popularnego anty wzorca, tak zwanego wielocelu, czyli do zrobienia jest A i B i C i D. Tak więc zamiast jednego konkretnego celu, mamy kilka celów, albo zamiast jednej najważniejszej rzeczy, mamy kilka najważniejszych rzeczy. Co powoduje, że już na etapie planowania tak naprawdę, zamykamy sobie tę furtkę do tego, żeby się skupić i żeby zrobić jedną rzecz, ale porządnie, dobrze, do końca. No bo właściwie już na początku iteracji zgadzamy się, że będziemy robić kilka rzeczy naraz. 

Kuba: Istotą tej porady jest to, żeby skupiać się na konkretnej jednej rzeczy, konkretnym jednym celu, konkretnym jednym kroku, konkretnej jednej decyzji, jednym priorytecie. Możemy to nazywać, jak chcemy, ale chodzi o to, żeby uniknąć sytuacji, w której na przykład poprzez brak selekcji, brak umiejętności, może brak możliwości zdecydowania, co jest najważniejsze, realizowanych jest wiele strumieni, wiele nurtów. Próbujemy złapać wiele srok za ogon. I tak naprawdę nie za bardzo się to udaje lub niestety, ale jakby już na takim bardzo wczesnym etapie trwania danej inicjatywy, danego projektu, już jesteśmy automatycznie wciągnięci w sytuację pracy zrównoleglonej nad wieloma wątkami. I od razu automatycznie skazujemy się właśnie na ten kłopot z trudnością zamykania zadań. Ta przyczyna jest tutaj bardzo bazowa i na bardzo wczesnym etapie. 

Kuba: Trzecia porada, którą mamy to – Zdefiniuj swój proces pracy i zadbaj o płynność jego przepływu. Trochę już wychodząc z tematu zaczynania roboty, a bardziej patrząc na tę perspektywę powtarzających się kolejnych kroków, kolejnych iteracji, kolejnych jakichś etapów. Wiele zespołów ma problem z kończeniem pracy, ponieważ nie do końca panują nad swoim procesem. W tym procesie są jakieś przestoje, w tym procesie są jakieś niejasności. Może nieprzejrzystości lub tak jest to wszystko ułożone, że niekoniecznie zwraca się uwagę na to, czy następuje prawdziwe płynne dążenie do kończenia zadań. Więc tutaj w praktyce chodzi o to, żeby, czy to indywidualnie, czy przede wszystkim raczej zespołowo, tak całościowo spojrzeć na to, jak wygląda nasz proces pracy. Zgodzić się co do tego, jaki on jest i zwracać też uwagę, czy są takie jakieś momenty, gdy ta praca spowalnia, albo się w ogóle zatrzymuje. I tak bardzo obrazowo, czy czasami to nie jest ten moment, gdy praca utyka i wszyscy przyzwyczajeni już są do tego, że skoro zadanie się zablokowało na przykład na Code Review, no to ja sobie w tym czasie zacznę coś zupełnie innego. No bo przecież wiadomo, że Code Review musi zająć kilka dni. No niekoniecznie musi. I tu może być tak, że my jesteśmy przyzwyczajeni do niepłynnego procesu, zamiast spróbować zawalczyć o to, żeby ten proces trochę upłynnić. 

Jacek: I bardzo pomocne w procesie definiowania procesu pracy i też właśnie wyłapywania tego, co Kuba mówi, że widzimy, na jakim etapie co się dzieje, są oczywiście wszelkiego rodzaju formy wizualizacji. Czy to w formie narzędzia online, czy to w formie jakiejś tam fizycznej tablicy, gdzie zespół sobie tę pracę wizualizuje? Z mojej perspektywy, to wielokrotnie na pewno wspominałem już w naszych nagraniach, to zmienia grę. W sensie dostajemy dodatkową, taką bonusową warstwę, z której możemy korzystać. No, która jeśli jest dobrze zrealizowana, czyli faktycznie oddaje prawdę i wszyscy na to patrzymy, no to faktycznie pewne rzeczy, które normalnie by nam umknęły, nagle jesteśmy w stanie zobaczyć, wskazać palcem, przesunąć. I to zwykle przynosi bardzo pozytywne efekty. 

Jacek: Kolejną poradą, którą mamy, to porada, która brzmi – Kończ otwarte zadania. Brzmi bardzo prosto i wydaje się taka oczywista. No ale, jak wskazuje nasze doświadczenie, często jest pomijana. Czyli przykładowo, jeżeli mamy kilka otwartych zadań, no to możemy podjąć decyzję, żeby skończyć to, co możemy zakończyć najszybciej. Czyli generalnie zachęcamy do tego, żeby spojrzeć na to, jaki jest ten nasz stan pracy, którą się aktualnie zajmujemy i próba oceny, gdzie tak naprawdę w tym konkretnym momencie powinienem czy powinnam wsadzić ręce. Po to, żeby ta praca, która ma najbliżej do zakończenia, czyli na przykład zostały nam tylko testy, albo tylko jakaś tam inna drobna czynność, która oddziela nas od stwierdzenia, że to zostało zakończone i skupienia się na tym konkretnym działaniu.

Kuba: I chodzi też o to, żeby taką sobie wytworzyć kulturę, czy nawyk – zarówno osobiście, jak i też najlepiej również w ramach całego zespołu, że to nie jest wszystko jedno, czy ja zrobię skończenie już rozgrzebanego, czy może rozpocznę jakieś następne. Zwłaszcza w niektórych zespołach scrumowych widzę taką obojętność, że i tak wszystko razem musimy na koniec Sprintu zrobić. Po prostu dopchniemy pod koniec. I wychodzi ten efekt klifu. Czyli zespół przez cały Sprint miał mnóstwo rozgrzebanej pracy, a dopiero tuż na końcu Sprintu im się to zaczyna zamykać. Jeśli w ogóle. Ale nawet gdyby nie chodziło tylko o to, że wyrabiamy się na koniec Sprintu, po prostu miejmy nawyk domykania, kończenia, nieposiadania gdzieś tam w głowie, czy wręcz na głowie tylu jakichś wątków, które są gdzieś dzisiaj realizowane równolegle. Wątków, o których muszę pamiętać. Wątków, między którymi być może będę się przełączać. Więc tutaj jakby dodatkowym bonusem, czy dodatkową wartością samą w sobie – fakt, że będę mieć mniej na głowie. Będę o mniejszej ilości rzeczy musiał pamiętać, jeśli będę się skupiał na tym, żeby po prostu domykać, dopychać, kończyć, a nie rozpoczynać następne zadania. Lub jeśli mam kilka do dokończenia, to też tak troszkę jakby rozładowywał się, zaczynając od tego, co jest najprostsze do zamknięcia i nieposiadania zbyt wielu rzeczy w toku.

Jacek: I tak dając dwa konkretne przykłady, to na przykład na planowaniu możemy zacząć od zaplanowania wykonania tych zadań, które nie zostały ukończone w poprzednim Sprincie czy w poprzedniej iteracji, zanim zaczniemy planować pracę nowych tematów. Co zwiększa szanse, że te rozgrzebane już zostaną dokończone. Inny przykład, kiedy jakąkolwiek formę stan-up’ów mamy w zespole, no to też możemy zmienić orientację tego spotkania. Z tego najbardziej popularnego, gdzie pojedyncze osoby z zespołu opowiadają, czym się zajmowały wczoraj, co będą robić dzisiaj, zmienić na taką formę, gdzie raczej iterujemy się po zadaniach, które są najbliżej końca. I można to zrobić w łatwy sposób, między innymi wyświetlając w sposób graficzny, wizualny naszą tablicę, która zwykle odzwierciedla jakieś tam flow, które mamy. No i przechodzimy z takiego myślenia, co robią osoby w zespole, na myślenie, które zadanie jest najbliżej końca i na tym skupmy swoje wysiłki, żeby to zadanie po prostu jak najszybciej domknąć i zakończyć. 

Kuba: OK. Piąta porada, którą mamy to – wspieraj innych w kończeniu zadań. W poprzedniej radzie mówiliśmy o tym, żeby skupić się na kończeniu otwartych zadań, ale można też pójść dalej i jeśli mam do wyboru zacząć jakieś zadanie swoje, albo pomóc koledze, koleżance z zespołu, żeby oni domknęli swoje zadania, no to tutaj również wartością dodatkową, jakby na takim kolejnym poziomie całozespołowym jest, to żeby cały zespół zwracał wzajemnie uwagę sobie na to, czy jest coś, co mogę zrobić dla kolegi, koleżanki, żebyśmy wszyscy razem mieli jak najmniej otwartych zadań. I może mogę w czymś się odblokować, może mogę w czymś pomóc. Może mogę trochę wyjść zupełnie ze swojej roli, ale dzięki temu jako cały zespół, będziemy mieli mniej równoległych zadań. I mówię to, ponieważ tak jak Jacek zaczynał, że widzimy w zespołach różne postawy. Ja niestety za często, o wiele częściej, niż bym chciał, widzę sytuację, w której jedna osoba w zespole jest absolutnie utopiona z jakichś powodów w zadaniach, a inne mają wolne przebiegi. Zaczynają kombinować, szukać zadań, być może wyprzedzać w ogóle Sprint. No bo oni już swoje skończyli, to swoje takie mocno w takim negatywnym cudzysłowie. No to byłby moment świetny na odruchy zespołowe i wzajemną pomoc. 

Jacek: To, co tutaj jest bardzo pomocne, to ustalenie w zespole takich zasad. Na zasadzie, co się dzieje, jak skończę swoją pracę. Bardzo często obserwuję, że teamy nie mają żadnego takiego ustalenia, więc po prostu w zależności od konkretnej osoby, podejmowane są różne akcje. Czyli czasem ktoś bierze sobie kolejne zadanie, które jest na jakiejś tam liście, na przykład w Backlogu Sprintu. Czasem osoby biorą sobie to z jakiejś tam bardziej globalnej listy, na przykład z Backlogu Produktu. A czasem po prostu jakieś zadanie sobie wymyślają, wręcz do tego stopnia na zasadzie, że tam ktoś ma jakiś fajny task, który po prostu ma ochotę zrobić. Natomiast nie ma to nic wspólnego z pracą zespołową. Więc przykładowo taką dobrą zasadą do przetestowania jest, kiedy kończę swoją pracę, to zaczynam od sprawdzenia, czy ktoś nie potrzebuje pomocy, żeby jakieś konkretne zadanie dokończyć. I dopiero kiedy upewniam się, że nie mam komu pomóc się odblokować, no to dopiero zgodnie z jakąś tam sensowną umową, na przykład patrzę na tę listę zadań, którą sobie na konkretne iteracje czy Sprinty wybraliśmy. 

Kuba: Wspomniałeś o Daily, a to jest dokładnie jeszcze jedno mądre pytanie, które można sobie zadać lub ważny wątek, który na Daily można też poruszyć. Mam wolne przebiegi, kto potrzebuje pomocy, ewentualnie nawet z boku. Hej Maćku widzę, że już skończyłeś, Kasia jest jeszcze utopiona w zadaniach, może byście jakoś pracowali razem.

Jacek: Zakładając, że kultura organizacyjna pozwala powiedzieć – mam wolne przebiegi. Bo to wcale nie jest takie oczywiste. Przedostatnia porada, którą mamy brzmi – Ograniczaj ilość jednocześnie wykonywanej pracy. Jest to taka porada, której intencją jest to, żeby bardzo świadomie podejść do obserwacji tego, ile faktycznie wykonujemy pracy w danym momencie. Możemy do tego podejść na różne sposoby. Bo to zarówno może być takie ograniczenie, które nakładamy sobie na pojedyncze osoby w zespole. Czyli na przykład umowa, że nie zajmujemy się więcej niż dwoma tematami naraz. Ale to może być też umowa, którą zawieramy na bardzo konkretny etap w naszym procesie. Czyli przykładowo jednocześnie w procesie developmentu nie znajduje się więcej niż X zadań, albo nie testujemy więcej niż ileś tematów jednocześnie. Tak więc możemy sobie tymi umowami na te limity dosyć płynnie sterować i dobierać je w zależności od potrzeb.

Kuba: Ta umowa zespołowa może być też fajnie wsparta, jeśli korzystamy z jakiegoś narzędzia elektronicznego. Możemy sobie tam zaszyć jakiś taki limit, ustawić przypomnienie, a być może narzędzie nawet będzie tak skonfigurowane, że gdzieś da nam pewne ostrzeżenie, że wcześniej podjętej umowy jednak nie dopełniamy i tych zadań jest jednak więcej. No i przede wszystkim w takim limicie chodzi o to, żebyśmy jako zespół czuli, po co w ogóle chcemy to limitowanie i co zrobimy, jeśli to limitowane zacznie nam jakoś przeszkadzać. Czy nie będziemy tego dochowywać? Czyli jak zareagujemy, jeśli na przykład te limity właśnie osiągniemy, czy nawet przekroczymy. Żebyśmy też sobie wzajemnie właśnie pomagali, to co teraz mówimy, czyli to ograniczenie ilości jednocześnie wykonywanej pracy prawdopodobnie jest bardzo powiązane z wszystkimi dotychczasowymi poradami. Czyli jak tylko widzimy, że ten limit jest osiągnięty, że to ograniczenie jest dla nas wcześniej ustalone, jest przez nas przekroczane, no to może właśnie nie rozpoczynamy kolejnej pracy. Pomóżmy koledze, koleżance i szereg pozostałych punktów dotychczas wymienianych w odcinku. 

Kuba: I ostatnia porada taka bardzo, jak zwykle nas z poziomu usprawnienia i korygowania, to porada – Mierz przepustowość procesu. Wielokrotnie, gdy rozmawiam z zespołami na temat jednocześnie wykonywanej dużej ilości pracy, czasami pojawia mi się taki argument, że to, że robię dużo pracy zrównoleglonej to, że rozpoczynam dużo wątków, to jest wydajne, to jest efektywne. Dzięki temu jestem dobrym pracownikiem, bo przecież nie mam ani chwili przestoju. I to jest niestety bardzo wąskie myślenie. To jest myślenie taką perspektywą niekoniecznie pomierzenia całości procesu, tylko perspektywą zajęto się indywidualnej, albo nawet to jest tylko takie złudzenie, że to jest dobre dla całego procesu. No i tutaj dobrze byłoby, żeby cały zespół zdefiniował sobie, co tu jest w ogóle czymś optymalnym, co to jest dla nas efektywnością procesu i zwrócili sobie wzajemnie uwagę na to, że w toku różnych eksperymentów możemy też podsumować efekty poprzez obiektywne miary. Na przykład ile ticketów udało nam się zamknąć w danym okresie czasu, ile feature’ów, może velocity, jeśli korzystamy z jakiejś formy Story Pointów. Czyli wszystkie takie bardzo proste miary, które nam wprowadzą jednak obiektywny czynnik do tej rozmowy. Czy lepiej, że ja jestem indywidualnie zajęty, czy lepiej, że porozpoczynałem pięć wątków jednocześnie? Bo niestety subiektywnie ta osoba, która jest bardzo zajęta, może nie widzieć tego, że to wcale nie jest optymalne w jej oczach. Może to być optymalne, ale obiektywnie to optymalne nie będzie i dobrze mieć miary, które nam to wyciągną, pokażą i pozwolą o tym, tak bym powiedział, na spokojnie podyskutować. 

Jacek: I ta porada, myślę o tyle jest istotna, że bardzo często widzę różnice w zespołach. Czyli zespół pracuje w jakiś sposób, zwykle jest jakiś tam problem z tą ilością pracy w toku. Nie ma żadnych miar. Np i ta świadomość problemu jest powiedzmy, jakaś taka anegdotyczna. Ktoś tam coś wspomniał, ktoś tam coś powiedział. No ale tak na koniec dnia w sumie nie mierzymy, no więc trudno powiedzieć. W momencie, kiedy wprowadzamy przepustowość, w sensie miary przepustowości, nagle się okazuje, że mamy na myśli jakąś cyferkę. Robimy siedem feature’ów na iterację i to jest zupełnie jakby inna rozmowa, no bo to siedem, to tak średnio w sumie się koreluje z tymi naszymi odczuciami, no bo przecież tyle tematów otwartych, tyle robimy. No ale jakby tak uczciwie powiedzieć – dobra to ile skończyliśmy, no to ta liczba jest bardzo mała. Tak więc ja jestem dużym fanem tego, żeby jednak mierzyć, żeby mieć dane, żeby te dane były też takim kompasem dla zespołu, żeby były czymś, do czego możemy się odnieść i poddać wewnętrznie ocenie, jak my się w ogóle z tą cyferką czujemy.

Kuba: I tak się zaśmiałem, jak powiedziałeś o tym anegdotycznym odczuciu i ilości feature’ów, że teraz, jak sobie o tym pomyślałem, to im bardziej zawalony robotą zespół, im więcej bierze na iteracje, im więcej pojawia się argumentów, że my przecież tak dużo rzeczy musimy zrobić, nie ma szans, żebyśmy wzięli mniej. A później podliczamy, ile się udało zrealizować i jest właśnie taki przypadek, że w zasadzie ta przepustowość jest mikroskopijna. Tylko ułamek tego, co zostało wzięte na przykład na Sprint, jest faktycznie kończone. Jest to normą w tym zespole, ale za to wszyscy mają takie poczucie, że ile wzięliśmy. Wzięliśmy osiemdziesiąt Story Point’ów, z czego dwadzieścia skończone, a cała reszta ciągle się przewala między Sprintami i zespół nie umie tak stanąć w prawdzie. Weźmy może dwadzieścia Story Point’ów i skończmy, urealnijmy, że po prostu więcej nie jesteśmy w stanie aktualnie zrobić. Zastanówmy się, z czego to wynika, ale przede wszystkim nie oszukujmy się, że jak więcej weźmiemy, to więcej skończymy, bo to jest jeden z trudniejszych mitów do wyplenienia, jeśli nie mierzymy tego. No bo wtedy też nie możemy sobie podsumować, że wcale nie jest tak, że kończycie więcej. Kończycie malutką ilość z tego, co wzięliście

Jacek: Te porady, którymi się przed chwilą podzieliliśmy, to były takie porady na poziom zespołu, ale przygotowaliśmy też trzy porady dla managerów i liderów, na zasadzie jak z tej konkretnej pozycji, czy mając tę optykę, możesz wesprzeć zespół w procesie kończenia pracy, a nie rozpoczynania nowych wątków. 

Kuba: Pierwszą rzecz, którą byśmy poradzili managerów, to promuj zespołowe zachowania. Gdy wchodzimy w głębszą rozmowę z niektórymi zespołami, to dosyć szybko daje się ustalić, albo poprzez bezpośrednią rozmowę, albo raczej poprzez pośrednie relacje, że skłonność do pracy zrównoleglonej, branie dużej ilości zadań, też takie indywidualne zachowania wynikają z tego, że po prostu, czy to w ogóle w kulturze zarządzania całą firmą, czy konkretnie u tego konkretnego managera są ślady premiowania promowania indywidualnych zachowań, zamiast zachowań zespołowych. Więc tutaj będąc tak bardzo pozytywnym, zachęcam managerów do tego, żeby zwracali uwagę czy wystarczająco mocno doceniają, nagradzają, wyróżniają, czy po prostu traktują jako normę, której oczekują. To, że zespół pracuje zespołowo. To, że zespół wzajemnie sobie pomaga. To, że zespół dąży do tego, żeby być lepszym jako całość zespołu, a nie na nie zwraca uwagę na to, że ma bohaterów, ma tutaj niezastąpionych ekspertów. Póki tylko osobno o tym mówimy, to może mogą być nawet dobre przypadki. Tylko one mogą mieć też swoje negatywne konsekwencje. Na przykład właśnie w spiętrzaniu zadań, niepomaganiu sobie, czy braku skupienia na ukończeniu jako zespół. 

Jacek: I to promowanie może być tak proste, jak powiedzenie – Widziałem, że Tomek pomagał Kasi domknąć to zadanie. Fajnie, że nie brałeś nowego zadania. Fajnie, że pomogłeś. Zobaczcie, w rezultacie mamy to zamknięte, odhaczone. Interesariusze już to widzieli, już wyrazili swoje zdanie, są zadowoleni. Tak więc to nie musi być naprawdę nic skomplikowanego. To jest moim zdaniem kwestia obserwacji i po prostu komentowania rzeczywistości we właściwych momentach. Zwracania uwagi, nazywania pewnych rzeczy po imieniu. No bo jakby rozumiem, że zespół będąc w ciągu pracy, no może po prostu nie mieć optyki na to, żeby patrzeć na wszystko z lotu ptaka, z perspektywy całego procesu. No tylko jednak skupia się konkretnie na swojej pracy.

Jacek: Druga porada, którą mamy dla managerów brzmi – Optymalizuj system na kończenie pracy. Taką bardzo popularną optymalizacją, którą obserwuję, to jest optymalizacja na zajętość. Czyli w szczególności, to jest widoczne na wszelkiego rodzaju sesjach planowania, gdzie próbujemy zapewnić, że osoby, które są zaangażowane w konkretną iterację, w konkretny Sprint, są po prostu zajęte. Są właściwie obłożone. Ta dostępność godzinowa, którą mamy na na przykład dwa tygodnie, ona jest wykorzystana na sto procent. Problem z tym podejściem, w sensie rozumiem, dlaczego to robimy. Zdrowy rozsądek podpowiada, że skoro mamy X osób, no to chcemy te osoby wykorzystać, w sensie ich dostępność czasową w jak najlepszy sposób. Natomiast myślenie w ten sposób powoduje, że automatycznie uruchamiają się mechanizmy pod tytułem, muszę bardzo dobrze wykorzystać swój czas pracy. Co często prowadzi do tego, że nie mam w ogóle żadnej wolnej przestrzeni na to, żeby pomóc komuś innemu. Więc przykładowo jakieś Code Review czeka na zrobienie, no ale ja nie go nie ruszę, no bo na Planowaniu już sobie pod korek zapełniłem moją objętość, no, że na dzisiaj mam zaplanowane od rana do wieczora wykonywanie jakiejś innej pracy. Więc jakby z perspektywy optymalizacji pojedynczej osoby, świetnie wykonana robota. No, ale na koniec może się okazać, że zabrakło kilku godzin pojedynczych osób, żeby pewne rzeczy domknąć i wypchnąć z systemu jako zakończone.

Kuba: Ponieważ jesteśmy w sekcji porad dla managerów, to zwróćmy uwagę sobie, jeśli jesteśmy managerem lub współpracujemy z managerem, któremu chcemy na to zwrócić uwagę, to patrzmy na to, że to mogą być rzeczy bardzo takie niebezpośrednie. To promowanie zajętości, to może być na przykład trochę za duży nacisk na raportowanie czasu pracy, albo robienie jakiegoś problemu ludziom, którzy mają jakieś chwilowe przestoje, albo robią coś spoza swojej ścisłej specjalizacji. To może być też jakaś silna presja na wyrobienie się. Gonienie ciągle terminów, bo to wszystko może powodować, nawet jeśli nie to mamy w intencji, to wszystko może powodować jednak taką interpretację u ludzi, że OK, musimy się wyrobić, musimy być zajęci, musimy wykazać się indywidualnie. No i niestety te postawy będą takie, że właśnie manager nawet nie mając tego w intencji, ale wywoła u ludzi duży multitasking i wywoła też system, w którym nie zwraca się uwagi na to, żeby kończyć, żeby pracować w pewnych skończonych etapach, konkretnych dużych krokach. Tylko gdzieś tam prze się do przodu, niekoniecznie myśląc o tym, czy to jest w ogóle wydajne, a przede wszystkim, czy to daje efekty. Bo tutaj cała masa niekorzystnych zjawisk, opóźniamy feedback, wydłużamy jakieś cykle, gubimy też efektywność w takich bardzo mało widoczny sposób. 

Kuba: I ostatnia porada dla liderów i managerów zespołów to – Pomagaj zespołowi w zmianie sposobu myślenia. W zwinności zawsze bardzo bazujemy na tym, że zespół jest bardzo samodzielny i jeśli szereg porad na przykład z tego odcinka lub jakiś ciąg taki usprawniony powoduje, że zespół sam sobie wymyśla, że będzie na przykład limitował prace, będzie wizualizował swoje flow. No to jest spora szansa, że będą bardzo samodzielni w tym. Natomiast tutaj rolą lidera zespołu, rolą managera jakiegoś obszaru w firmie, może być też wspieranie zmiany nawyków. Zachęcanie ludzi do tego, żeby to robili. Docenianie za to, że właśnie przechodzą pewną ścieżkę. Bycie tutaj takim zdrowo rozumianym coachem dla swojego pracownika, czy dla całych swoich zespołów w tym, żeby przechodzili pewną drogę. Ciągle się w niej doskonali i również, no może po drodze też się trochę potykali. Może coś tam po drodze nie będzie wychodziło. Ale żeby być też taką osobą, która ze zrozumieniem do tego podejdzie. Jednak będzie wspierać w tym, żeby ta zmiana następowała.

Jacek: Ja bardzo często obserwuję właśnie to, że brak takiej osoby, która ma po prostu przestrzeń na to, żeby się nad tym zastanowić i spojrzeć, powoduje, że po prostu nawet pomimo dobrych chęci zespołu, ta taka potocznie nazywana bieżączka zalewa zespół. Choćbyśmy chcieli, choć te pomysły były fajne, no to jednak brakuje tego kogoś, kto by trochę nam pomógł w prowadzić te zmiany związane z kończeniem pracy w nasze codzienne flow. No i fajne pomysły, ale rzeczywistość powoduje, że tego nie robimy. Tak więc, w szczególności, jeśli jako manager czy lider dostrzegasz ten problem, o którym mówimy, no, to zdecydowanie warto poświęcić czas na to, żeby wesprzeć zespół w tej drodze, w tej przemianie, w tej zmianie sposobu patrzenia na wykonywaną pracę.

Jacek: Podsumowując. Jak skupić się na kończeniu zadań w zespole? 

Kuba: Dziel pracę na mniejsze kawałki. Planuj jeden konkretny krok. Zdefiniuj swój proces pracy i zadbaj o płynność jego przepływu. Kończ otwarte zadania.

Jacek: Wspieraj innych w kończeniu zadań. Ograniczaj ilość jednocześnie wykonywanej pracy. Mierz przepustowość procesu. Notatki do tego odcinka, za parę dni również artykuł, transkrypcję, a także zapis wideo, znajdziesz na naszej stronie porzadnyagile.pl/83

Kuba: 16. i 17. maja będę realizował kolejną grupę warsztatów Prawdziwe Przypadki Scrumowe, do których zapraszam również Ciebie. Będą to warsztaty oparte o case study’ies, konkretnych, prawdziwych, realnych zespołów, z którymi miałem do czynienia w przeszłości. Dobieram przypadki, w których zespół mierzył się z jakąś bardzo życiową sprawą. Czy to są problemy we współpracy z Product Ownerem, czy to jest opóźnienie w dostarczeniu rozwiązania, czy to jest jakiś konflikt w zespole? Szereg tego typu rzeczy, które są bardzo prawdziwe. Wiele osób na warsztatach zawsze mówi – Skąd wiesz? Ja też ten problem mam. No właśnie, tak się staram dobierać case’y, żeby one były właśnie takie dosyć popularne. Natomiast istotą tych warsztatów nie jest to, że ja przynoszę jakiegoś case’a, albo ja znam jego rozwiązanie. Tylko istotą tych warsztatów jest to, że zebrani Scrum Masterzy i Agile Coach’e z różnych firm, z różną perspektywą przepracowują te tematy. Dzielą się swoimi pomysłami. Najpierw zgłębiamy, z czego może to wynikać, a później rozmawiamy też, jak tego typu problemy można by rozwiązać. A tak naprawdę najczęściej, jak tego typu problem różne osoby zebrane na sali rozwiązują. Zapraszam do tych warsztatów. Przez najbliższych kilka tygodni będzie okazja do zapisania się po trochę niższej cenie. Później już będzie cena regularna. W kolejnych odcinkach jeszcze będę pewnie o tych zapisach przypominał. Można się zapisać na stronie 202procent.pl/przypadki-scrumowe 16., 17. maja w Warszawie, warsztaty stacjonarne.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. 

Jacek: I do usłyszenia wkrótce.

Daj nam znać co sądzisz o tym odcinku


Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Newsletter „Porządny Agile”

.

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial