Czy wypalenie może się zdarzyć podczas ciągłego wykonywania sprintów Scrumowych? [Zamknięte]

Mam dość mały startup i zaczęliśmy używać formy cyklu rozwojowego Scrum / Agile.

Pod wieloma względami lubię Scrum. Mamy stosunkowo krótkie sprinty (2 tygodnie) i podoba mi się wykres spalania, aby śledzić postępy zespołu. Podoba mi się też tablica funkcji, więc zawsze wiem, co powinienem robić dalej. Dobrze jest zdjąć kartę funkcji z planszy, ukończyć ją, a następnie odłożyć na stos spalonych.

Jednak wchodzimy teraz w nasz 18. cykl wydawniczy Sprint i zaczynam czuć się trochę wypalony. Nie chodzi o to, że nie lubię pracy ani współpracowników, po prostu te sprinty to ... cóż, sprinty . Od początku do końca dosłownie czuję, że ścigam się z czasem, aby utrzymać tempo rozwoju. Kiedy kończymy sprint, spędzamy jeden dzień na planowaniu zestawu funkcji i szacunków dla następnego sprintu, a następnie ruszamy ponownie.

Czy to normalne dla osób, które pracują w dojrzałym procesie rozwoju Agile / Scrum? A może czegoś brakuje? Czy normalnie jest czas w środowisku Scruma, które jest nieprzypisane / nieśledzone, aby zrobić kilka drobnych rzeczy i oczyścić głowę?

Jest to stosunkowo normalne i czasami może być narzekaniem członków naszego zespołu, jeśli projekty są kontynuowane przez długi czas.

Kluczem do tego, o czym tutaj mówimy, jest zrównoważone tempo . Jeśli ty i twój zespół jesteście w stanie utrzymać swoje tempo w dłuższej perspektywie, to świetnie - osiągnęliście hiperproduktywność, do której dążą wszystkie zespoły Scrumowe.

Ewentualnie, jeśli okaże się, że przeceniasz, ile pracy możesz wykonać w ciągu jednego dnia, być może będziesz musiał ponownie ocenić to podczas retrospektywy. Ilość produktywnego czasu w ciągu dnia, którą zespół decyduje się uwzględnić podczas planowania zdolności do sprintu, jest określana jako czynnik skupienia .

Henrik Kniberg ma do powiedzenia:

„Domyślny” współczynnik skupienia, którego używam dla nowych drużyn, to zwykle 70%, ponieważ to jest miejsce, w którym większość naszych pozostałych drużyn kończy się z czasem.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Jednak to, o czym mówisz, to po prostu nieprzerwany rozpęd sprintu za sprintem, niekoniecznie Twoja dzienna produktywność. Oto kilka sugestii rzeczy, z którymi próbowaliśmy sobie poradzić:

• Zakończ sprint w piątek rano. Rano przeprowadź przegląd sprintu i retrospektywę, a resztę dnia pozwól zespołowi pracować nad czymś innym, aby oczyścić głowy. Odbierz z planowaniem sprintu w poniedziałek.
• Wprowadziliśmy pojęcie „dni laboratoryjnych”. To są całe dni, kiedy zespół zostaje zabrany z projektu i spędza dzień pracując nad doskonaleniem własnych umiejętności technicznych poprzez wspólne badania i współpracę nad określonymi tematami technicznymi. W większości przypadków nie mają one absolutnie nic wspólnego z konkretnym projektem i pozwalają członkom zespołu myśleć o lżejszych tematach.

Z Wikipedii na temat wypalenia zawodowego: „wypalenie jest w dużej mierze problemem organizacyjnym spowodowanym długimi godzinami pracy, krótkimi przestojami i ciągłym nadzorem rówieśników, klientów i doskonałego nadzoru”

Równie dobrze mogą mieć obraz ikony Scruma obok definicji wypalenia.

