Why I'm not a big fan of Scrum

it is totally reasonable for stakeholders to want to track your progress through a project. If you have a good way of doing that then great, you should use that.

Scrum people believe that scrum is the simplest way of measuring that. But at some stage you have to estimate the constituent parts of the project in order to get an idea of its size, and for those estimates to be useful in tracking your progress you have to do it in advance.

I repeat however, if you dont need to do this then thats fantastic! Many of us do however, and some of us choose to use scrum to do that, and some of us have had a great deal of success with that.

(edit: I worry that this sounds condescending. I am just trying to keep the tone friendly)

There are some valid criticisms here, though on balance I think the author enumerates costs without considering benefits. But the biggest complaint is a result of a common misconception: that scrum is somehow a replacement for software design. It is not, nor is it intended to be. The author seems to have a glimmer of understanding that this is the case:

Scrum, however, is much closer to the problem solving approach, where analysis (breaking down a problem, and reassembling the solution) is the organizational tool. In order for an interpretive community to emerge, an organization needs ambiguity, open-ended conversations, and alternative perceptions. All of this, Scrum leaves to something else, whatever it is.

But then goes on as though Scrum precludes any kind of thoughtful design or experimental innovation. Nonsense. Nothing in Scrum suggests that a team mindlessly go through sprint after sprint without ever pausing to have design sessions or build prototypes. And there is scant mention of the product owner at all; it's as though the author believes that software is designed by developers, for developers.

Scrum is a way to implement a software design, flexibly and with the understanding that the design will change along the way. How you decide what to implement, how you arrive at that initial design, is up to you. If your organization doesn't understand how to create and manage the abstractions that make up a software application to begin with, then Scrum isn't going to save you.

Isn't there a name for this pattern?

I swear I remember reading a piece on how having a team member leave can be good for cohesion and efficiency, because everyone is free to vent about old, bad decisions without targeting anyone still at the company. I think it was part of a story about a team clearing their technical debt by convincing a reluctant manager that they needed to undo the last guy's mistakes.

I managed a small team of engineers and synchronous daily standups just broke down with remote teams and timezones.

It also just felt unproductive - it became something we did to feel like we had "best practices" when in reality it was a waste of everyone's time.

I got the sense that everyone would essentially forget what they said/heard at the end of the meeting (or was simply tuned out).

I ended up launching a tool to solve this problem: (https://jell.com).

We're a lot happier showing a "todo list" with each other and still have a place to write out the challenges/progress we're making - all while respecting each others time.

Not to take away from either point, and I largely agree, but written word is our 'mode 2' - a lot can be missed without talking face to face.

Yes the issue with standups/scrum cereomonies is if people ignore all the 'other' info they are receiving and for what ever reason choose to ignore it.

The real key for Scrum for me has to be not only teams that want to write good code, but teams that WANT to get better at working together. That takes the whole team. If the team aren't bought in to this, then I'm not sure which project management tool will work for them, but it sure isn't scrum!