Artwork

Treść dostarczona przez Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.
Player FM - aplikacja do podcastów
Przejdź do trybu offline z Player FM !

Episode 394: Scrum master, weapons master and minimum tenure to not look bad

29:21
 
Udostępnij
 

Manage episode 399357212 series 133571
Treść dostarczona przez Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.

In this episode, Dave and Jamison answer these questions:

  1. My team are about 4 months into transitioning from a scrum/kanban way of working to a more traditional scrum/sprint way of working.

    I feel like our scrum master is “weaponising” some of the scrum practices in order to show up weak points and failures in the team, rather than working with the team to ease us through the transition and make gradual improvements.

    In private conversations with me and some other trusted developers (lol jk I clearly shouldn’t be trusted as I’m writing in to Dave and Jamison) the scrum master speaks about how little refined work we have in our back log, and how they are looking forward to “exposing bottle necks” in the team. As they expect this will lead to pressure on our PO and Business Analyst and force them to step up their game.

    Whatever amount of work we bring into a sprint is law, and they forbid more tickets coming onto the board mid sprint (even if all the tickets are done half way through the sprint).

    If one single ticket is on the board they will try to block more tickets moving into ready for Dev as they believe we should all be focusing on getting the highest priority pieces of work into the done column. And they take no notice when I’ve expressed the issue with this too many cooks approach.

    They’re a nice enough person outside of a work context. But in work, it really feels like they’re setting us up to fail (and sort of releshing in it).

    Dissent is rising in the team, and everyone from all sides feels unhappy. Can you recommend any action I could take to prevent the failures that are inbound?

    For context, I am a junior developer working for a large company. Within my department we are split up into “SCRUM” teams made up of around 6 Developers, 2 testers, a scrum master, a Business Analyst and a Product Owner. The senior developers within the team have not taken any action other than to complain in secret about the SMs behaviour.

  2. Before the tech recession, I would recommend engineers stay at a job for 12 months before looking for a new job in order to avoid having the stigma of being a job hopper. But with the tech recession enabling employers to be more picky, is 12 months long enough? Or should engineers stay at a job for even longer than 12 months before looking for a new job?

  continue reading

410 odcinków

Artwork
iconUdostępnij
 
Manage episode 399357212 series 133571
Treść dostarczona przez Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.

In this episode, Dave and Jamison answer these questions:

  1. My team are about 4 months into transitioning from a scrum/kanban way of working to a more traditional scrum/sprint way of working.

    I feel like our scrum master is “weaponising” some of the scrum practices in order to show up weak points and failures in the team, rather than working with the team to ease us through the transition and make gradual improvements.

    In private conversations with me and some other trusted developers (lol jk I clearly shouldn’t be trusted as I’m writing in to Dave and Jamison) the scrum master speaks about how little refined work we have in our back log, and how they are looking forward to “exposing bottle necks” in the team. As they expect this will lead to pressure on our PO and Business Analyst and force them to step up their game.

    Whatever amount of work we bring into a sprint is law, and they forbid more tickets coming onto the board mid sprint (even if all the tickets are done half way through the sprint).

    If one single ticket is on the board they will try to block more tickets moving into ready for Dev as they believe we should all be focusing on getting the highest priority pieces of work into the done column. And they take no notice when I’ve expressed the issue with this too many cooks approach.

    They’re a nice enough person outside of a work context. But in work, it really feels like they’re setting us up to fail (and sort of releshing in it).

    Dissent is rising in the team, and everyone from all sides feels unhappy. Can you recommend any action I could take to prevent the failures that are inbound?

    For context, I am a junior developer working for a large company. Within my department we are split up into “SCRUM” teams made up of around 6 Developers, 2 testers, a scrum master, a Business Analyst and a Product Owner. The senior developers within the team have not taken any action other than to complain in secret about the SMs behaviour.

  2. Before the tech recession, I would recommend engineers stay at a job for 12 months before looking for a new job in order to avoid having the stigma of being a job hopper. But with the tech recession enabling employers to be more picky, is 12 months long enough? Or should engineers stay at a job for even longer than 12 months before looking for a new job?

  continue reading

410 odcinków

Wszystkie odcinki

×
 
Loading …

Zapraszamy w Player FM

Odtwarzacz FM skanuje sieć w poszukiwaniu wysokiej jakości podcastów, abyś mógł się nią cieszyć już teraz. To najlepsza aplikacja do podcastów, działająca na Androidzie, iPhonie i Internecie. Zarejestruj się, aby zsynchronizować subskrypcje na różnych urządzeniach.

 

Skrócona instrukcja obsługi