4 ms·
>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. Agree with everything _expect_ retros.
by DoingIsLearning 3y ago
>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming.
Agree with everything _expect_ retros.
I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have:
- Teams that can look at problems head on and be civil addressing things without making it personal.
- Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team.
In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.
- lucumo 3y agoI found that retros tend to devolve into gripe sessions when the team isn't able to change its environment. Best to keep them focused on things they can actually change, and just to let them fix what they need instead of talking about it. Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good at and they're motivated to do.
- przemo_li 3y agoProposing retro board be available 24/7 and retros be skipped if board is empty is good use of retro time. ;)
- bluefirebrand 3y agoThis sounds amazing. But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting. I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".
- sodapopcan 3y agoI've worked on a team that had amazing retros: lots of difficult discussions that resulted in change. We also made sure to discuss positive things too to ensure they keep happening. I think a lot of people miss this about retro. I also worked on a team with terrible retros. The "good" column would always be extremely long and was only full of platitudes, nothing of actual substance that was brought forward into the next week. If anything difficult came up, someone would say, "Ok, let's book a meeting to talk about this later". It was an extreme misunderstanding of the value of retros. Though everyone else seemed to enjoy them so that's arguably valuable? I dunno. Anyway, yes, lots has been said on this topic in the past. SCRUM is just Agile for stakeholders. There is the whole "SCRUM But" joke but I actually think a bunch of things in SCRUM are valuable BUT if something isn't working out, don't do it! I get the impression that lots of companies just do all the rituals "because SCRUM" and don't actually understand why they are doing them. Case in point, I was at a company that would always spend time story-pointing but no one ever looked at them. Not the teams and not the stakeholders.