3 ms·

I love agile I think the fundamental underlying principle is sound. Iterate quickly, be flexible, focus on doing a thing and change when it isn't working. The

I love agile I think the fundamental underlying principle is sound. Iterate quickly, be flexible, focus on doing a thing and change when it isn't working. The problem is not and never had been agile. It is the "agile" industry which spun up around it to bilk clueless management, out of money and give Execs reasons to transfer a couple thousand quid to their buddies for agile consulting services. Agile is brilliant precisely because it is so concise and clear and there isn't that much more beyond the manifesto to understand. Unfortunately it was mangled, tortured and twisted into a Frankenstinian nightmare that made everyone suffer. The good news is that right around the time everyone was getting wise to the fact that the entire agile industry was built on sand DevOps popped up to be the new buzzword of which the kingdom of jargon will be grown out of. And the cycle continues.

graypegg 3y ago
The manifesto is concise, but I wouldn’t call it clear. I think that’s why “agility coaches” have their niche. You can’t really teach beliefs, which is why it’s formatted like an agreement. Everyone is supposed to at least think they share these ideals, and make choices that align with those beliefs. But that’s much too introspective to be marketable as meta-work, so people have started reading between the lines to explain away specific meetings or processes. Because “agile” as a concept is so unclear, it’s easy to expand on, creating the weird Frankenstein situation you’re talking about.
- RayFrankenstein 3y ago
  Borrowing from sci-fi, I call it the “Agile Expanded Universe”
dylan604 3y ago
I've been in too many situations where agile was touted, but it was just something to cover up the lack of longer term planning. Treating everything like a fire and running about being agile is also a sign of bad leadership
deleted 3y ago
[deleted]
zamalek 3y ago
> It is the "agile" industry which spun up around it to bilk clueless management Scrum is the epitome of this. It's a half-measure that combines the worst of waterfall and agile. You have (almost always) pointless ceremonies that do little more than satiate management's cargo cult of productivity (yes, I do know what it is academically designed to do). Furthermore, given that its more similar to waterfall than kanban, it often gets watered down for execs and becomes even worse. I have come to realize that unless you're doing something that approximates kanban or chaos/anarchy, then you're probably not doing agile.
deleted 3y ago
[deleted]
AtlasBarfed 3y ago
Agile is universally applied, which is the failing. SOmewhere in those comments is the gem of the whole thing: - It's good for interfaces. Specifically, ones that are ill-defined And therefore, agile is great for moving around widgets, changing CSS / colors / fonts, adding a widget or two, improving validation on fields, maybe splitting a page into multiple. Notice how all those tasks are palpable, pretty simple, well constrained, evolutionary, and steadily improved? Perfect for Agile. It might be good for some microservice development, but it also tends to make microservice interactions unstable and explode their numbers, and destabilize the apis. Research, deeply difficult code, inherited codebases, large refactors, architectural migrations (monolith --> microservices, major version updates to platforms, move to cloud), are AWFUL for Agile. Aside from that, story points, burn charts, velocity charts, fixed sprints, tend to be square peg round holes and big hammers. I can't count the number of times I simply had a "8" ticket that would cross two or three sprints before it was done, and eventually managers just accepted it when I explained what needed to be done. And really, that was still to confining for major major tasks. Also, QA gets completely squeezed, because the agiles I've seen all assume the QA is done in the same sprint the dev occurred. Wow is that dumb. Because the dev runs long, the QA gets shrunk. Really the QA should occur in the following sprint once the dev deadline is achieved. There has to be a middle ground. Either you are doing 6-12 month waterfalls, or doing 1-2 week sprints? Come on people. How about 1-2 month checkins? Sometimes I wonder if software dev orgs could vastly benefit from a bunch of attached "dev assistants" that help write the documentation, track tasks, tickets, etc, and alleviate devs from having to do all that paperwork / distraction. They can function as safe sounding boards, or keep an eye on a bigger picture as the developer dives deep into the tech details. Managers wouldn't stoop to this. SCrummasters ... kind of ... devalue managers a bit at the interface point with engineers, but not enough to get this sort of bookkeeping. Like, if you are shelling out 200k for an engineer, wouldn't you rather they work as much as possible on the tech stuff, and leave the bookkeeping to some cheaper person?

graypegg 3y ago

The manifesto is concise, but I wouldn’t call it clear. I think that’s why “agility coaches” have their niche. You can’t really teach beliefs, which is why it’s formatted like an agreement. Everyone is supposed to at least think they share these ideals, and make choices that align with those beliefs. But that’s much too introspective to be marketable as meta-work, so people have started reading between the lines to explain away specific meetings or processes. Because “agile” as a concept is so unclear, it’s easy to expand on, creating the weird Frankenstein situation you’re talking about.

RayFrankenstein 3y ago
Borrowing from sci-fi, I call it the “Agile Expanded Universe”

dylan604 3y ago

I've been in too many situations where agile was touted, but it was just something to cover up the lack of longer term planning. Treating everything like a fire and running about being agile is also a sign of bad leadership

deleted 3y ago

[deleted]

zamalek 3y ago

> It is the "agile" industry which spun up around it to bilk clueless management Scrum is the epitome of this. It's a half-measure that combines the worst of waterfall and agile. You have (almost always) pointless ceremonies that do little more than satiate management's cargo cult of productivity (yes, I do know what it is academically designed to do). Furthermore, given that its more similar to waterfall than kanban, it often gets watered down for execs and becomes even worse. I have come to realize that unless you're doing something that approximates kanban or chaos/anarchy, then you're probably not doing agile.

deleted 3y ago

[deleted]

AtlasBarfed 3y ago

Agile is universally applied, which is the failing. SOmewhere in those comments is the gem of the whole thing: - It's good for interfaces. Specifically, ones that are ill-defined And therefore, agile is great for moving around widgets, changing CSS / colors / fonts, adding a widget or two, improving validation on fields, maybe splitting a page into multiple. Notice how all those tasks are palpable, pretty simple, well constrained, evolutionary, and steadily improved? Perfect for Agile. It might be good for some microservice development, but it also tends to make microservice interactions unstable and explode their numbers, and destabilize the apis. Research, deeply difficult code, inherited codebases, large refactors, architectural migrations (monolith --> microservices, major version updates to platforms, move to cloud), are AWFUL for Agile. Aside from that, story points, burn charts, velocity charts, fixed sprints, tend to be square peg round holes and big hammers. I can't count the number of times I simply had a "8" ticket that would cross two or three sprints before it was done, and eventually managers just accepted it when I explained what needed to be done. And really, that was still to confining for major major tasks. Also, QA gets completely squeezed, because the agiles I've seen all assume the QA is done in the same sprint the dev occurred. Wow is that dumb. Because the dev runs long, the QA gets shrunk. Really the QA should occur in the following sprint once the dev deadline is achieved. There has to be a middle ground. Either you are doing 6-12 month waterfalls, or doing 1-2 week sprints? Come on people. How about 1-2 month checkins? Sometimes I wonder if software dev orgs could vastly benefit from a bunch of attached "dev assistants" that help write the documentation, track tasks, tickets, etc, and alleviate devs from having to do all that paperwork / distraction. They can function as safe sounding boards, or keep an eye on a bigger picture as the developer dives deep into the tech details. Managers wouldn't stoop to this. SCrummasters ... kind of ... devalue managers a bit at the interface point with engineers, but not enough to get this sort of bookkeeping. Like, if you are shelling out 200k for an engineer, wouldn't you rather they work as much as possible on the tech stuff, and leave the bookkeeping to some cheaper person?