I like focusing on the root motivation. I haven't been able to get to it based on previous conversations. It seems to be perceived velocity because of the increased visibility from what I've gathered but the fact that we don't even have the option to experiment leads to a bigger issue IMO. The teams just aren't empowered to adjust course.
See if your manager knows what's going on. They may be just as oppressed as you feel!
And they may be willing to go along with smaller secret team-level experiments. Maybe Kanban will result in even better visibility and performance! (And satisfaction)
Yeah, unfortunately I did and have been declined several times to experiment. I've also suggested Kanban too since it feels more in line with the pace and the lacking requirements and also shut down several times.
Saying this probably indicates more problems but they also insist on demos each week and demos/retros every 2 weeks. Also they want metrics/retros to track team velocity.
How much time per week do you have dedicated to sprint meetings? Another issue we have is requirements are always lacking because it’s always fires (and everything is P1).
The most efficient form I've seen is one 30 min meeting to discuss what we plan to do and what went wrong/well with previous plans. And a second 60 min meeting at the end of the week to show what we've done, the impact, and the GTM plan.
But if you have frequent P1 fires, then you definitely need the retros quite often. In our case, we always do post mortems for a P1. We dig deep into root causes and this alone is a significant meeting. If it's P1, then, well, it should take everyone's attention. If it's not that major, then it should be some other level. But they shouldn't be happening more than one a quarter or something. It's okay to not be adding features – sometimes reducing fires is significant progress, lol.
Sprint planning meetings for us is just 30 min. We update a doc, it doubles as the retro. Most of the tickets and stuff is already managed by Jira; PM just ticks what we plan to do that sprint. Requirements have already been reviewed before the meeting starts, the meeting is where we work out a plan for it.
They are also forcing time based pointing onto the teams too. 1 point per engineer day. There are other issues with the leadership expecting each engineer to be able to support 5-6 “points” a week but that’s another story.
Exactly that being a problem within itself. It feels so counter to the philosophy of Agile being “people over process”. If the people are saying they need more prep time why aren’t they listening?
