to keep everyone busy all the time doesn’t work

I agree but that has nothing to do with scrum. It does not say how busy everyone has to be. Things like these are left for the team to decide. If you felt like you had to be more busy, then someone among you probably pushed it.

In fact i prefer a bit of slack time so people can react to incidents better. Imagine a 100% busy highway. Not nice. And then you need to spontaneously deliver something from A to B, using that highway -> there will be a traffic jam and everything works terribly. Have a bit of slack here and there so the spontaneous delivery does not mess up the flow -> much more effective and everyone is happier too.

thanks for your words.

I always wonder what the point is of time-boxing in the first place

When all work is done inside of sprints (including merging, testing, delivery, troubleshooting) etc., as it originally is meant, this becomes a really convenient thing. Sales people, the customers or the manager, know at 1pm every other Friday they can come to the review, check out a new iteration, with contiguous items, without interrupting anyone or having to make changes in their full calendar to get in touch. In kanban, i wouldn’t be so sure when a good moment is to review with others, in advance.

I like kanban too, by the way.

I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time.

And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.

The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint. The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.

Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.

estimate weeks

In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.

The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea and Scrum makes an entire process out of this bad practice.

Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too. Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…

You can actually see sprints as mini-Waterfalls. But the point is to fail and learn from it. I am sorry you had no Scrum Master with responsibility. Not finished on Friday? So be it! Find out why and try a solution. You had distractions, complexities during the sprint: reduce them! You planned wrong: why? Were you forced to, by people outside of your team? Put the decision making back to the team, where it belongs. Nobody else.

Embarrassment at the review? Don’t cover it up because no one will learn from it. Dont fix something in secret over the weekend. Someone will not notice something was ever wrong.

the mini waterfall is kind of the intention of a sprint. The whole idea is to reduce the huge waterfall and its horrible surprises at the end when it is way too late. Have those surprises early by doing small waterfalls. But everybody is splitting it wrong so all the small waterfalls have no outcome until the whole thing is done, just like you do without sprints.

I am so sorry to everybody here who never saw the real agile. All you ever saw was fake / wasabi scrum. The little side gig scrum with the tickets and the sprints and a scrum master without any power to change a company is a frustrating distraction for everybody.

As soon as the team makes their own decisions and the bosses in every level actually help them on this, they can become agile and the framework just a communication theme.

I’d rather say an SM does not shield the team from bureaucracy, but makes them face it and empowers them to take it down.

The SM coaches the team on targeting the right topics themselves. Making them realize what to focus on. Ideally, don’t to the work for them, that they should be able to do themselves. That would make them ignore these topics, because the SM takes care of it for them.