4 ms·
What 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, yo
by bamboozled 2y ago
What 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 nature.
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
- Aeolun 2y agoI just completely ignore sprints, or sprint/standup meetings. Somehow it works well enough that nobody has called me out on it yet. If they all want to waste 2 hours a day, more power to them.
- Pet_Ant 2y agoIf your stand-up meeting is more than 15 minutes long you are doing it wrong. It's called stand-up for a reason. https://scrumguides.org/scrum-guide.html#daily-scrum https://scrumguides.org/scrum-guide.html#daily-scrum > The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. If what you are doing doesn't match that, then it's not a Scrum stand-up.
- randomdata 2y ago> If what you are doing doesn't match that, then it's not a Scrum stand-up. You must have stopped reading too soon. "The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work."
- Aeolun 2y agoIt doesn't matter what is written on a random website (even _the_ scrum website) if nobody actually follows what's written there and still calls it scrum. The de-facto definition of scrum is what people make of it.
- bamboozled 2y agoI just find American corporate culture to be 90% about participation, not really results, but being there, being a "team player" and being really nice to everyone. Not necessarily bad things, but compared to Australian work culture (for example), America is really about "the teaaarrrmm".
- Aeolun 2y agoYeah, I worked with a bunch of people in the US a while ago, and I had the impression that they were playing house or something. I'm all for treating each other with respect, but that means something different to me than the constant. virtue signalling going on there. US people tend to say that Dutch people are very blunt, but it feels like that should just be normal? If you do a bad job I'm not going to tell you that it was nice you tried so hard.
- siva7 2y agoThe sprint goal is a team target. If you're sick that shouldn't endanger the sprint goal because anyone in the team can pick up any work. Of course in mediocre or low-performing teams that's almost never the case but still not the fault of a product framework
- jacknews 2y agoThis seems like a disingenuous answer to me - the rest of the team will take up the slack? And if they can't they must be a low-performing team? The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack. Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it. I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
- deleted 2y ago[deleted]
- JansjoFromIkea 2y agoThis doesn't apply for pod-based systems though, does it? They were everywhere for years there and are still very common. Basically by definition there's only one or two people that can do each task.
- throwaway89988 2y agoWhat you say works 100% for trivial CRUD applications. Which is also, where SCRUM is still a bad framework, but at least SCRUM works on this trivial level of software development. When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
- freedomben 2y ago> 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 nature. It definitely is human nature, and beyond that we're so trained to focus on goals and take them seriously that the "sprint goals" actually feel weaponized to me in order to get people to self-motivate/drive themselves. In the Scrum world engineers are fungible, so if one burns up or stops performing, you just replace them with a new one. Also that "rough week at home" is going to show up on metrics for a very long time. A good manager understands the ebb and flow, but many do not. It also doesn't help that the Certified ScrumMaster® people will put so much emphasis on smoothness and consistency, and when it doesn't happen there's always someone/something to blame. When you remove the context (like team lead who knows what happened) and put it in a quarterly chart for upper management, you get a lot of bad and counter-productive conclusions.