Dlaczego i z jakich powodów programiści mogą nie lubić „codziennego scrum”? [Zamknięte]

Trzymanie codziennego scrum ma zalety, takie jak:

1. Zespół koordynuje się ze sobą
2. Wszyscy wiedzą, ile zadań zostało wykonanych
3. Wykres wypalenia staje się coraz bardziej kompletny
4. Tablica zadań została zaktualizowana
5. Nie trwa to długo, 15 minut nikogo nie zabije

Jednak ostatnio (po 6 miesiącach wdrażania i używania scrum) czuję, że nasi programiści nie lubią scrumu tak bardzo codziennie. Ludzie po prostu aktualizują tablicę zadań, nie wyjaśniając wystarczająco dużo, i wygląda na to, że się nudzą. Widzę, że kiedy z jakiegoś powodu tego nie trzymamy, stają się wyjątkowo szczęśliwi.

Po prostu nie wiem, co może być z tym nie tak. Czy są gdzieś jakieś powody wspomnianych wad dla „codziennego scrum” dla zespołu? Jakie mogą być przyczyny zmęczenia programistów codziennym scrumem?

Miałem doświadczenie w zespole „SCRUM” z kilkoma pracodawcami. Wydaje mi się, że menedżerowie biorą „codzienne spotkanie scrumowe” jako główny punkt SCRUM i wyznaczają go jako cel, zamiast realizować go tak, jak to jest: środek do osiągnięcia bardziej efektywnego cyklu rozwoju .

Bardzo szybko 15-minutowe spotkania stały się 45-minutowymi spotkaniami, aktualizacje były nieskuteczne, ponieważ ludzie byliby zajęci ziewaniem i myśleniem „kiedy już możemy iść” zamiast słuchać innych, a także łamałoby ludzkie rutyny (ja, na przykład, jestem sowa i codzienne chodzenie do pracy o 9 rano na to głupie spotkanie to wystarczający powód, dla którego muszę rzucić pracę).

Kiedy menedżerowie wpadną na pewien pomysł, który może być dobry, jeśli zastosuje się go poprawnie, i doprowadzą go do skrajności - otrzymają dokładnie odwrotność oczekiwanych rezultatów. Ja osobiście uważam, że im więcej spotkań biorę udział w - tym mniej pracy robię. W kalendarzu mam 2 regularne spotkania tygodniowo i zwykle pomijam jedno z nich. Spotkania są dla menedżerów, zostaw programistom wykonanie ich zadań.

Jestem pewien, że będzie wielu entuzjastów SCRUM, którzy powiedzą „Ale to takie wspaniałe” - no cóż, ocal to, słyszałem to wszystko.

Codzienne wstawanie byłoby nudne i bezużyteczne, gdybym poczuł, że nie ma w tym żadnej wartości. Istnieje kilka rzeczy, które mogą zmniejszyć użyteczność codziennego standupu.

• Udostępniane informacje nigdy mnie nie dotyczą ani w żaden sposób nie wpływają na mnie.
• Brak własności zespołu i wszyscy zawsze pracują nad własnymi projektami.
• Brak komunikacji zespołowej poza jednostką.
• Brak widocznego lub zakomunikowanego postępu.
• Brak informacji do udostępnienia.

Są tuż nad moją głową, ale zawsze jest więcej możliwych powodów.

Być może powinieneś po prostu zapytać deweloperów, dlaczego nie wydają się zainteresowani? Jeśli chcesz mieć więcej / lepszą komunikację, powinna zacząć od Ciebie.

Niektóre problemy napotykane podczas codziennych spotkań SCRUM:

• te, które trwają zbyt długo. Nie chcesz, aby pojawił się w nich ktoś z kadry kierowniczej, ponieważ są one przyczyną tego rodzaju problemów. Zobacz, jak zwykle używają krzesła (tak, trzeba stawać w ich obronie, aby zachęcić ludzi do szybkości)
• musi usłyszeć o kimś (lub 2 lub 3 deweloperach) opisujących jakikolwiek odizolowany problem, który ma w zamian zamiast niego, który decyduje się umówić kolejne prawdziwe spotkanie później, aby omówić to z zainteresowanymi
• głupie godziny. Te spotkania nie muszą odbywać się rano: nie mówisz o tym, co zrobiłeś wczoraj i nie decydujesz, co zrobisz dzisiaj; mówisz o tym, co robiłeś między ostatnim dniem a tym, i decydujesz, co będziesz robić do następnego.
• brak własności aplikacji dla deweloperów. SCRUM działa, jeśli deweloperzy nie są traktowani jak małpy kodowe. Pierwszą oznaką niepowodzenia procesu jest to, że twórcy nie są tymi, którzy oceniają, ile czasu zajmie zrobienie czegoś.
• znowu głupie godziny. Jeśli część zespołu zaczęła pracować nad niektórymi rzeczami i znajduje się „w strefie”, gdy zdarza się codzienność, staje się to kłopotliwe. Dobrym momentem na codzienne jest to, że nikt nie powinien pracować (na przykład po obiedzie lub tuż przed rozpoczęciem dyskusji podczas lunchu).

Czas jest dla wielu zabójcą. Programiści lubią kodować do późna, spać do późna i przychodzić po porannym pośpiechu. Konieczność bycia w biurze o ustalonej godzinie - o wiele za wcześnie. I za późno dla innych, którzy mogą przyjść wcześniej i już zacząć pracę.

Kolejnym problemem jest przepływ . Programista z pewną funkcją będzie działał do późnej nocy, wróci do domu i wróci naładowany i będzie gotowy do kontynuowania. Konieczność spotkania się z najczęściej niezwiązanymi ze sobą kwestiami może go rozproszyć.

Moim spostrzeżeniem jest zdecydowanie zbyt często spotkania te są dla menedżerów, aby wyglądać i czuć, że faktycznie coś robią, a nie są przydatne dla zespołu i projektu.

Na przykład zespół ma za zadanie wykonać szereg krótkich poprawek błędów w różnych projektach. Naprawdę nie pracują jako zespół, ale jako jednostki. Ponieważ jednak nakazuje to polityka firmy / działu, kierownik zespołu / menedżer organizuje codzienne spotkanie scrumowe. Wszystko, co zostało osiągnięte, to zabranie 15+ minut na bezużyteczne spotkanie i zajęcie się 15-30 minutami rozproszenia i braku wydajności przed i po spotkaniu.

Teraz widziałem, jak Scrum dobrze sobie radzi w projekcie, który miał napięte terminy i wymagał dużej koordynacji między ludźmi pracującymi nad różnymi utworami. W tym kontekście był to świetny system. Ale w kontekście „Jesteśmy na spotkaniu, ponieważ jesteśmy sklepem typu scrum / agile i właśnie to mamy robić” może naprawdę być do kitu.

Upewnij się, że nikt nie monopolizuje spotkania.

Jeśli 4 programistów usunie się z gry w ciągu 5 minut, a kolejne 10 minut zostanie spędzonych na słuchaniu lidera zespołu opisującego wszystkie niesamowite , niesamowite nowe osiągnięcia, których dokonał, z których większość nie jest ani tak niesamowita, ani tak niesamowita jak mu się wydaje, ludzie bardzo szybko się nudzą.

Odsuń się na chwilę i pomyśl o swoim zespole:

• Czy działają skutecznie?
• Czy zadania są wykonywane na czas?
• Czy kod jest solidny i dobrze napisany?
• Czy zespół zapewnia, że ​​nic nie wpadnie przez pęknięcia?
• Czy zespół koordynuje się, aby nie powielać pracy ani nie deptać sobie nawzajem?

Jeśli Twoja odpowiedź na wszystkie te pytania brzmi „Tak”, być może powinieneś zastanowić się, dlaczego chcesz zmusić do pracy, jak codzienne spotkania, tabele wypalenia i tablice zadań w swoim zespole. Jaką wartość to dodaje? Czy chcesz generować biurokratyczne dane wyłącznie dla własnej przyjemności, czy starasz się zwiększyć wydajność zespołu?

Czy nastąpił spadek wydajności od czasu zatrzymania się codziennych młynów, czy też wszystko tyka tak samo jak wcześniej? Jeśli nic się nie zmieniło, po co kontynuować spotkania?

