Comment by perrygeo
10 hours ago
I know this sounds like a zen koan but to be consistent, don't worry about consistency. A description of the desired outcome is not a strategy for achieving it.
An actual strategy: track all of the blockers. You say that your sprints "go wrong" but that isn't a helpful observation. If you track why it goes wrong - write down the start and end time any time you get stuck, blocked, confused, waiting on others, dealing with unforeseen issues, "tech debt", etc.
This is not a failure, it's a vital signal! The time spent on blockers are literally what's standing between you and consistency. Address them head on with empirical data. You should be able to estimate the risk for any new change based on how much time you wasted in the past working on that subsystem. It's a clear choice. Slog through the problems again and deliver inconsistent results - or fix it and deliver consistently.
You do have to be selective - don't just fiddle with the code until it's pretty - fix only the observed problems that stand in the way of delivery. "Make the change easy, then make the easy change" - Kent Beck.
Good advice, really. love it. Maybe I can try harder to control these issues. One challenge with this is finding a way to talk about it without it sounding like I'm just complaining all the time
I've definitely been that guy complaining about all the unnecessary friction. What I've learned is that you have to be selective; take note of the flaws when you find them, but put them aside and focus on the things that directly impact current work on your plate. "I'm going to refactor this class in order to add X with less risk" is an easier sell compared to "I'm going to put development on hold while I refactor all the things for some reason."