Nadgodziny to drażliwy temat, ale gdy dodamy do tego jeszcze metodykę Scrum, to robi się wręcz kontrowersyjny.
Nadgodziny w metodykach zwinnych
Wielu osobom wydaje się, że metodykę agile wprowadzamy po to, żeby pracować szybciej i wydajniej. Gdy tak się nie dzieje, pojawiają się pretensje. Z tematem tego czy Scrum jest drogi już się rozprawialiśmy, ale przypomnijmy najważniejsze obietnice agile’owego podejścia.
„Our highest priority is to satisfy the customer (…)” – Agile Manifesto
Metodyki zwinne i „cały ten agile” są nakierowane na podniesienie satysfakcji naszego odbiorcy. Przyświeca temu założenie, że zadowoleni mogą być wszyscy – klient, odbiorcy, sponsorzy, wykonawca, a także ludzie te oprogramowanie tworzący. Nawet, jeśli to brzmi trochę jak utopia, to jak pokazuje praktyka, takie podejście w długim okresie sprawdza się po prostu lepiej.
Chcemy pracować tą samą grupą ludzi, która już jest dobrze zgrana oraz nie tylko rozumie potrzeby i wymagania, ale też jest w stanie reagować tak szybko, jak się tylko da. Nie chcemy z każdym nowym pomysłem wdrażać ludzi z rynku, ani od podstaw budować zespołów roboczych. Żeby tego uniknąć potrzebujemy pracowników, którzy nie są wypaleni ani zamęczeni nadgodzinami.
„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” – Agile Manifesto
Metodyki zwinne promują zrównoważone tempo. Takie, które jest możliwe do utrzymania „w nieskończoność” przez wszystkich – zarówno sponsorów, jak i deweloperów czy użytkowników. Lepiej jest działać na 80% mocy przez całe lata, niż na 120% przez pół roku, tylko po to, żeby potem borykać się z brakami kadrowymi czy niską jakością wytworzonych rozwiązań.
Nie oszukujmy się, zrywy wydajności spowodowane nadgodzinami zawsze zbierają swoje żniwo – czy to w odpływie pracowników, czy to w długu technologicznym, który kiedyś do nas wróci i będzie domagał się naszej uwagi.
Efektywność Scrum
Scrum jest metodyką zwinną. Co do tego nie ma żadnych wątpliwości. To sugeruje też, że nasze znane i lubiane podejście powinno wspierać zrównoważone tempo pracy. Sprawdźmy, co na ten temat mówi Scrum Guide.
„Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.” – Scrum Guide
Scrum zakłada przewidywalność. Jeśli chcemy być przewidywalni i potrafić oszacować terminy realizacji wymagań, to nie ma dla nas innego wyjścia niż zrównoważone tempo. Dlatego właśnie Sprinty są stałej długości, dlatego podkreślany jest stały skład zespołów. Zmiany zaburzają przewidywalność.
Wspomniana powyżej „przynajmniej jedna okazja do inspekcji i adaptacji” to Sprint Review. To właśnie tam Product Owner dowiaduje się o stanie realizacji poszczególnych wymagań, dzięki czemu potrafi zaplanować terminy dostarczenia poszczególnych rozwiązań. Oczywiście w praktyce zwykle dzieje się to o wiele częściej niż raz na Sprint.
„The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed)” – Scrum Guide
Żeby Product Owner był w stanie określić, kiedy dostarczymy poszczególne wymagania, to musi wiedzieć, w jakim tempie zespoły je realizują. To tempo musi być w miarę stałe, bo inaczej planowanie staje się niemożliwe.
PO, który oszacuje termin zrealizowania jakiejś funkcjonalności w formie MVP na „od 4 do 9 miesięcy” raczej nie zostanie potraktowany poważnie.
Nadgodziny w sprincie
Jeśli chodzi o zaburzanie transparentności, to prawdziwą plagą są zrywy wydajności pod koniec Sprintu, realizowane w formie nadgodzin.
Bardzo często to zespoły same zostają w nadgodzinach, żeby „dowieźć Sprint”. Działają tym samym na szkodę swoją i całego projektu. Powody są dokładnie takie same, jak zawsze: robienie czegoś „rzutem na taśmę” praktycznie gwarantuje niższą jakość, a zostawanie w nadgodzinach co Sprint powoduje zmniejszenie zadowolenia Zespołu Deweloperskiego.
Ponadto, w ten sposób zespół efektywnie zaciemnia obraz swojej wydajności. Jeżeli dzięki nadgodzinom i obniżeniu jakości udaje mu się dostarczyć o 20% więcej wymagań niż zwykle, to z czasem nikt nie będzie pamiętał o nadgodzinach. Wszyscy, włącznie z PO i samym zespołem, będą oczekiwali takiej, a nie innej wydajności.
Jakie jest rozwiązanie tej sytuacji? Zespół powinien po prostu pozostawić nadmiarowe wymagania niezrealizowane. To powinno z kolei wywołać dyskusję na Sprint Retrospective, a kolejne planowanie powinno już być bardziej realistyczne. Lepiej jest raz czy dwa pokazać, że zespół planuje się zbyt optymistycznie niż brnąć w nadgodziny, błędy i frustrację.
Jawne pokazanie sytuacji pozwoli na dostrzeżenie prawdziwego stanu projektu i być może spowoduje rozszerzenie go o kolejne zespoły bądź zmniejszenie zakresu. Ani jedno, ani drugie nie będzie możliwe, jeśli zespoły będą ukrywać nierealne oczekiwania pod płaszczykiem nadgodzin i niskiej jakości.
Tak jak nie widzę miejsca dla stałych, powtarzalnych nadgodzin w żadnej pracy, tak tym bardziej nie widzę ich w Scrumie czy innych metodykach zwinnych. Po to jesteśmy „zwinni”, żeby wszyscy byli zadowoleni. Permanentne nadgodziny i związane z nimi wypalenie, niska jakość i brak przewidywalności nie służy nikomu.