15 minut. Czy to 15 minut (plus czas na przygotowanie się) przekazuje wystarczającą ilość nowych i przydatnych informacji między członkami zespołu, aby poprawić wydajność zespołów na nadchodzący dzień o ponad 15 minut? Jeśli każdego dnia nie ma takiej ilości przydatnych treści, członkowie zespołu prawdopodobnie myślą, że zrobiliby znacznie większy postęp w kierunku celów, gdyby jak najszybciej opuścili spotkanie i wrócili do pracy.

Jeśli chcesz tylko często aktualizować planszę i wykres, umieść kopie robocze na wiki.

Sugerowałbym, aby odbyć spotkanie retrospektywne, aby zobaczyć „Co poszło dobrze” i „Co nie poszło dobrze” i sprawdzić, czy programiści wymieniają codzienne spotkanie Stand-up jako stratę czasu. W takim razie trzeba go trochę przeorganizować.

Moje osobiste doświadczenie:

• Chodzi o to, aby wiedzieć, co robimy dzisiaj i gdzie byliśmy wczoraj. Zamiast trzymać się agendy, zaczyna się techniczna dyskusja na temat blokerów między 2 osobami, a pozostałymi 15 się nudzi. Zidentyfikuj problem, ale przedyskutuj na zewnątrz
• Ludzie nie wchodzą na salę konferencyjną na czas, a niektórzy celowo to robią. Dlatego Scrum Master musi odbyć z nimi cichą dyskusję poza spotkaniem, aby upewnić się, że zaczną i kończą się na czas.
• Aktualizujemy już wykresy wypalenia poza spotkaniem Scruma, aby nie było to głównym celem codziennej walki.

Opór pojawia się, gdy: 1) Służą do zmuszenia ludzi do pośpiechu o 9 rano. Jest dodatkowy stres, gdy pociąg się spóźnia. 2) Słabe przywództwo scrum. Lider powinien mówić ludziom, żeby zdjęli rzeczy z linii, a nie zmuszali ludzi do słuchania czegoś, co ich nie dotyczy. 3) Treści bezwartościowe. To znowu kwestia przywództwa scrum. Ma to być forum zajmujące się wąskimi gardłami, problemami trajektorii i potencjalną współpracą. W rzeczywistości każdy mówi po prostu, czego oczekuje od pracy w tym dniu, co nie jest przydatne ani interesujące dla nikogo innego. 4) Stojący. Nie będę stać na stojąco. Logika stojąca za tym była taka, że ​​zachęca ludzi do krótkich wypowiedzi. Ludzie faktycznie po prostu grzechotają.

Wiele razy zarządzałem zespołami scrum i byłem ich częścią. Kluczowym powodem, dla którego programiści nie lubią scrum, są:

• Ponieważ są prowadzone przez bardzo słabego mistrza scrum, jeśli zmieni się to w 45 minut, twój scrum master musi poprawić kontrolę nad scrumem.
• Największym i jak dotąd najbardziej uczciwym powodem, dla którego im się to nie podoba, jest to, że bardzo trudno jest ukryć złą etykę pracy, tj. Bardziej rażąco pokazuje leniwych ludzi. Niektórzy deweloperzy, z którymi pracowałem, są szokujący, wykonują zadania, które powinny zająć 30 minut. Dobry premier powinien usunąć bariery dla deweloperów, co oznacza, że ​​powinni móc wykonywać swoje zadania w sprincie. Twórcom się to nie podoba, ponieważ muszą codziennie wstawać i demonstrować poczynione postępy. Powoduje niepokój, gdy nie mogą wykazać postępu z jakiegokolwiek powodu. Jeśli to z powodu ważnego problemu, dobry mistrz scrum powinien rozwiązać ten problem jak najszybciej.

Problem pojawia się, gdy mistrzowie scrum nie mają uprawnień, umiejętności ani zdolności do rozwiązywania problemów z blokowaniem. W rzeczywistości widziałem kilka problemów z pogrzebaniem w nadziei, że odejdą. To jest katastrofalne.

Szczerze mówiąc, w 99% codziennych spotkań, w których uczestniczyłem, prawie wszystkim dyskusjom / pytaniom / odpowiedziom można było zaradzić za pomocą kilku e-maili.

