Ditching Scrum for Kanban - The best decision we’ve made as a team

2-3 hour backlog grooming sessions is a warning sign. Of what I couldn't say but maybe it is time to evaluate team size or how meetings are being conducted. Push as much stuff out of meetings as possible.

If you have a morale issue due to stuff slipping (and I suspect maybe you didn't capture everything in this post) then it may not be planned sprints that are the issue. Expectations that people have of themselves and of the team are something you are free to set. I think SCRUM tend to end poorly for developers because they are placed on top of dysfunctional systems of expectation that discourage many kinds of failure.

I am perfectly happy abusing SCRUM and letting things slip from sprint to sprint sometimes excessively. Fitting things into 2 weeks was a goal to gain the benefits of constrained scope and clearly articulated and designed implementations or requirements, but failure is something I made sure to embrace. Sure we had retrospectives to see what could be learned and what we could do better, but you have to be very careful to make sure it isn't second guessing or moving the goal posts. You shouldn't fault people pretty much ever as part of SCRUM, but definitely don't fault them for slippage. There should be next to no onus on an assignee for a task to prove they did the right thing.

IMO That kind of feedback comes best out of band on a very macro scale when there is a pattern of failure for an individual to address AND you must get buy in from the individual that there is improvement to be had. The reason I stress this is that I don't want people to try and avoid things that they might fail at. That pushes people away from important work that needs to be done.

I think that planned sprints and retrospectives are the 1-2 punch of SCRUM. By estimating what you should be capable of you are then capable of reasonably identifying WHY you didn't achieve that and trying things until there is improvement or you establish that the estimates are wrong. SCRUM without high functioning retrospectives is missing 50% of the goodness IMO.

It's great that you kept regularly scheduled meetings. There is a huge amount of buy in, knowledge sharing, and consensus you get for relatively low cost by having regularly scheduled meetings. With small enough teams you can get it all done with one hour long interrupt per week. Socially it's also good because it discourages backroom deals, planning, and cliques which are toxic. Doubly so if you have remote workers.

Depending on the scale you're operating at, it's easy to see this as a waterfall methodology. There are lots of different words to describe organizing work, but what's important is that the methodology remains consistent enough that the team understands it.

I think of time-boxed sprints as great for training. Humans aren't going to get better at estimating how long it takes to complete complex engineering tasks. But teams that work together over a long enough period of time can plan ahead better. (For example, time-boxed sprints would suggest that everyone has to take vacations at the same time for Scrum to be effective.) There are plenty of ways to deal with the fact that humans are asynchronous. I particularly liked this author's focus on team morale as a major factor.

Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.

To me, that rhymes with "hero that papers over bad management".