Jeśli myślisz, że możesz wysłać kogoś na coś innego na krótką rozrywkę w celu naprawienia wypalenia, oczywiście nie przemyślałeś tego. Kiedykolwiek wyjeżdżasz na wakacje po wypaleniu i wracasz do pracy, myśląc: Wow! Teraz jestem odświeżony i gotowy na kolejne 6 miesięcy tej tortury, aż w końcu znów mam przerwę. Nie, zdajesz sobie sprawę, wow! Moja praca jest do dupy. Teraz naprawdę widzę, jak mikro-zarządzanie, proces rozwoju mojego głupiego menedżera to kolejny sposób na wyciągnięcie ze mnie więcej za mniej, a życie jest na to za krótkie ... Powinienem znaleźć coś innego do zrobienia lub zmienić pracę na mniej stresującą .

IMHO, krótkie 2 tygodnie Scrum powinno być zabronione, z wyjątkiem małych dawek, nie więcej niż 4-8 z rzędu. Używaj go jako narzędzia do wyjątkowych lub krytycznych rzeczy, a nie ciągle. Użyj rozumu.

Stajesz się zmęczony po 36 tygodniach ciężkiej pracy; to nie Scrum, taka jest ludzka natura! Scrum nie jest po to, aby zmusić Cię do cięższej pracy, jest po to, aby pomóc Ci pracować bardziej konsekwentnie i z większą przewidywalnością. Często widzę ludzi mylących symptomy normalnego zarządzania projektami z tym, co postrzegają jako symptomy zwinnych metodologii (tj. „Klient ciągle zmienia wymagania - to musi być wina Scruma!”). Jest to jednak ważne rozróżnienie, ponieważ bez zidentyfikowania przyczyny nie można leczyć objawów. Osobiście szukałbym sposobów na zmniejszenie wypalenia, takich jak techniki radzenia sobie ze stresem. Jest mnóstwo informacji na temat tego, jak odnieść sukces w stresującym środowisku.

Zespół, nad którym obecnie pracuję, bardzo ładnie rozwiązuje ten problem. Po trzech sprintach mamy tydzień, w którym każdy programista może pracować nad tym, czego chce. Te poboczne projekty powinny być powiązane z wartością biznesową, ale nie ma presji, aby to zrobić. Jest to środek, który pozwala nam programistom odkrywać nowe technologie, ale zapewnia nam również tydzień bardziej zrelaksowanej i przyjemnej pracy.

To na pewno pomaga mi się nie wypalić.

Bez względu na to, jakiego procesu rozwoju używasz, jeśli zespół się wypala, coś jest nie tak. Może to być tak proste, jak ludzie, którzy nie biorą urlopu, którego potrzebują, lub może tkwić w szczegółach, jak radzisz sobie ze swoimi scrumami. Zespoły są skuteczne przez długi czas, ponieważ po drodze każdy otrzymuje resztę, której potrzebuje.

Sprint to nie bieg na 100 jardów; jest to jedna (przypadkowa) mila w maratonie, czyli tempo, które możesz utrzymywać w nieskończoność.

Czy Twój Zespół przeprowadza retrospektywy na koniec każdego Sprintu? Czy jest to okazja Zespołu do „sprawdzenia i dostosowania” swojego procesu? Jako ScrumMaster regularnie proszę Zespół, aby ocenił, jak Zespół jako jednostka „czuje się” i czy dobrze się bawi. Badamy, dlaczego lub dlaczego nie, i eksperymentujemy z dostosowaniami i alternatywami.

Z mojego doświadczenia wynika, że ​​członkowie zespołu cieszą się (do pewnego stopnia) „presją”, którą ogranicza czas Sprintu. Kluczem jest podejście, ale nie przekraczanie tej strefy. W razie potrzeby kalibracja tej strefy jest głównym punktem kontrolnym w retrospekcji.

