I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team. We often would go days without having a formal meeting. But, software was different then as well. Everything is interconnected now. One team dropp…
Why Scrum is stressing you out
91–100 of 462 posts
Re: Why Scrum is stressing you out
#92I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team. We often would go days without having a formal meeting. But, software was different then as well. Everything is interconnected now. One team dropp…
Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum).
It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").
I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.
When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.
Re: Why Scrum is stressing you out
#93What I dislike about SCRUM specifically is that if you're having a rough week at home, recovering from illness or you just have things to do outside of work, you can't really just have an easy week and make up for it later on. It's a kind of constant grind and we always have a way of "filling up" our sprint. If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human na…
If they all want to waste 2 hours a day, more power to them.
Re: Why Scrum is stressing you out
#94One hill I will utterly die on: Many people (including some in these comments) are fully able and happy to go their entire career mistaking high performing individuals with a high performing work framework.
Re: Why Scrum is stressing you out
#95Earlier quoted context omitted.
>> None of that is required to actually create software. Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) >> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone. Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress,…
> Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) You are essentially saying “Shit is bad, give up on it ever improving.”
It seems to me that most devs don't understand the root problem, so they both don't understand, and don't constructively improve the current solution.
Improvement is not "leave me alone". Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
Re: Why Scrum is stressing you out
#96We moved from sprints back to work queues for exactly this reason. Output is exactly the same but no one is cutting corners to "finish" the sprint. We still use a kanban and do estimation the same exact way, but rather than arbitrary deadlines, devs are trained and encouraged to communicate on their velocity in a way that is far more effective than a daily standup. Scrum was an idea that had its time, but after like.…
The main value of stressing about sprint goals and what's "in" a sprint and finishing it is the very specific situation of there being a bunch of people who want to feed in a large amount of work to a team (usually bugs/support requests/operational work) and it results in constant prioritization issues. If you don't have that situation, you probably don't need to be really careful about what's in a sprint.
Re: Why Scrum is stressing you out
#97Earlier quoted context omitted.
That's normal nowadays, even in the most ridiculous of situations. I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that w…
What was the opportunity cost of potentially deprioritizing other work?
I read it as that the opportunity cost would be lower.
Re: Why Scrum is stressing you out
#98Earlier quoted context omitted.
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers. They also tend to make the stand-ups one hour long.
Re: Why Scrum is stressing you out
#99Re: Why Scrum is stressing you out
#100Earlier quoted context omitted.
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers. They also tend to make the stand-ups one hour long.