Szczerze uważam, że musimy podać bardziej uzasadnione powody, by NIE organizować spotkań. Buduj środowiska, w których kiedy nadejdzie czas, aby wszystkich osobiście zamknąć w pokoju, że lepiej być dobrym powodem i być zorganizowanym, aby zmaksymalizować wydajność czasu.

Nienawidzę spotkań w ogóle i wolałbym korzystać z wideokonferencji, telefonów, e-maili i wszystkiego, co pozwala mi wejść lub pozostać w pracy bez konieczności wstawania i zakłócania wydajności.

Osobiście uważam, że jeśli masz więcej niż cztery spotkania w ciągu 8 godzin, projekty nie są dobrze zarządzane.

Istnieje wiele czynników, które przyczyniają się do napięcia wokół spotkań. Weź to pod uwagę jako jeden z ważnych powodów, dla których spotkania mogą cię kosztować więcej niż są warte:

• Focus - oprogramowanie kontra spotkania
• Zarządzanie - menedżerowie potrzebują pomiaru
• Osobowość - introwertycy kontra ekstrawertycy
• Czas - przerwy, czas Twórcy i Menedżera
• Cele, priorytety

Każdy z tych czynników wyjaśniono poniżej,

Koncentracja - Lubię tworzyć oprogramowanie, które obejmuje myślenie o wyzwaniach (problemach), tworzenie rozwiązań, tworzenie oprogramowania i spotkania, które odwracają uwagę od zadań związanych z tworzeniem oprogramowania. Istnieje stan o nazwie „ Flow ”, w którym programista jest zanurzony w wyzwaniu (problemie), zbudował mentalny model rozwiązania i całkowicie skupia się na budowaniu rozwiązania. Deweloper może pracować do północy, pozostawiać tylko po to, aby jeść i spać, a następnie powrócić do stanu bliskiego miejsca, w którym wyszedł.

Programiści muszą unikać rozpraszania uwagi, a wielu uważa, że ​​kodowanie do późnych godzin ma zalety (unikają hałasu, rozmów telefonicznych, zajętego biura i współpracowników niebędących programistami przerywających pracę). A kiedy pracowałeś do 10, 11 lub 12, przychodzenie do pracy później (10, 11 w południe?) Jest nieracjonalne. Czy można oczekiwać od programistów pracy od 9 rano do północy?

Spotkania Scrumowe (i wszelkie inne) odwracają uwagę programisty od ich głównego celu, jakim jest budowanie oprogramowania.

Zarządzanie - Menedżerowie muszą mierzyć, aby odnieść sukces, stąd potrzeba harmonogramów, rezultatów, harmonogramów, priorytetów i spotkań w celu pomiaru i zgłaszania postępów oraz ujawniania zależności, opóźnień i obszarów ryzyka. Wyzwanie związane ze Scrumem polega na tym, że menedżer potrzebuje tych rzeczy, ale deweloper musi się skupić. Spotkania służą menedżerowi i zapewniają menedżerowi sposób uzyskiwania, mierzenia i śledzenia statusu i postępów, ale spotkania rzadko zapewniają użyteczność programistom. Weź pod uwagę, że menedżerowie zapewniają większą wartość, gdy radzą sobie z rozrywkami, usuwają bariery i umożliwiają programistom skupienie się na tworzeniu oprogramowania.

Istnieją rozwiązania potrzeby spotkań. Menedżer może odwiedzać swoich programistów, prosić o raporty o stanie, przyjmować protokół, gdy zakłócenia są mniej ingerujące, lub przyjąć zasady informujące programistę o postępach, gdy programista jest przerywany. Zobacz dyskusję czasu, dlaczego jest to ważne.

Osobowość - weź pod uwagę, że niektórzy ludzie są introwertykami, a inni ekstrawertykami. Ekstrawertycy lubią interakcje społeczne i są przez nich ładowani. Menedżerowie są zazwyczaj ekstrawertykami (ponieważ ekstrawertycy są zwykle lepsi w kontaktach społecznych), chociaż introwertycy mogą odnosić sukcesy jako menedżerowie. Introwertycy mogą cieszyć się, a nawet celować w interakcjach społecznych, ale są ładowani przez samotność. Deweloperzy często są introwertykami i odnoszą sukcesy pracując samodzielnie (lub w małych zespołach), ponieważ nie potrzebują „interakcji społecznych”; mogą być szczęśliwi pracując samodzielnie nad problemami (chociaż ekstrawertycy mogą być również programistami). Codzienne spotkania scrumowe mogą stać się spotkaniami towarzyskimi, dobrymi dla ekstrawertyków, ale nie tak dobrymi dla introwertyków.