Jeśli chodzi o "... czas w środowisku Scrum, które jest nieprzypisane / nieśledzone, aby wykonać drobne rzeczy i oczyścić głowę", utrzymywanie zaangażowania Zespołu na poziomie x% dostępnej pojemności (najlepiej punktów, ale można wykorzystać godziny w razie potrzeby; w każdym przypadku znalazłem coś w zakresie 60-70% wydaje się normą) jest kluczem do zrównoważonego rozwoju w Sprincie, a okazjonalny „dzień wolnego kodu” sprawdza się dobrze w przypadku Sprintów zewnętrznych.

Jednym z rozwiązań jest zmniejszenie liczby godzin w ciągu dnia spędzanych na sprincie.

Znam ludzi, których dzień pracy składał się z zaledwie dwóch i pół godziny sprintu, a reszta dnia była skupiona na różnych innych czynnościach: wsparcie, spłacanie długów technicznych, badania itp. Odpowiednio ustalono ich tempo rozwoju.

Może się to wydawać trochę ekstremalne, ale jeśli się nie mylę, była to rentowna firma, dopóki nie nastąpił niedawny powszechny szok gospodarczy.

Jesteś w swoim 18. sprincie !?

Biorąc pod uwagę 2 tygodnie na sprint, oznacza to 36 tygodni pracy bez przerwy nad tym samym projektem. Możesz również skomentować, że codziennie pracuje około 6 godzin. To brzmi bardzo dużo!

Nie wiem zbyt wiele o metodologiach zwinnych (chociaż faktycznie używamy Scruma w naszym obecnym projekcie), ale jest zasada dotycząca godzin pracy (mam na myśli, że ilość czasu spędzanego na wykonywaniu zadania) powinna wynosić 60% ~ 70%. Teraz, znowu licząc, jeśli dzień roboczy trwa 8 godzin, a pracujesz 6 godzin, tak naprawdę spędzasz około 75% swojego czasu pracy. To może być małe odchylenie, które w końcu sprawi, że poczujesz to.

OTOH, wierzę, że jeśli Twój projekt będzie trwał długo, sprinty powinny być dłuższe, nie 2 tygodnie, ale nie miesiąc. Rozważ krzywą w dół na wykresie wypalenia: rozpocznij sprint od regularnego spalania zadań i zmniejsz aktywność w ciągu ostatnich 2 lub 3 dni przed zakończeniem sprintu.

Agile to nie kamień z grawerem: „pracuj szybciej / mocniej / lepiej / mocniej”, to bardziej jak błękitne niebo z białymi chmurami, które brzmią: „pracuj dobrze, pięknie, wydajniej”. (trochę lol na koniec dzięki uprzejmości daft punk + radiohead).

W pełni rozumiem, co mówisz. Dla tych z Was, którzy mówią „Twoje tempo jest zbyt szybkie”: nie jestem pewien, czy zgadzam się, że tempo jest zawsze problemem, gdy ludzie są wypaleni przez ten proces. Mimo że śledzenie wszystkich postępów JEST dobrą rzeczą, może to być również czynnik stresujący sam w sobie (a nie śledzenie również może być), nie tylko dlatego, że szef / premier będzie przy tobie, jeśli zobaczą, że coś się nie udaje zgodnie z planem, ale dla siebie. Samo posiadanie tych zarejestrowanych informacji sprawi, że większość ludzi będzie pracować tylko trochę ciężej niż normalnie przez CAŁY CZAS i nie jestem pewien, czy poświęcenie więcej czasu na oszacowanie czasu, rozwiąże to dla wszystkich. Nie sądzę, aby motywator (taki jak wykres wypalenia) był zawsze pozytywny.

Niektórzy ludzie nie będą się tak czuć, inni tak. Nie ma JEDNEGO sposobu pracy, który będzie pasował wszystkim. Moim zdaniem nigdy nie będzie.

