Dzięki Pawel za zaproszenie do Twojego podcastu oraz arcyciekawą dla mnie rozmowę. Mam nadzieję, że będzie ona uzupełniającym spojrzeniem na AGILE dla Twoich odbiorców.
Scrum w teorii jest super, w praktyce wygląda to tak że byleby napchać jak najwięcej zadań do Sprintu i ognia. Zazwyczaj dorzuca się stopniowo zadania, aż zespół lub któryś Developer przestanie się wyrabiać w ciągu 8h pracy. Niestety tak to wygląda w wielu firmach. Dowalić pracownikowi tylu zadań, aż nie powie dość. Narzędzie, które w teorii miało służyć programistom stało się narzędziem do codziennego przesłuchiwania co kto robił wczoraj, wywieraniu presji na ciągłe dowożenie. Dla mnie Scrum Master to po prostu dozorca pracy, tylko jest to obrane w korpomowę, aby było ładniej.
Developer here. Chyba miałem szczęście, bo w życiu nie widziałem takiej patologii. Zawsze w zwinnych zespołach, w których pracowałem, to developerzy decydowali o tym jak wygląda backlog sprintu, a nagłe wrzutki powodowały dyskusję o tym co zmienić w planie sprintu, żeby zmieścić nową rzecz. Nigdy (poza pierwszą pracą w małej firmie) nie miałem ciśnienia z góry na nadgodziny (poza naprawdę drobnymi i uzasadnionymi wyjątkami). W mojej obecnej pracy w ogóle nadgodzin nie mamy. Widziałem czasami wręcz odwrotną sytuację. Programiści, z powodu dobrych intencji, sami sobie dokładali roboty mimo, że nikt im nie kazał. Ale to akurat coś, z czym manager czy scrum master powinien walczyć.
Oczywiście smutno się słucha takich historii. Szkoda, że masz takie doświadczenia w pracy zwinnej. Mam nadzieję, że znajdziesz miejsce gdzie tak to nie wygląda a Scrum Master na prawdę wspiera zespoły w usprawnieniach pracy z pełnym poszanowaniem zespołowości.
Dzięki Pawel za zaproszenie do Twojego podcastu oraz arcyciekawą dla mnie rozmowę. Mam nadzieję, że będzie ona uzupełniającym spojrzeniem na AGILE dla Twoich odbiorców.
To ja dziękuję za dobrą rozmowę :)
Scrum w teorii jest super, w praktyce wygląda to tak że byleby napchać jak najwięcej zadań do Sprintu i ognia. Zazwyczaj dorzuca się stopniowo zadania, aż zespół lub któryś Developer przestanie się wyrabiać w ciągu 8h pracy. Niestety tak to wygląda w wielu firmach. Dowalić pracownikowi tylu zadań, aż nie powie dość. Narzędzie, które w teorii miało służyć programistom stało się narzędziem do codziennego przesłuchiwania co kto robił wczoraj, wywieraniu presji na ciągłe dowożenie.
Dla mnie Scrum Master to po prostu dozorca pracy, tylko jest to obrane w korpomowę, aby było ładniej.
Developer here.
Chyba miałem szczęście, bo w życiu nie widziałem takiej patologii.
Zawsze w zwinnych zespołach, w których pracowałem, to developerzy decydowali o tym jak wygląda backlog sprintu, a nagłe wrzutki powodowały dyskusję o tym co zmienić w planie sprintu, żeby zmieścić nową rzecz.
Nigdy (poza pierwszą pracą w małej firmie) nie miałem ciśnienia z góry na nadgodziny (poza naprawdę drobnymi i uzasadnionymi wyjątkami). W mojej obecnej pracy w ogóle nadgodzin nie mamy.
Widziałem czasami wręcz odwrotną sytuację. Programiści, z powodu dobrych intencji, sami sobie dokładali roboty mimo, że nikt im nie kazał. Ale to akurat coś, z czym manager czy scrum master powinien walczyć.
Dzięki za głos developera i cieszę się, że masz tak dobre doświadczenia :)
Oczywiście smutno się słucha takich historii. Szkoda, że masz takie doświadczenia w pracy zwinnej. Mam nadzieję, że znajdziesz miejsce gdzie tak to nie wygląda a Scrum Master na prawdę wspiera zespoły w usprawnieniach pracy z pełnym poszanowaniem zespołowości.