Czas - programiści nie mogą pisać kodu podczas spotkań. Nie mogą też myśleć o trudnych problemach (chyba, że ​​burza mózgów), podczas gdy są rozproszeni przez spotkania. Programiści potrzebują dużych bloków nieprzerwanego czasu, aby skupić się na tworzeniu oprogramowania. Spotkania są przerwami, które odwracają uwagę od ich wysiłków. Kiedy godzinami zanurzasz się w rozwiązywaniu problemu, prawie już skończyłeś, a ktoś mówi „czas na scrum”, zostajesz przerwany i być może tracisz godziny pracy podczas „zmiany biegów”. Lub pozostałeś w pracy do 23:00, opuściłeś pracę, pojechałeś do domu, spałeś na problemie, obudziłem się, wróciłem do pracy gotowy do rozwiązania problemu, a potem zostałeś przerwany po godzinie pracy nad problemem, ponieważ to „czas na scrum”.

Paul Graham ma doskonały artykuł na temat Maker Time vs. Manager Time, który wyjaśnia ten problem znacznie lepiej niż ja. Wystarczy powiedzieć, że przerwanie spotkania, niezależnie od tego, czy jest planowane, czy nieplanowane, może przerwać przepływ i zmusić programistę z czasu Maker do czasu Menedżera. Uwierz mi, chcesz programistów na czas Maker.

Cele, priorytety - Programiści i menedżerowie mają różne cele i priorytety. Menedżerowie mają obowiązek śledzenia harmonogramów, minimalizacji kosztów, upewnienia się, że ich raporty są odpowiedzialne i że wykonują. Programiści mają na celu zbudowanie oprogramowania, które sprosta wyzwaniom / problemom. Cele te nie są w konflikcie, ale to mechanizm komunikacji powoduje napięcie. Spotkania służą potrzebom menedżera i optymalizują czas menedżerów, ale są sprzeczne z potrzebami programisty. Spotkania Scruma odrzucają pierwszą zasadę spotkań, „mają porządek obrad” i mają tendencję do błąkania się dalej. Spotkania służą do optymalizacji komunikacji (dla menedżera), ale kosztują czas programisty (przerwy, utrata przepływu itp.).

Jaki jest cel Aby szybko i jakościowo tworzyć oprogramowanie, które zaspokaja potrzeby, a ograniczeniami są (jakość, czas, koszt, proces). Scrum i inne zwinne metodologie rozpoznają ograniczenie procesu i próbują zminimalizować ten czynnik, i odniosły sukces, ponieważ minimalizują to ograniczenie. Ale dodawanie spotkań kosztuje czas, a przerwanie kosztuje programistę znacznie więcej niż czas trwania spotkania.

Zmodyfikuj spotkanie, aby upewnić się, że zapewnia ono korzyści:

1. Zaplanuj to w czasie, który oferuje pewną wygodę. Dlaczego nie może upłynąć 30 minut od rozpoczęcia pracy, aby każdy mógł przejrzeć e-mail i uporządkować swoje przemyślenia na spotkanie. Brevity wymaga planowania. Nieprzygotowani mogą włóczyć się wiecznie.
2. Zidentyfikuj problemy, których można by uniknąć, gdyby problem został zakomunikowany podczas spotkania. Każdy musi zrozumieć, o co chodzi.
3. Zrób wszystko, aby ograniczyć wkład wszystkich do minimum. To nie jest miejsce na debatę. Zachęcaj ludzi do prywatnego planowania spotkań poza codziennym spotkaniem poświęconym tematowi, który wymaga dyskusji. Reguła: rozmawia tylko jedna osoba na raz.

Wszyscy skarżący muszą upewnić się, że nie przyczyniają się do powstania problemu. Jeśli możesz osiągnąć swoje cele w codziennym scrumie, nie mając go w mniej bolesny sposób, chcielibyśmy to usłyszeć.