czy Agile to tylko spotkania

„Agile to za dużo spotkań”

Często przy okazji pracy zwinnej można usłyszeć ze strony zespołu zarzut, że praca tym podejściem wiąże się z dużą liczbą spotkań. Dobrze wyedukowany Scrum Master natychmiast odbije piłeczkę argumentem o timeboxie – czyli maksymalnym procencie czasu na te spotkania (10% czasu Sprintu na Wydarzenia Scrumowe i ewentualne (kiedyś wspominane w Przewodniku po Scrumie) kolejne max. 10% czasu na procesy związane z Doskonaleniem Backlogu Produktu (Refinementem), które wielokrotnie również oznaczają spotkania zespołowe). Czym jest 20% spotkań względem 80% czasu pracy w Sprincie? Niestety prosta relacja matematyczna może nie oddawać istoty sprawy – spotkania mogą być nużące, nie wnosić wartości i być ułożone w tak nieszczęśliwy sposób w kalendarzu tygodnia, że znacznie zaburzają możliwość pracy w dłuższych okresach skupienia. O tym ostatnim zagrożeniu będzie niniejszy artykuł.

Wyobraźmy sobie Zespół Scrumowy, którego kalendarz tygodniowy wygląda następująco:

Reklama



  • Zespół zaczyna Planowanie Sprintu o godzinie 10:00, ponieważ Właściciel Produktu nie ma możliwości spotkać się z zespołem wcześniej.
  • Codzienny Scrum odbywa się od wtorku do piątku o 9:00.
  • Zespół realizuje Doskonalenia Backlogu Produktu w postaci sesji wspólnej pracy warsztatowej we wtorki i czwartki od 13:30 do 15:00
  • Przegląd Sprintu, z uwagi na małą dostępność Bardzo Ważnego Interesariusza, odbywa się w piątki o 11:00, a Retrospektywa zaczyna się o 13:30 (zaraz po lunchu niestety nie udało się zorganizować odpowiednio pojemnej sali).
  • Dla uproszczenia przyjmijmy też, że wszyscy Deweloperzy pracują w tych samych godzinach – od 8 do 16, oraz że w środku dnia robią sobie w tym samym momencie dłuższą przerwę obiadową.

Sumarycznie wyżej wskazany zespół spędza na spotkaniach związanych ze stosowaniem zasad Scruma 8 godzin roboczych, czyli mieści się we wspomnianych wyżej przeze mnie sugestiach, by spotkania nie przekroczyły 20% pojemności Sprintu. Jednocześnie jestem gotów założyć się o całkiem sporą kwotę, że członkowie takiego Zespołu Scrumowego będą bardzo głośno narzekać na spotkania. Dlaczego? 

Przyjmijmy też następujące założenie – po każdym przerwaniu (np. z powodu spotkania), do pracy kreatywnej potrzebne jest 15 minut “rozgrzewki”, by uzyskać skupienie, przypomnieć sobie dotychczasowe ustalenie, odświeżyć szkic projektu, który miał zrealizowany itd. Każdy pracownik kreatywny będzie miał swój własny czas potrzebny do uzyskania takiego skupienia (może to być zależne od warunków pracy, osobistych umiejętności wyciszenia się, entuzjazmu związanego z realizowanym zadaniem, brakiem innych przeszkadzaczy, wielkości i stopnia skomplikowania zadania), ale szczerze wątpię, by był on krótszy niż wspomniany kwadrans.

Jeśli naniesiemy taki czas “rozgrzewki” na wcześniejszy kalendarz spotkań, obraz dostępnych okienek na pracę zaczyna się nagle zmniejszać. Niejednokrotnie zespoły zajmują się rozwiązaniami innowacyjnymi, wymagającymi kreatywności i poszukiwania w skupieniu rozwiązania, co wymaga czasu. Dlatego pod poważnym znakiem zapytania postawiłbym przydatność odcinków krótszych niż godzina nieprzerwanej pracy.

Przy i tak bardzo ostrożnych założeniach (15 minut startu po przerwie, minimum 1 godzina skupienia) wspomniany zespół ma potencjalnie w trakcie tygodnia wyłącznie 15 godzin na pracę.

Jeśli dla tego samego zespołu przyjmiemy założenie, że “rozgrzewka” po przerwie zajmuje jednak pół godziny, a wytworzenie kolejnego kawałka kreatywnego rozwiązania wymaga minimum 2 godzin nieprzerwanej pracy – zespół ma dyspozycji w całym tygodniu tylko ok. 12 godzin.

Kalendarz twórcy i kalendarz menedżera

