Why Scrum is stressing you out

Yes. Communism's key attributes are that it is classless, stateless, and moneyless.

> Who takes all the resources and allocates them "according to each person's need" then?

We'd need to know more about how post-scarcity is achieved in order to answer that question. Star Trek says the replicator is responsible, although that seems unlikely outside of the imagined Star Trek universe. Based on what we can see today, I'd guess robots. But this is all speculative as we don't really know what post-scarcity truly looks like, or if it is achievable at all.

> Communism predates the idea of post scarcity by a hundred years or more AFAIK.

Are you referring to what is oft referred to as primitive communism?

Although I find it hard to believe that humans have ever not thought about post-scarcity. It seems like the first thought/dream anyone would have when first faced with scarcity constraints.

- Make it clear that the name "sprint" is a bad one. This is marathon. Encourage maintaining a steady pace and do not become a party to burn-out.

- Use Agile pointing methodology by the book.

- Standups are for communicating wins and blockers; your overall general status is not useful to the rest of the team and makes the standup go long. Project chit-chat, problem-solving, and talking about wins, is for afterwords or completely different meetings.

- Defend the team from management's attempt to deconstruct points into hours, days, or any other more conventional metric; Agile exists to neuter these anti-patterns, and the points exist only to figure out what gets done in a "sprint" interval. Offer velocity tracking and focus on results instead.

- Defend the plan and the team from all stakeholder asks, and make it clear that adding to an existing plan also means taking other tasks away.

- Carefully triage emergencies, bugs, into the plan with stakeholder consent and involvement.

- In fact, everything for Scrum is just triage, including features. Mark everything with a relative priority, even the normal things.

- Celebrate every single last win, no matter how small. There are no victory ceremonies in the standard Agile Scrum playbook; this is on project leadership to address and absolutely must be done without fail.

If done well, the project says on a relatively even keel for the duration. Using Agile for evil, by instilling a false sense of urgency every two weeks, will burn your team out faster than any Waterfall crunch ever could.

Here's where people get this all screwed up: Agile methodology requires constant communication between the team and stakeholders, leaving the PM/Lead to play goalie for the project's run. That leader must be comfortable saying "no" to anyone/everyone, manage stakeholder expectations at regular intervals, and must have a keen sense of how to break down a project's deliverables into achievable increments. In short: this person must be both technically and socially adept.

If that doesn't sound like your lead or organization, Waterfall may be a better move. It pushes a lot of this communication and negotiation to the planning phase, before any engineering work is done. In the case of contracting, it also escalates project change to a legal process, which can blunt/halt the influence of meddlesome forces. It's also possible to avoid big crunches and burnout, if (and only if) your project management has a clue and is dogged about milestone due dates. Overall, it pushes the bigger social aspects to a preparatory phase which can be executed by different personnel than the team that implements the product.

"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."

"You have five developers working on one project? Isn't that too much?"

Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.

So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.

The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.

Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing.

After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details.

I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work.

Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.