I have always considered scrum to be like a beginners workout routine. It's never best for you, but it's better than doing what you feel like is good for you. Because if you've been lying on the sofa for the last ten years, you don't know what's good for you.
Chances are that you don't know what suites you, that's why you are looking into scrum in the first place. First you do it strictly by the book and in time you will learn what works for you and what doesn't. Then you can start customizing become mature agile team/organization. OP has probably achieved this, but I think it can be harmful to suggest "pro" techniques to someone just starting out :)
To borrow your analogy, to me Scrum is like the guy who reads some stuff about working out on the Internet and proceeds to try and correct everyone in the gym on their form.
That's a great analogy. I think you need a high-functioning team that really understands the Agile manifesto and its principles to roll-your-own solution.
If you are going to roll-your-own solution, start with retro and build from there. Retro is the most important part of the process. There's a reason it's the only explicit activity mentioned in the manifesto. As long as you keep reflecting on past performance and continually try to improve you'll probably end up with a good process.
It encourages everyone to ignore/bottle up issues until the magical retro day where everyone can spend a couple of hours venting their frustration. At which point nothing gets done and the process repeats. Project issues should be resolved immediately, directly with the people responsible and with actionable outcomes. Not during a glorified weekly/fortnightly 'meeting'.
It encourages everyone to ignore/bottle up issues until the magical retro day where everyone can spend a couple of hours venting their frustration. At which point nothing gets done and the process repeats. Project issues should be resolved immediately, directly with the people responsible and with actionable outcomes. Not during a glorified weekly/fortnightly 'meeting'.
If that's what happening then the retros are being terribly run. Especially if you're not coming away with an actionable outcome.
If you can deal with it immediately - you deal with it immediately. Nothing in any agile process says you should save it up for the retro. Many quite forcefully say the opposite.
The retro is for helping you spot larger scale issues or systematic problems that you miss / don't have the room to address in the day-to-day project.
(For example, we ran one last Friday where it was pointed that I'd been a bottleneck on several different tasks. I'd not been bright enough to spot that myself. Since the bottlenecks were with different folk nobody had spotted it at the time. Bring everybody together and - boom - problem identified and some options for solutions spotted. No angst or venting involved. There was cake though ;-)
"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly."
That's what I mean by retro. Two parts: self-reflection, and change of behavior.
Sounds like your problem with retro is that behavior isn't changing. Maybe it's management stopping things from changing, or teammates who refuse to go along with what the team wants. A team that won't change won't get better.
Chances are that you don't know what suites you, that's why you are looking into scrum in the first place. First you do it strictly by the book and in time you will learn what works for you and what doesn't. Then you can start customizing become mature agile team/organization. OP has probably achieved this, but I think it can be harmful to suggest "pro" techniques to someone just starting out :)