Jira is agile: do you use Jira and Confluence and consider this one of the main reasons contributing to your agility? Congratulations, you are part of the problem.
Boring Backlog: fixed really hard bug? Implemented complex algorithm or cut processing time from 10 hours to 22 seconds? It doesn’t matter, just pick another thing from backlog. Scrum/backlog promotes code monkeys where good effort isn’t rewarded. Personal efforts don’t matter.
Story points implementation: as long as story is implemented, quality or tech-debt doesn’t matter.
The more ritual and incense-waving you wrap around your work, the more likely it is that someone is going to spend all their time on ritual and incense-waving and none on actually creating value.
@btaf45@mspencer712 The whole point of Scrum is to use the retrospective to stop doing what doesn’t work and start doing what does.
At one point, when my team’s workload changed to less-timeboxable work, we threw out the entire concept of sprints and just used kanban instead, and stayed like that for a year. We still did retrospectives on the old sprint cadence though.
@btaf45 in my case, we as a team could have done that, because we didn’t have management dictating how we did anything. It was our choice to do what worked for us, and it was a valuable tool for dealing with whatever got thrown at us.
Now I’m working in a different place that dictates Agile and Scrum to be done Their Way, on top of a project that’s largely waterfall-like to begin with, and I’m starting to see why people say it doesn’t work.
It works, BUT, only when you’re using it as the right tool for the right job and not when management decide to misapply it as a hot new planning methodology.
One of my project managers once described scrum as agile with training wheels. Which I think is a good description. It is useful for teams new to agile but once you get going you can start to throw out the parts that you don’t need or that don’t work for your team. But still useful to get you going initially.
Seems to me you’ve had issues with how people (mis)implement agile in your company, which is a common problem. Managers can’t get their heads out of their waterfall ass. Agile’s not to blame though, i’ve worked in teams where it was a breeze to work in scrum and quite helpful, so don’t blame the tool.
Put a chimpanzee behind the wheel of a Ferrari and you’ll still have problems.
Kinda comes across as someone complaining about how their company implemented agile. The only thing I can relate to is long sprints around the holidays, which I don’t see as an issue.
I’ve only worked for 20-30 person companies so maybe it’s a corpo thing? The post reads like a list of red flags that would have me looking for a new job pronto.
Seems to be more a problem of shitty management than agile vs waterfall.
I have my complaints about Agile, but a bit different from this list. Teams I’ve worked in have generally tried to spec in quality control measures into story points, to prevent some of the issues mentioned, for example.
My issue is almost always just that the top half of the organisation does not, and will never, conceptualise a software project like agile demands. Business will always want X scope within Y time. And Agile demands that at least one of those to be variable. The backlog represents scope organised by time. Want X features complete? Check the backlog to see when they’ll be done. Want to deliver after Y time? Check the backlog to see what features will likely be ready by that time.
But business will not accept that. They have scope requirements and deadlines to deliver within.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
The more ritual and incense-waving you wrap around your work, the more likely it is that someone is going to spend all their time on ritual and incense-waving and none on actually creating value.
Are you questioning the Omnissiah!? The Machine God will not favour your next build!
My thoughts exactly 😂
This is perfect.
I’m going to save this and refer to it, along with the half arsed agile manifesto.
Edit: I also would like to take a moment to invoke the “no true Scottsman” fallacy, by saying they’re just doing it wrong. /s
Do you keep a shopping list? A personal to-do or reminders list? You should stop because that’s a ritual and rituals are clearly bad.
I mean, no, you should keep the rituals that help you work better and discard the rest. Which is what successful agile teams are already doing.
For those using Scrum, that means keep backlog list and discard everything else.
@btaf45 @mspencer712 The whole point of Scrum is to use the retrospective to stop doing what doesn’t work and start doing what does.
At one point, when my team’s workload changed to less-timeboxable work, we threw out the entire concept of sprints and just used kanban instead, and stayed like that for a year. We still did retrospectives on the old sprint cadence though.
That is only something useful if you can use the retrospective to through out Scrum. Otherwise it is yet another Scrum timewaster.
@btaf45 in my case, we as a team could have done that, because we didn’t have management dictating how we did anything. It was our choice to do what worked for us, and it was a valuable tool for dealing with whatever got thrown at us.
Now I’m working in a different place that dictates Agile and Scrum to be done Their Way, on top of a project that’s largely waterfall-like to begin with, and I’m starting to see why people say it doesn’t work.
It works, BUT, only when you’re using it as the right tool for the right job and not when management decide to misapply it as a hot new planning methodology.
@btaf45 tagging @programming so that this federates properly from Mastodon to Lemmy
I jokingly suggested a similar crusade against sprints, because the nature of my team’s work isn’t prohibitively time-boxed either.
Wasn’t expecting the people sitting on that zoom call with the power and influence to make such a change to actually agree
One of my project managers once described scrum as agile with training wheels. Which I think is a good description. It is useful for teams new to agile but once you get going you can start to throw out the parts that you don’t need or that don’t work for your team. But still useful to get you going initially.
@nous That’s a good way of putting it!
Seems to me you’ve had issues with how people (mis)implement agile in your company, which is a common problem. Managers can’t get their heads out of their waterfall ass. Agile’s not to blame though, i’ve worked in teams where it was a breeze to work in scrum and quite helpful, so don’t blame the tool.
Put a chimpanzee behind the wheel of a Ferrari and you’ll still have problems.
Kinda comes across as someone complaining about how their company implemented agile. The only thing I can relate to is long sprints around the holidays, which I don’t see as an issue.
I’ve only worked for 20-30 person companies so maybe it’s a corpo thing? The post reads like a list of red flags that would have me looking for a new job pronto.
Seems to be more a problem of shitty management than agile vs waterfall.
I have my complaints about Agile, but a bit different from this list. Teams I’ve worked in have generally tried to spec in quality control measures into story points, to prevent some of the issues mentioned, for example.
My issue is almost always just that the top half of the organisation does not, and will never, conceptualise a software project like agile demands. Business will always want X scope within Y time. And Agile demands that at least one of those to be variable. The backlog represents scope organised by time. Want X features complete? Check the backlog to see when they’ll be done. Want to deliver after Y time? Check the backlog to see what features will likely be ready by that time.
But business will not accept that. They have scope requirements and deadlines to deliver within.
I know this is just a rant but consider this: if your company reverted back to traditional methods, how much of this would be fixed?