Paul Graham z Y Combinator w swoim artykule z 2009 roku zwrócił uwagę na to, że w firmach technologicznych zauważa dwa typy podejścia planowania czasu – kalendarz twórcy (w oryginale “maker”) i menedżera. Typowy kalendarz menedżera napakowany jest dużą liczbą spotkań, gęsto zaplanowanych od rana do popołudnia co pół godziny, a jeśli zdarzy się między nimi jakaś przerwa, wspomniany menedżer zrealizuje szereg drobnych zadań typu: krótki telefon, odpowiedzi na maila, wyciągnięcie danych z raportu itd. Praca twórcy wymaga o wiele więcej skupienia – podejmuje on zadania, które wymagają nieprzerwanego poświęcenia się pracy, dużego czasu na “rozkręcenie się” i również sporego czasu, by w całości zrealizować wymyśloną koncepcję. Przerwanie twórcy pracy w trakcie jest bardzo kosztowne – póki nie skończył swojego zadania, ryzykuje, że część jego wymyślonej koncepcji ucieknie albo co najmniej będzie czasochłonne (i denerwujące), żeby od nowa przejść ten sam proces myślowy i odtworzyć tą samą myśl.

Jeśli zgodzimy się, że taka rozróżnienie typów pracy jest trafne, jasne jest dlaczego Właściciel Produktu czy Scrum Master nie widzą aż tak wielkiego problemu z ułożeniem kalendarza z przykładu z początku artykułu, a równocześnie Deweloperzy (czyli specjaliści z takich profesji jak np. programiści, analitycy, testerzy, projektanci) będą sygnalizowali kompletny brak czasu na pracę. Ci pierwsi mogą działać w przyzwyczajeniu do kalendarza menedżera, Ci drudzy bez wątpienia funkcjonują według kalendarza twórcy.

Swego czasu usłyszałem poradę, by dzień roboczy w zespole kreatywnym dzielić na maksymalnie dwie części: “przed lunchem” i “po lunchu”. Jeśli musimy organizować spotkania z kimś z zespołu twórców, dążmy do planowania tych spotkań na skraju takich “półdniówek” – czyli od rana, tuż przed lunchem, tuż po lunchu albo na sam koniec dnia roboczego. Spotkanie, które zostanie zorganizowane w środku bloku “po lunchu” może oznaczać, że całe pół dnia nie będzie mogło już być poświęcone na skupioną pracę.

Jak Zespół Scrumowy może zadbać o swoje skupienie?

Zespół Scrumowy z przykładu, bez zmiany długości spotkań, a tylko po ich poprzesuwaniu z uwzględnieniem koncepcji kalendarza twórcy, uzyskałby następujący plan:

Przy założeniu, że rozgrzewka wymaga 15 minut, ten zespół ma ok. 26 godzin w tygodniu na pracę w skupieniu, a przy rozgrzewce 30 minutowej (i konieczności spędzenia 2 godzin minimum) – 18 godzin. 

Koncepcję kalendarza twórcy może wziąć sobie do serca również sam Zespół Scrumowy w trakcie planowania pracy na cały Sprint oraz w trakcie synchronizacji i aktualizacji planu pracy na Codziennych Scrumach. Przede wszystkim nie planujmy sobie pracy w takim stylu, który oznacza dużą ilość przerwań okresów skupienia i wykorzystujmy do maksimum istniejące rutyny zespołu (pytania, które mogą poczekać, zadajmy na następnym Daily albo w komunikacji asynchronicznej, zaplanujmy koordynację i współpracę, by nie zaskakiwać swoimi problemami kolegę z zespołu w środku dnia). Wiele doświadczonych zespołów, jakie widziałem, wprowadza sobie dodatkowe wewnętrzne reguły funkcjonowania, które wpływają na ich skupienie – stosują Pomodoro, wyznaczają sobie godziny pracy w skupieniu albo wyznaczają “dyżurnego”, który zajmuje się komunikacją między zespołem a światem zewnętrznym (np. zleceniami utrzymaniowymi), by pozostali członkowie nie musieli się odrywać od swoich zadań.

Zachęcam do refleksji wszystkie Zespoły Scrumowe i eksperymentowania, czy zmiana układu spotkań w zestawieniu z koncepcją kalendarza twórcy wpłynie na poprawę poczucia efektywności naszej pracy. Oczywiście wpływ na złą ocenę spotkań w zespole może mieć też ich niedoskonały przebieg – w takiej sytuacji polecam serię artykułów o antywzorcach Wydarzeń Scrumowych albo podpowiedzi na temat praktyk, które usprawniają przebieg Planowania Sprintu.

PS. Zapraszam Cię też do posłuchania 49. odcinka podcastu Porządny Agile, którego tematem jest Facylitacja spotkań.

Źródło zdjęcia: Priscilla Du Preez – Unsplash

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x