Ponadto, jeśli mówisz, że te zwinne metody i sprinty nie stają się bardziej efektywne / produktywne, dlaczego w ogóle ich używasz? Jak myślisz, dlaczego firmy w ogóle chcą korzystać z tych metod? Nie dlatego, że są fajni ....

Moim zdaniem skuteczność / produktywność zawsze ma jakąś cenę. Nie pojawia się znikąd po prostu przy użyciu magicznych metod (jeśli rozumiesz).

Jedynym sposobem, aby stać się bardziej efektywnym (pod względem pracy i presji) i wykonywać mniej pracy, jest skłonienie kogoś innego do wykonania pracy lub jej zautomatyzowanie.

Moim zdaniem zawsze należy przejrzeć swoje procesy i zobaczyć, co można zautomatyzować, a zamiast tego poświęcić czas na automatyzację procesów. Automatyzacja ma cenę wykonania dodatkowej pracy zamiast wykonywania „prawdziwej pracy”, ale bez względu na to, jak małe jest zautomatyzowane zadanie, na dłuższą metę zawsze zyskasz. ZAWSZE! Jeśli nie jeden dzień, to za dwa. Nie jeden miesiąc, dwa. Nie jeden rok, za dwa lata. Masz pomysł.

Jednak podoba mi się pomysł wolnego czasu na pracę nad własnymi projektami. Jednak większość firm nigdy na to nie pozwoli. Ale być może uda Ci się przekonać pracodawcę, aby miał czas na zautomatyzowanie procesów, a praca ta może być „poza kontrolą sprintu”, aby czas, o którym mówisz, mógł „odpocząć” i odzyskać energię na nowy sprint.

To były tylko moje 2 centy. Trochę się boję, gdy ludzie mówią, że tych metod nie ma, abyśmy byli bardziej efektywni i pracowali ciężej. Oczywiście że są! Kiedy nie masz śladu tego, co robisz, odpoczniesz, gdy twoje ciało ci to powie. Kiedy „wszystko”, co robisz, zostanie wytropione, będziesz się zmuszać. Albo poprawiam się, większość ludzi pracuje w ten sposób, niektórzy i tak odpoczną.

Zrównoważone tempo jest kluczową zasadą zwinności. Podczas wykonywania praktyk zarządzania (SCRUM) wraz z praktykami inżynierskimi (XP), zespół może realizować sprint po sprincie w nieskończoność. Jednak to, że można, nie znaczy, że należy.

Wygląda na to, że potrzebujesz zmiany w stosunku do niekończącej się serii sprintów, którą widzisz przed sobą. Dostępnych jest wiele opcji. Co X sprintów, członek zespołu (lub para) może opuścić zespół. Podczas rotacji możesz wspierać drużynę biegową, brać udział w zajęciach, skupić się na zestawie kolców, wyjechać na wakacje itp.

Jeśli zespół ma 5 par, a ty obracasz osobę z linii, osoba może zdejmować rotację co 10. sprint (w przypadku jednej osoby) lub co 5. iterację (w przypadku pary). Kwestie budżetu i zwrotu z inwestycji w Twoje działania będą musiały zostać rozwiązane przez kierownictwo i / lub partnera biznesowego. Ale oczywiście posiadanie trochę czasu na „ostrzenie piły” przyniosłoby korzyści zespołowi, a tym samym projektowi. Utrzymywanie zespołu w świeżości i skupieniu to bardzo dobra rzecz. Ale musimy pamiętać, że otrzymujemy zapłatę i musimy wnieść wartość do zarobionych dolarów.

Myślę, że czegoś brakuje, ale nie jesteś jedyny. Jak mówi Jim Highsmith: „Prędkość jest coraz częściej wykorzystywana jako miara produktywności (a nie miara kalibracji wydajności, którą miała być), która zbytnio skupia się na ilości dostarczanych wątków”.

Domyślam się, że to właśnie dzieje się z Twoim zespołem. Polecam przeczytanie tego nowatorskiego postu IMHO Highsmith: Velocity is Killing Agility!