Any developers here think “Agile” is a cult?

blaincorrous

All Puns Intended
Est. Contributor
Messages
1,899
Role
  1. Diaper Lover
I’ve been slotted into a team where they use a heavy Agile methodology. I find myself spending more time and effort on “ceremonies” and “retrospectives”. It feels like it takes up about half my attention, and that attention is alrea

I don’t mind organization, but things feel cult like when they change names of things like meetings to “ceremonies”. Even the daily meetings and retros feel like confession when I have to defend how the real world intrudes on this “perfect” framework.

And I take particular umbridge with the point that tasks (user stories) need to be sized according to Fibonacci numbers. 1,2,3,5,8 for example. It seems like an entirely arbitrary attempt to be clever.
 
  • Wow
Reactions: KrankyPants
I never heard about AGILE before, but I think it's great!
 
It all depends on what the upper management has deemed a good "team building strategy".
I'm sure what you are experiencing is based on a workshop, training class, or seminar that some executive(s) attended.
 
  • Like
Reactions: blaincorrous and Billybatts
There is what I call "big A" agile and "little A" agile.

I am a believer in agile methodologies, and generally subscribe to a lot of the underlying principles like doing what makes sense, having the flexibility to change your process, doing work in small pieces where you can continuously have a tangible thing to play with, involving the customer/stakeholders throughout, etc.

That said, Agile has become a business, with companies offering their flavor and tooling around it (and of course their training and consulting and certification), which then gets sold to management and then they're paying $2000 /a year/ so you can tall yourself a "Certified SAFe agile grandmaster" or whatever. Agile can also butt up against business realities, old guard management, customers, and so on. Management also often can't help themselves with trying to measure and control things, and you again start to see a lot of the old tropes creep in because its hard to gather consistent metrics when a team changes how they track issues or manage their work flow. And few managers can breath if they can't somehow figure out how many bricks of code you're laying a day.

Where I work we've fallen into a pretty good workflow where we took the bits that made sense, made up our own bits, and threw out stuff that didn't work. Pointing poker? Waste of time for us. We just discuss it and usually quickly come to a consensus. All the various story point "rules", nuts to it.. we basically call them "small, medium, big" and go from there. Stories having to be "1 at most 2 days work" .. hell no, the nature of what we do has way too much overhead to iterate that quickly. If something is gonna take 4 days, we say its a big task and move on rather than try to break it into ackward chunks. Rigid adherence to the concept of a release.. nope, if we decide we need another sprint we argue the point with management and usually just extend the thing. We also don't involve the entire damn program in release planning. Conceptually it makes sense, practically it just didn't work for us. Releases are planned by leads and product owners and dolled out like ye olden dinosaurs did. We're a large multi-team company so we do the scrum-of-scrums (just leads/product owners) thing, and we do daily standups, and yeah, as a lead/pseudo product owner I probably spend 1/3 of my day in meetings but aside from the daily standup, and maybe 1 hour sprint planning every 2 weeks, most people are relatively free to just get their shit done.

EDIT: since I'm ranting.. totally agree on the name things. I actually think that hindered adoption somewhat because you feel like an idiot talking about "stories" and "sprints" and such. This is /finally/ starting to change, with terminology like "iteration" catching on vs sprint and "team lead" making a comeback over "scrum master"... though I think we're stuck with "story" for the time being.
 
Last edited:
  • Like
Reactions: blaincorrous, perlFerret, Deleted member 63976 and 1 other person
BoundCoder said:
There is what I call "big A" agile and "little A" agile.

I am a believer in agile methodologies, and generally subscribe to a lot of the underlying principles like doing what makes sense, having the flexibility to change your process, doing work in small pieces where you can continuously have a tangible thing to play with, involving the customer/stakeholders throughout, etc.

That said, Agile has become a business, with companies offering their flavor and tooling around it (and of course their training and consulting and certification), which then gets sold to management and then they're paying $2000 /a year/ so you can tall yourself a "Certified SAFe agile grandmaster" or whatever. Agile can also butt up against business realities, old guard management, customers, and so on. Management also often can't help themselves with trying to measure and control things, and you again start to see a lot of the old tropes creep in because its hard to gather consistent metrics when a team changes how they track issues or manage their work flow. And few managers can breath if they can't somehow figure out how many bricks of code you're laying a day.

Where I work we've fallen into a pretty good workflow where we took the bits that made sense, made up our own bits, and threw out stuff that didn't work. Pointing poker? Waste of time for us. We just discuss it and usually quickly come to a consensus. All the various story point "rules", nuts to it.. we basically call them "small, medium, big" and go from there. Stories having to be "1 at most 2 days work" .. hell no, the nature of what we do has way too much overhead to iterate that quickly. If something is gonna take 4 days, we say its a big task and move on rather than try to break it into ackward chunks. Rigid adherence to the concept of a release.. nope, if we decide we need another sprint we argue the point with management and usually just extend the thing. We also don't involve the entire damn program in release planning. Conceptually it makes sense, practically it just didn't work for us. Releases are planned by leads and product owners and dolled out like ye olden dinosaurs did. We're a large multi-team company so we do the scrum-of-scrums (just leads/product owners) thing, and we do daily standups, and yeah, as a lead/pseudo product owner I probably spend 1/3 of my day in meetings but aside from the daily standup, and maybe 1 hour sprint planning every 2 weeks, most people are relatively free to just get their shit done.

EDIT: since I'm ranting.. totally agree on the name things. I actually think that hindered adoption somewhat because you feel like an idiot talking about "stories" and "sprints" and such. This is /finally/ starting to change, with terminology like "iteration" catching on vs sprint and "team lead" making a comeback over "scrum master"... though I think we're stuck with "story" for the time being.
flexibility and team's comfort is key. I think agile is great if applied well
 
  • Like
Reactions: perlFerret
BoundCoder said:
EDIT: since I'm ranting.. totally agree on the name things. I actually think that hindered adoption somewhat because you feel like an idiot talking about "stories" and "sprints" and such. This is /finally/ starting to change, with terminology like "iteration" catching on vs sprint and "team lead" making a comeback over "scrum master"... though I think we're stuck with "story" for the time being.
Agreed with your entire post.
As for "story", the whole concept of a user story is to explain things from a user's perspective.
"As a _________, I want to _____________ so I can ___________." - it explains who wants the feature, what it should do, and why they want it - what the business value is. If it doesn't provide those pieces of information, it's not a user story, it's just a task in a to-do list, or a feature request that needs further information before being worked. Often missing is the "why" part - the business value that's being added.
 
perlFerret said:
Agreed with your entire post.
As for "story", the whole concept of a user story is to explain things from a user's perspective.
"As a _________, I want to _____________ so I can ___________." - it explains who wants the feature, what it should do, and why they want it - what the business value is. If it doesn't provide those pieces of information, it's not a user story, it's just a task in a to-do list, or a feature request that needs further information before being worked. Often missing is the "why" part - the business value that's being added.
Oh I do get the rational and also get that an entirely different set of terms was probably chosen on purpose to differentiate everything from the olden ways... but I still think it sounds goofy! That said, I've never heard anything better that doesn't use the dreaded R word though (requirement).
 
Last edited:
  • Like
Reactions: perlFerret
These are useful perspectives. Thank you.

We just did some training for user story writing, and there’s some good ideas, but it seems like a lot of effort. Still, I’ve had enough trouble with tasking in the past that I should be receptive to a new solution.

Mostly, I already have enough trouble winding myself up for normal work. It’s hard to get excited about agile, so it’s hard to use my natural traits to excel at this aspect of my work.
 
Last edited:
  • Like
Reactions: perlFerret
Back
Top