Dev:Cast – #01 Jak zorganizować Daily Scrum aby przynosił wartość

4
298
views

Witajcie w pilotażowym odcinku podcastu Dev:Cast. Pierwszym poruszanym tematem jest długi, rozciągający się w czasie Daily Scrum. Czasem pojawiają się tematy, które powinny zostać jedynie zasygnalizowane i kontynuowane już po tzw. standupie. Niestety stają się niezłą odskocznią od głównego wątku rozmowy, zajmując czas, a nie raz wyzwalając zażartą dyskusję. Rozważamy jak można zapobiec takiemu problemowi bez osoby sprawującej roli supervisora. Jeśli pracujesz w scrumie i czujesz, że Twoje daily stało się za długie oraz „wymemłane” – to idealne trafiłeś. Niech pierwszy odcinek Dev:Cast pomoże Ci w rozwiązaniu tego problemu.

Dodatkowy odsłuch Dev:Cast

Różnorodność używanych mediów do śledzenia podcastów jest jeszcze dla nas nowością. Dlatego na początek, podcast Dev:Cast możesz słuchać:

Udział wzięli

Chcemy aby podcast tworzony był przez różne osoby. Dlatego, też będziemy się starać rozmawiać w różnorodnym składzie, zapraszając do pogawędki także osoby z poza grona naszej rodziny DevEnv. W pierwszym odcinku usłyszycie głosy następujących osób:

Masz pomysł na temat?

Jeżeli chcesz abyśmy porozmawiali na jakiś konkretny temat, zgłoś go za pośrednictwem komentarza pod tym odcinkiem lub za pomocą naszego fanpage w serwisie Facebook.

  • Pingback: dotnetomaniak.pl()

  • tomatlover

    Mam pytanie dotyczące ‚problemów’, o których wspominacie w podcascie. Czy daily nie jest najlepszym miejscem do wspominania o zaistniałych problemach? Nawet jeśli dotyczy on aspektów technicznych, tak?
    Myślę że ludzie mają obawę przed wspominaniem o rzeczach, z którymi sobie nie radzą, gdyż problem z reguły odbierany jest jako zła rzecz.

    Tutaj chciałbym też zaproponować kolejny temat na podcast. Problemy. Nie każdy o nich daje znać, nie każdy też reaguje na zgłoszone problemy. Jak zakomunikować problem tak, by spotkał się on z pozytywnym odzewem i chęcią pomocy.

    • Czy najlepszym? To zależy, natomiast na pewno jest miejscem gdzie powinno się mówić reszcie zespołu o problemach w dowiezieniu celu sprint przez zespół do mety. W dyskusji chciałem zaznaczyć, że klasyczna/dawna forma pytań na daily (choć właściwie pytań być nie musi) powinna być skierowana na cel sprint całego zespołu, a nie wyłącznie na „moich” zajęć. Dzięki temu a) unikniemy sytuacji, schodzenia z tematów nie związanych z aktualnie toczącą się iteracją, b) unikniemy postrzegania daily jako spowiedzi świętej przed kolegami lub (najgorzej) liderem/SM.
      Ważne by pamiętać, że daily to timebox 15min. Problemy, których nie jesteśmy w stanie samodzielnie ubić, oczywiście trzeba poruszyć, aczkolwiek niekoniecznie je rozwiązać.
      Mam nadzieję, że to nieco rozwiało Twoje wątpliwości, a o problemach na pewno kiedyś pogadamy na podcastcie 😉

    • Dzięki za komentarz tomatlover. Pozwólcie, że wtrącę jeszcze swoje trzy grosze.

      O problemach powinniśmy w ramach zespołu rozmawiać cały czas. Nie czekać na daily. Każde wspólne wyjście na kawę, chwila oderwania się od wzroku wbitego w monitor to odpowiedni moment na rozmowę o problemach. Jeżeli nie chcemy przeszkadzać w skupieniu możemy poinformować o problemie i poprosić o pomoc na komunikatorze.

      „gdyż problem z reguły odbierany jest jako zła rzecz”

      Z takim podejściem należy pracować i starać się je wręcz wybijać z głowy. Praca programisty to głównie rozwiązywanie „jakiś problemów” 🙂

      Czasem się śmiejemy w zespole to „nie problemy” to „wyzwania” 😀 Pozdrawiam.