3 ms·

Alright, here's my Agile rant. It's bigger than my last one because I hadn't experienced it to its full potential. In my current team, it's followed religiousl

Alright, here's my Agile rant. It's bigger than my last one because I hadn't experienced it to its full potential. In my current team, it's followed religiously. Stand-ups are daily and people use it as a time to fraternize between talking about actual work, I just want to get back to work. There's no camaraderie, every retro is this one guy bitching about how things aren't done the way they were in his previous job (and usually they aren't because it wouldn't make sense). The time between demo and sprint planning is a full day's of wasted time per developer, because there's nothing to do. Every developer writes hacks and things that shouldn't pass code review get passed because there's not enough time in the sprint to implement the known-good solution. I've caught flak from going beyond the story requirements because I know what the final solution actually looks like. I also catch flak regularly because I run out of work and I take more tickets that are not in the sprint. I've never not finished a task when I did that. Every other meeting I get to hear a spiel from the project manager about how great Agile is. I'm sure there's cases where Agile is the perfect solution. But it's not every time, and the rigidity that people want to apply was never meant to be there. I wish it would go away, but it's the perfect tool for management to be able to submit reports and say "look how consistent we are!"

pjkundert 10y ago
> In my current team, it's followed religiously. So, not Agile then...
ebiester 10y ago
So, it sounds like you hate your team, and agile just makes it more obvious. So, here are the few quick fixes I see: 1. point out in retro that standups as currently constructed are a waste of time. Tell them you will utilize the law of two feet if they can't be tightened up. 2. Suggest a definition of done. If the product owner doesn't agree it meets requirements, code quality isn't high, and tests aren't there then it's' not fucking done. That means your sprints are implementing too much. 3. Don't pull in more work if other members are struggling to finish something. How can you help them out to make sure their code quality doesn't suffer? If your piece is adjacent to another that is in desperate need of refactoring/code quality improvement, just say that you needed to clean that up to implement your solution. Use that time to de-hackify.
- arenaninja 10y ago
  'Hate your team' is a little too strong, I think. I may dislike some of their working habits, and I think our code quality would be higher if we took code review seriously (I've been told to not hold back PR approval even on issues like not putting braces on single line if statements - if it runs, it's "good enough"; I'm also the only one to ever write tests). Implementing less isn't an option because we have a hard deadline I see what you're saying in your last point, but on that particular sprint, someone didn't want to do something they had assigned to themselves and pulled in a different story/ticket. I have no issues picking up anything that is still unassigned, and I had mentioned during the daily that I was available if anyone needed help with anything. No one got back to me and I honestly didn't know until later that day that the other story/ticket hadn't even been started. I don't think I should have to talk to individual developers to see if they need help; we're adults and if you can't manage your workload or can't communicate that then I don't have a solution for you

pjkundert 10y ago

> In my current team, it's followed religiously. So, not Agile then...

ebiester 10y ago

So, it sounds like you hate your team, and agile just makes it more obvious. So, here are the few quick fixes I see: 1. point out in retro that standups as currently constructed are a waste of time. Tell them you will utilize the law of two feet if they can't be tightened up. 2. Suggest a definition of done. If the product owner doesn't agree it meets requirements, code quality isn't high, and tests aren't there then it's' not fucking done. That means your sprints are implementing too much. 3. Don't pull in more work if other members are struggling to finish something. How can you help them out to make sure their code quality doesn't suffer? If your piece is adjacent to another that is in desperate need of refactoring/code quality improvement, just say that you needed to clean that up to implement your solution. Use that time to de-hackify.

arenaninja 10y ago
'Hate your team' is a little too strong, I think. I may dislike some of their working habits, and I think our code quality would be higher if we took code review seriously (I've been told to not hold back PR approval even on issues like not putting braces on single line if statements - if it runs, it's "good enough"; I'm also the only one to ever write tests). Implementing less isn't an option because we have a hard deadline I see what you're saying in your last point, but on that particular sprint, someone didn't want to do something they had assigned to themselves and pulled in a different story/ticket. I have no issues picking up anything that is still unassigned, and I had mentioned during the daily that I was available if anyone needed help with anything. No one got back to me and I honestly didn't know until later that day that the other story/ticket hadn't even been started. I don't think I should have to talk to individual developers to see if they need help; we're adults and if you can't manage your workload or can't communicate that then I don't have a solution for you